UTF-8

UTF-8 ist ein variable Breite Zeichenkodierung Wird für die elektronische Kommunikation verwendet. Definiert durch die Unicode Standard, der Name wird abgeleitet von Unicode (oder Universal codiertes Zeichensatz) Transformationsformat-8-Bit.^[1]

UTF-8 kann alle 1.112.064 codieren^{[NB 1]} gültiger Charakter Codepunkte in Unicode Verwenden Sie eins bis vier eins.Byte (8-Bit) Code-Einheiten. Codepunkte mit niedrigeren numerischen Werten, die tendenziell häufiger auftreten, werden unter Verwendung weniger Bytes codiert. Es wurde für für Rückwärtskompatibilität mit ASCII: Die ersten 128 Zeichen von Unicode, die eins zu eins mit ASCII entsprechen, werden unter Verwendung eines einzelnen Byte mit demselben binären Wert wie ASCII codiert, sodass auch gültiger ASCII-Text auch gültiges UTF-8-kodierter Unicode ist. Da ASCII-Bytes bei der Codierung von Nicht-ASCII-Codepunkten in UTF-8 nicht auftreten, kann UTF-8 in den meisten Programmier- und Dokumentsprachen, die bestimmte ASCII-Zeichen auf besondere Weise interpretieren, sicher verwendet werden, wie z. B. / (Schrägstrich) in Dateinamen, \ (Backslash) in Fluchtsequenzen, und % in printf.

UTF-8 wurde als überlegene Alternative zu UTF-1, eine vorgeschlagene Codierung der variablen Breite mit teilweise ASCII-Kompatibilität, bei der einige Funktionen fehlten, einschließlich Selbstsynchronisation und vollständig ASCII-kompatibles Handling von Zeichen wie Schrägstrichen. Ken Thompson und Rob Pike produzierte die erste Implementierung für die Plan 9 Betriebssystem im September 1992.^[2][3] Dies führte zu seiner Annahme durch X/offen als Spezifikation für FSS-UTF, was zuerst offiziell präsentiert werden würde Usenix im Januar 1993 und anschließend von der übernommen Internettechnik-Arbeitsgruppe (IETF) in RFC 2277 (BCP 18) für zukünftige Internetstandards funktionieren und ersetzen einzelne Byte -Zeichensätze wie z. Latein-1 In älteren RFCs.

UTF-8 ist die dominierende Kodierung für die Weltweites Netz (und Internet -Technologien), die 98% aller Webseiten und bis 2022 bis zu 100,0% für einige Sprachen ausmachen.^[4]

Benennung

Das offizielle Internet zugewiesene Zahlen Autorität (IANA) Code für die Codierung ist "UTF-8".^[5] Alle Buchstaben sind obere Fälle und der Name wird beigebracht. Diese Schreibweise wird in allen Unicode -Konsortiumdokumenten in Bezug auf die Codierung verwendet.

Der Name "UTF-8"Kann nach allen Maßstäben verwendet werden, die der IANA -Liste entsprechen (einschließlich der Teilnahme CSS, Html, Xml, und HTTP -Header),^[6] Da die Erklärung von Fall unempfindlich ist.^[5]

Andere Varianten, wie diejenigen, die den Bindestrich auslassen oder ihn durch einen Raum ersetzen, d. H. "UTF8" oder "UTF 8", werden nach den Regierungsstandards nicht als korrekt anerkannt.^[7] Trotzdem die meisten Internetbrowser Kann sie verstehen, und so können Standards, die die bestehende Praxis beschreiben sollen (wie HTML5), ihre Anerkennung effektiv erfordern.^[8]

Inoffiziell, UTF-8-BOM und UTF-8-Nobom werden manchmal für Textdateien verwendet, die a enthalten oder nicht enthalten Byte -Bestellmarke (BOM). Insbesondere in Japan wird die UTF-8-Codierung ohne Bom manchmal genannt ""UTF-8n".^[9][10]

Windows XP und später, einschließlich aller unterstützten Windows -Versionen, haben Codepage 65001als Synonym für UTF-8 (seitdem Windows 7 Die Unterstützung für UTF-8 ist besser).^[11] Seit Windows 10 Version 1903, der Standard für Windows Notepad in UTF-8 geändert.^[12][13]

Im Pcl, UTF-8 heißt Symbol-ID "18n" (PCL unterstützt 183 Zeichencodierungen, die als Symbolsets bezeichnet werden und möglicherweise auf ein, 18N, dh UTF-8 reduziert werden können).^[14]

Codierung

Da die Einschränkung des Unicode-Code-Raums auf 21-Bit-Werte im Jahr 2003 so definiert ist, dass UTF-8 Codepunkte in ein bis vier Bytes codieren, abhängig von der Anzahl der signifikanten Bits im numerischen Wert des Codespunkts. Die folgende Tabelle zeigt die Struktur der Codierung. Das x Zeichen werden durch die Bits des Codepunkts ersetzt.

Die ersten 128 Codepunkte (US-ASCII) benötigen ein Byte. Die nächsten 1.920 Codepunkte benötigen zwei Bytes, die den Rest von fast allen abdecken Latein-Skriptalphabete, und auch IPA extensions, griechisch, kyrillisch, koptisch, Armenisch, hebräisch, Arabisch, Syrien, Thaana und N'ko Alphabete sowie Kombination diakritischer Markierungen. Für den Rest der Bytes werden drei Bytes benötigt Grundlegende mehrsprachige Ebene, was praktisch alle Codepunkte in der gemeinsamen Verwendung enthält,^[15] einschließlich der meisten Chinesische, japanische und koreanische Charaktere. Für Codepunkte in der werden vier Bytes benötigt andere Ebenen von Unicode, einschließlich weniger häufig CJK -Charaktere, verschiedene historische Skripte, mathematische Symbole, und Emoji (piktografische Symbole).

Ein "Charakter" kann mehr als 4 Bytes einnehmen, da er aus mehr als einem Codepunkt besteht. Zum Beispiel a Nationalflaggencharakter Nimmt 8 Bytes, da es "aus einem Paar Unicode -Skalarwerte konstruiert ist", beide von außerhalb des BMP.^{[16][NB 3]}

Beispiele

Betrachten Sie die Codierung der Eurozeichen, €:

1. Der Unicode -Codepunkt für € ist U+20AC.
2. Da dieser Codepunkt zwischen U+0800 und U+FFFF liegt, werden drei Bytes zur Codierung benötigt.
3. Hexadezimal 20AC ist binär 0010 0000 1010 1100. Die beiden führenden Nullen werden hinzugefügt, da eine Drei-Byte-Codierung genau 16 Bits aus dem Codepunkt benötigt.
4. Da die Codierung drei Bytes lang sein wird, beginnt das führende Byte mit drei 1s, dann einem 0 (0 () 1110 ...)
5. Die vier bedeutendsten Bits des Codepunkts werden in den verbleibenden vier Bits dieses Bytes gespeichert ( 11100010), 12 Bit des Codepunkts zu lassen, die noch codiert werden sollen ( ...0000 1010 1100).
6. Alle Fortsetzung Bytes enthalten genau sechs Bits aus dem Codepunkt. Die nächsten sechs Bits des Codepunkts werden also in der niedrigen Bestellung sechs Bit des nächsten Byte gespeichert, und 10 wird in der hohen Reihenfolge zwei Bits gespeichert, um es als Fortsetzung von Byte zu markieren (also 10000010).
7. Schließlich werden die letzten sechs Bits des Codepunkts in der niedrigen Reihenfolge sechs Bit des letzten Byte und wieder gespeichert 10 wird in der hohen Reihenfolge zwei Bits gespeichert ( 10101100).

Die drei Bytes 11100010 10000010 10101100 kann besser geschrieben werden in hexadezimal, wie E2 82 AC.

Die folgende Tabelle fasst diese Konvertierung sowie andere mit unterschiedlichen Längen in UTF-8 zusammen. Die Farben geben an, wie Bits aus dem Codepunkt auf die UTF-8-Bytes verteilt sind. Zusätzliche Bits, die durch den UTF-8-Codierungsprozess hinzugefügt wurden, werden schwarz angezeigt.

Oktal

Die Verwendung von sechs Bits pro Byte von UTF-8 zur Darstellung der tatsächlichen Zeichen, die codiert werden, bedeutet, dass dies dies bedeutet Oktal Notation (die 3-Bit-Gruppen verwendet) kann den Vergleich von UTF-8-Sequenzen miteinander und bei der manuellen Konvertierung unterstützen.^[17]

Bei Oktalnotation bleibt die mit X, Y, Z oder W in der Tabelle gekennzeichneten oktalischen Ziffern beim Konvertieren in oder von UTF-8 unverändert.

Beispiel: á = u+00c1 = 0301 (in Oktal) ist codiert als 303 201 in UTF-8 (C3 81 in Hex).

Beispiel: € = U+20AC = 020254 ist codiert als 342 202 254 in UTF-8 (E2 82 AC in Hex).

Codepage -Layout

Die folgende Tabelle fasst die Verwendung von UTF-8 zusammen Codeeinheiten (Individuell Bytes oder Oktetten) in einem Code Seitenformat. Die obere Hälfte ist für Bytes, die nur in Single-Byte-Codes verwendet werden, daher sieht sie wie eine normale Codeseite aus. Die untere Hälfte ist für Fortsetzung von Bytes und führenden Bytes und wird in der unten stehenden Legende weiter erklärt.

Overgon Codings

Im Prinzip wäre es möglich, die Anzahl der Bytes in einer Codierung aufzublasen, indem der Codepunkt mit den führenden 0er Jahren gepolstert wird. Um das Euro -Zeichen € aus dem obigen Beispiel in vier Bytes anstelle von drei zu codieren, konnte es mit den führenden 0S bis zum 21 -Bit -Long gepolstert werden.000 000010 000010 101100, und codiert als 11110000 10000010 10000010 10101100 (oder F0 82 82 AC in hexadezimal). Dies wird als eine genannt überlange Codierung.

Der Standard gibt an, dass die korrekte Codierung eines Codepunkts nur die minimale Anzahl von Bytes verwendet, die erforderlich sind, um die signifikanten Bits des Codepunkts zu halten. Längere Kodierungen werden genannt überlangen und sind keine gültigen UTF-8-Darstellungen des Codepunkts. Diese Regel behält eine Eins-zu-Eins-Korrespondenz zwischen Codepunkten und ihren gültigen Codierungen bei, so dass für jeden Codepunkt eine eindeutige gültige Codierung vorliegt. Dies stellt sicher, dass String-Vergleiche und -Suchanfragen gut definiert sind.

Ungültige Sequenzen und Fehlerbehandlung

Nicht alle Sequenzen von Bytes sind gültig UTF-8. Ein UTF-8-Decoder sollte vorbereitet sein für:

• Ungültige Bytes
• Ein unerwarteter Fortsetzungsbyte
• Ein Nicht-Ein-in-Einsatz-Byte vor dem Ende des Charakters
• Die Zeichenfolge, die vor dem Ende des Zeichens endet (was in einer einfachen Stringkürzung passieren kann)
• Eine überlange Codierung
• Eine Sequenz, die zu einem ungültigen Codepunkt decodiert

Viele der ersten UTF-8-Decoder würden diese entschlüsseln, falsche Bits ignorieren und überlange Ergebnisse akzeptieren. Sorgfältig gefertigtes ungültiges UTF-8 kann sie entweder überspringen oder ASCII-Zeichen wie NUL, Slash oder Zitate erstellen. Ungültige UTF-8 wurde verwendet, um Sicherheitsvalidierungen in hochkarätigen Produkten einschließlich Microsoft zu umgehen Iis Webserver^[25] und Apache's Tomcat Servlet Container.^[26] RFC 3629 Staaten "Implementierungen des Dekodierungsalgorithmus müssen vor Decodierung ungültiger Sequenzen schützen."^[7] Der Unicode -Standard Erfordert Decoder "... eine schlecht geformte Code-Einheit-Sequenz als Fehlerbedingung behandeln. Dies garantiert, dass sie eine schlecht geformte Code-Einheit-Sequenz weder interpretiert noch emittiert."

Seit RFC 3629 (November 2003) die hohen und niedrigen Ersatzhälften von verwendet von UTF-16 (U+D800 über U+DFFF) und Codepunkte, die von UTF-16 nicht codierbar sind (diejenigen nach u+10ffff) sind keine legalen Unicode-Werte, und ihre UTF-8-Codierung muss als ungültige Byte-Sequenz behandelt werden. Nicht dekodierende ungepaarte Ersatzhälften macht es unmöglich, ungültige UTF-16 (wie Windows FileName oder UTF-16, die zwischen den Ersatzstücken aufgeteilt wurde) als UTF-8 zu speichern.^[27] Während es mit möglich ist mit WTF-8.

Einige Implementierungen von Decoder machen Ausnahmen von Fehlern.^[28] Dies hat den Nachteil, dass es ansonsten harmlose Fehler (z. Denial of Service. Zum Beispiel würde frühe Versionen von Python 3.0 sofort beenden, wenn die Befehlszeile oder Umgebungsvariablen enthielt ungültige UTF-8.^[29] Eine alternative Praxis besteht darin, Fehler durch einen Ersatzcharakter zu ersetzen. Seit Unicode 6^[30] (October 2010), the standard (chapter 3) has recommended a "best practice" where the error ends as soon as a disallowed byte is encountered. In these decoders E1, A0, C0 is two errors (2 bytes in the first one). This means an error is no more than three bytes long and never contains the start of a valid character, and there are 21,952 different possible errors.^[31] Der Standard empfiehlt außerdem, jeden Fehler durch das zu ersetzen Ersatzcharakter "�" (u+fffd).

Byte -Bestellmarke

Wenn der UTF-16 Unicode Byte -Bestellmarke (BOM, U+FEFF) character is at the start of a UTF-8 file, the first three bytes will be 0xef, 0xbb, 0xbf.

The Unicode Standard neither requires nor recommends the use of the BOM for UTF-8, but warns that it may be encountered at the start of a file trans-coded from another encoding.^[32] While ASCII text encoded using UTF-8 is backward compatible with ASCII, this is not true when Unicode Standard recommendations are ignored and a BOM is added. A BOM can confuse software that isn't prepared for it but can otherwise accept UTF-8, e.g. programming languages that permit non-ASCII bytes in String -Literale but not at the start of the file. Nevertheless, there was and still is software that always inserts a BOM when writing UTF-8, and refuses to correctly interpret UTF-8 unless the first character is a BOM (or the file only contains ASCII).^[33]

Annahme

Declared character set for 10 million most popular websites since 2010

Use of the main encodings on the web from 2001 to 2012 as recorded by Google,^[34] with UTF-8 overtaking all others in 2008 and over 60% of the web in 2012 (since then approaching 100%). Das ASCII-only figure includes all web pages that only contain ASCII characters, regardless of the declared header. Other encodings of Unicode such as GB2312 are added to "others".

Many standards only support UTF-8, e.g. offen JSON exchange requires it (without a byte order mark (BOM)).^[35] UTF-8 is also the recommendation from the Waswg for HTML and Dom Spezifikationen,^[36] und die Internet -Mail -Konsortium recommends that all e-mail programs be able to display and create mail using UTF-8.^[37][38] Das World Wide Web Konsortium recommends UTF-8 as the default encoding in XML and HTML (and not just using UTF-8, also declaring it in metadata), "even when all characters are in the ASCII range .. Using non-UTF-8 encodings can have unexpected results".^[39]

Lots of software has the ability to read/write UTF-8, though this often requires the user to change options from the normal settings, and may require a BOM (byte order mark) as the first character to read the file. Beispiele beinhalten Microsoft Word^[40][41][42] und Microsoft Excel.^[43][44] Most databases support UTF-8 (sometimes the only option as with some file formats), including Microsoft's since SQL Server 2019, resulting in 35% speed increase, and "nearly 50% reduction in storage requirements."^[45]

UTF-8 has been the most common encoding for the Weltweites Netz seit 2008.^[46] Ab Juli 2022^{[aktualisieren]}, UTF-8 accounts for on average 97.7% of all web pages (and 989 of the top 1,000 highest ranked web pages).^[4] UTF-8 includes ASCII as a subset; almost no websites declare only ASCII used.^[47] Over a third of the languages tracked have 100.0% UTF-8 use.

For local text files UTF-8 usage is lower, and many legacy single-byte (and CJK multi-byte) encodings remain in use. The primary cause is editors that do not display or write UTF-8 unless the first character in a file is a byte order mark (BOM), making it impossible for other software to use UTF-8 without being rewritten to ignore the byte order mark on input and add it on output.^[48][49] There has been some improvement, Notepad on Windows 10 writes UTF-8 without a BOM by default,^[50] and some system files on Windows 11 require UTF-8,^[51] and almost all files on macOS and Linux are required to be UTF-8 (without a BOM). Java 18 defaults to reading and writing files as UTF-8,^[52] and in older versions the Nio API only did so. Many other programming languages default to UTF-8 for I/O; or plan to migrate to UTF-8, such as Python. which already made changes to help programmers prepare for the change "to UTF-8 [since it has] become the de-facto standard text encoding".^[53]

Internally in software usage is lower, with UTF-16 in use, particularly on Windows, but also by JavaScript, Python,^[54][55] Qt, and many other cross-platform software libraries. Compatibility with the Windows -API is one of the primary reasons for this (though the belief that direct indexing of BMP improves speed was also a factor). More recent software has started to use UTF-8 (almost) exclusively: the default string primitive used in gehen,^[56] Julia, Rost, Swift 5,^[57] und Pypy^[58] is UTF-8, a future version of Python intends to store strings as UTF-8,^[59] and modern versions of Microsoft Visual Studio use UTF-8 internally^[60] (however still require a command-line switch to read or write UTF-8^[61]). UTF-8 is the "only text encoding mandated to be supported by the C++ standard", as of C ++ 20.^[62] As of May 2019, Microsoft reversed its course of only supporting UTF-16 for the Windows API, providing the ability to set UTF-8 as the "code page" for the multi-byte API (previously this was impossible), and now Microsoft recommends programmers use UTF-8.^[63]

Geschichte

Das Internationale Standardisierungsorganisation (ISO) set out to compose a universal multi-byte character set in 1989. The draft ISO 10646 standard contained a non-required annektieren called UTF-1 that provided a byte stream encoding of its 32-Bit Codepunkte. Diese Codierung war unter anderem aus Leistungsgründen nicht zufriedenstellend, und das größte Problem war wahrscheinlich, dass es keine klare Trennung zwischen ASCII und Nicht-ASCII hatte UTF-1-kodierter Text könnte den vorhandenen Code verwirren, der ASCII erwartet (oder erweiterte ASCII), weil es Fortsetzungsbytes im Bereich 0x21–0x7e enthalten könnte, was in ASCII etwas anderes bedeutete, z. B. 0x2f für '/', die Unix Weg Verzeichnisabscheider, und dieses Beispiel spiegelt sich im Namen und einführenden Text seines Austauschs wider. Die folgende Tabelle wurde von einer Textbeschreibung im Anhang abgeleitet.

Im Juli 1992 die X/offen Das Komitee Xojig suchte nach einer besseren Codierung. Dave Prosser von UNIX -Systemlabors eingereicht einen Vorschlag für einen, der schnellere Implementierungseigenschaften hatte und die Verbesserung einführte, die 7-Bit-ASCII-Zeichen nur darstellen würden; Alle Multi-Byte-Sequenzen würden nur Bytes enthalten, in denen das hohe Bit festgelegt wurde. Das Namensdateisystem sicher UCS Transformationsformat (FSS-UTF) und der größte Teil des Textes dieses Vorschlags wurden später in der endgültigen Spezifikation erhalten.^{[64][65][66][67]}

FSS-UTF

Im August 1992 wurde dieser Vorschlag von einem verbreitet IBM X/offener Vertreter von Interessenten. Eine Modifikation durch Ken Thompson des Plan 9 Betriebssystem Gruppe bei Bell Labs machte es Selbstsynchronisation, um einen Leser überall zu beginnen und sofort Charaktergrenzen zu erkennen, um etwas weniger biteffizient zu sein als der vorherige Vorschlag. Es gab auch die Verwendung von Verzerrungen auf und fügte stattdessen die Regel hinzu, dass nur die kürzest mögliche Codierung zulässig ist. Der zusätzliche Verlust der Kompaktheit ist relativ unbedeutend, aber die Leser müssen nun auf ungültige Kodierungen achten, um Zuverlässigkeit und insbesondere Sicherheitsprobleme zu vermeiden. Thompsons Entwurf wurde am 2. September 1992 auf a umrissen Placemat in einem New Jersey Diner mit Rob Pike. In den folgenden Tagen haben Pike und Thompson es implementiert und aktualisiert Plan 9 Um es durchgehend zu verwenden, und dann ihren Erfolg mit X/Open zurückversorgten, was es als Spezifikation für FSS-UTF akzeptierte.^[66]

UTF-8 wurde erstmals offiziell am vorgestellt Usenix Konferenz in San Diegovom 25. bis 29. Januar 1993. Die Internettechnik-Arbeitsgruppe Angenommen UTF-8 in seiner Richtlinie zu Charaktersätzen und Sprachen in RFC 2277 (BCP 18) für zukünftige Internetstandards ersetzen Einzel -Byte -Zeichensätze wie zum Beispiel Latein-1 In älteren RFCs.^[68]

Im November 2003 wurde UTF-8 durch eingeschränkt von RFC 3629 die Einschränkungen der Einschränkungen der UTF-16 Charaktercodierung: explizit verbotene Codepunkte, die den hohen und niedrigen Ersatzzeichen entsprechen, wurden mehr als 3% der Drei-Byte-Sequenzen entfernt und endet bei U+10ffff, mehr als 48% der vier Byte-Sequenzen und alle fünf und sechs -Byte -Sequenzen.

Standards

In verschiedenen Standarddokumenten gibt es mehrere aktuelle Definitionen von UTF-8:

• RFC3629 / STD 63 (2003), das UTF-8 als Standard-Internet-Protokollelement festlegt
• RFC5198 definiert UTF-8 NFC Für Netzwerk Interchange (2008)
• ISO/IEC 10646: 2014 §9.1 (2014)^[69]
• Der Unicode Standard, Version 11.0 (2018)^[70]

Sie ersetzen die Definitionen in den folgenden veralteten Werken:

• Der Unicode Standard, Version 2.0, Anhang A (1996)
• ISO / IEC 10646-1: 1993 Änderung 2 / Annex R (1996)
• RFC2044 (1996)
• RFC2279 (1998)
• Der Unicode Standard, Version 3.0, §2.3 (2000) plus Corrigendum Nr. 1: UTF-8 kürzestes Formular (2000)
• Unicode Standard Anhang Nr. 27: Unicode 3.1 (2001)^[71]
• Der Unicode Standard, Version 5.0 (2006)^[72]
• Der Unicode Standard, Version 6.0 (2010)^[73]

Sie sind alle in ihrer allgemeinen Mechanik gleich, wobei die Hauptunterschiede zu Problemen wie dem zulässigen Bereich der Codepunktwerte und der sicheren Handhabung von ungültigen Eingaben bestehen.

Vergleich mit anderen Codierungen

Einige der wichtigsten Merkmale dieser Codierung sind wie folgt:

• Rückwärtskompatibilität: Rückwärtskompatibilität mit ASCII und der enormen Menge an Software, die zum Verarbeiten von Asciii-codierter Text entwickelt wurde, war die Hauptantriebskraft für die Gestaltung von UTF-8. In UTF-8 sind einzelne Bytes mit Werten im Bereich von 0 bis 127 direkt an Unicode-Codepunkte im ASCII-Bereich abgebildet. Einzelne Bytes in diesem Bereich repräsentieren Zeichen wie in ASCII. Darüber hinaus erscheinen 7-Bit-Bytes (Bytes, bei denen das bedeutendste Bit 0 ist) niemals in einer Multi-Byte-Sequenz und keine gültigen Multi-Byte-Sequenz-Decodes zu einem ASCII-Codepunkt. Eine Sequenz von 7-Bit-Bytes ist sowohl gültigem ASCII als auch gültiges UTF-8, und unter beiden Interpretationen repräsentiert die gleiche Zeichenfolge von Zeichen. Daher repräsentieren die 7-Bit-Bytes in einem UTF-8-Stream alle und nur die ASCII-Zeichen im Stream. So funktionieren viele Textprozessoren, Parsers, Protokolle, Dateiformate, Textdisplay-Programme usw., die ASCII-Zeichen für Formatierungs- und Steuerzwecke verwenden, weiterhin wie beabsichtigt, indem der UTF-8-Byte-Stream als Sequenz von Single- Byte-Zeichen, ohne die Multi-Byte-Sequenzen zu dekodieren. ASCII-Zeichen, an denen sich die Verarbeitung dreht, wie Zeichensetzung, Whitespace und Steuerzeichen, werden niemals als Multi-Byte-Sequenzen codiert. Es ist daher sicher für solche Prozessoren, die Multi-Byte-Sequenzen einfach zu ignorieren oder durchzuführen, ohne sie zu entschlüsseln. Zum Beispiel kann ASCII -Whitespace verwendet werden Tokenize ein UTF-8-Stream in Wörter; ASCII-Zeilen-Feeds können verwendet werden, um einen UTF-8-Stream in Linien aufzuteilen. und ASCII-NUL-Zeichen können verwendet werden, um UTF-8-kodierte Daten in null-terminierte Zeichenfolgen aufzuteilen. In ähnlicher Weise werden viele Formatketten, die von Bibliotheksfunktionen wie "printf" verwendet werden, die UTF-8-kodierten Eingabedargumente korrekt verarbeitet.
• Fallback und automatische Erkennung: Nur eine kleine Untergruppe möglicher Byte-Zeichenfolgen ist eine gültige UTF-8-Zeichenfolge: Die Bytes C0, C1 und F5 bis FF können nicht erscheinen, und Bytes mit dem hohen Bit-Set müssen paarweise und andere Anforderungen sein. Es ist äußerst unwahrscheinlich, dass ein lesbarer Text in jedem erweiterte ASCII ist gültig utf-8. Ein Teil der Popularität von UTF-8 ist darauf zurückzuführen, dass diese auch für diese eine Form der Rückwärtskompatibilität bereitgestellt werden. Ein UTF-8-Prozessor, der fälschlicherweise erweiterte ASCII empfängt, kann dies mit sehr hoher Zuverlässigkeit "automatisch erkennen". Fallback -Fehler sind falsch negative, und diese werden selten sein. Darüber hinaus ist in vielen Anwendungen, wie z. B. der Textanzeige, die Folge eines falschen Fallbacks normalerweise gering.^{[Originalforschung?]} Ein UTF-8-Stream kann einfach Fehler enthalten, was dazu führt, dass das automatische Erkennungsschema falsch-positive Ergebnisse erzeugt. Die automatische Erkennung ist jedoch in den meisten Fällen erfolgreich, insbesondere bei längeren Texten, und wird weit verbreitet. Es arbeitet auch daran, 8-Bit Datei.
• Präfixcode: Das erste Byte zeigt die Anzahl der Bytes in der Sequenz an. Das Lesen eines Streams kann jede einzelne vollständig empfangene Sequenz sofort dekodieren, ohne zuerst auf das erste Byte einer nächsten Sequenz oder auf eine Anzeige des Streams zu warten. Die Länge von Multi-Byte-Sequenzen wird leicht von Menschen bestimmt, da es einfach die Anzahl der 1S-Anzahl von 1S in der führenden Byte ist. Ein falscher Zeichen wird nicht dekodiert, wenn ein Strom mit der Mitte der Sequenz endet.
• Selbstsynchronisation: Die führenden Bytes und die Fortsetzung von Bytes teilen keine Werte (Fortsetzung Bytes beginnen mit den Bits 10 während einzelne Bytes mit beginnen mit 0 und längere Lead -Bytes beginnen mit 11). Dies bedeutet, dass eine Suche die Sequenz für einen Zeichen, das mitten in einem anderen Charakter beginnt, nicht versehentlich findet. Dies bedeutet auch, dass der Beginn eines Charakters aus einer zufälligen Position gefunden werden kann, indem Sie höchstens 3 Bytes unterstützen, um das führende Byte zu finden. Ein falscher Zeichen wird nicht dekodiert, wenn ein Stream mit der Mitte der Sequenz beginnt und eine kürzere Sequenz niemals in einem längeren auftritt.
• Sortierreihenfolge: Die ausgewählten Werte der führenden Bytes bedeuten, dass eine Liste von UTF-8-Zeichenfolgen in Codepunktreihenfolge sortiert werden kann, indem die entsprechenden Byte-Sequenzen sortiert werden.

Single-Byte

• UTF-8 kann jeden codieren Unicode -Zeichen, vermeiden Sie die Notwendigkeit, herauszufinden und einzustellen "Codepage"oder anderweitig angeben, welcher Zeichensatz verwendet wird, und gleichzeitig die Ausgabe in mehreren Skripten zuzulassen. Für viele Skripte gab es mehr als eine Einzelbyte-Codierung in der Verwendung. Selbst wenn ich das Wissen, dass das Skript nicht ausreicht .
• Die Bytes 0xfe und 0xff werden nicht angezeigt, sodass ein gültiger UTF-8-Stream niemals mit dem UTF-16 übereinstimmt Byte -Bestellmarke und kann daher nicht damit verwechselt werden. Das Fehlen von 0xff (0377) beseitigt auch die Notwendigkeit, diesem Byte in entkommen Telnet (und FTP -Steuerverbindung).
• Der utf-8-codierte Text ist größer als spezialisierte Einzelbyte-Codierungen mit Ausnahme von einfachen ASCII-Zeichen. Im Fall von Skripten, die 8-Bit kyrillisch und griechisches Alphabet Codeseiten), Zeichen in UTF-8 sind doppelt so groß. Für einige Skripte wie z. Thai und Devanagari (Das wird von verschiedenen südasiatischen Sprachen verwendet) Charaktere verdreifachen sich in der Größe. Es gibt sogar Beispiele, bei denen ein einzelnes Byte in Unicode in einen zusammengesetzten Charakter verwandelt und somit in UTF-8 sechsmal größer ist. Dies hat Einwände in Indien und anderen Ländern verursacht.
• Es ist in UTF-8 (oder einer anderen Multi-Byte-Codierung) möglich, sich zu teilen oder kürzen eine Schnur in der Mitte eines Zeichens. Wenn die beiden Teile später vor der Interpretation als Zeichen nicht wieder aufgenommen werden, kann dies eine ungültige Sequenz sowohl am Ende des vorherigen Abschnitts als auch zu Beginn des nächsten einführen, und einige Decoder erhalten diese Bytes nicht und führen zu Datenverlust. Da UTF-8 sich selbst synchronisiert, wird dies jedoch niemals einen anderen gültigen Charakter einführen, und es ist auch ziemlich einfach, den Kürzungspunkt nach rückwärts zum Beginn eines Charakters zu bewegen.
• Wenn die Codepunkte alle gleich groß sind, sind die Messungen einer festen Anzahl von ihnen einfach. Aufgrund der Ascii-Ära-Dokumentation, in der "Charakter" als Synonym für "Byte" verwendet wird, wird dies oft als wichtig angesehen. Durch Messen von String-Positionen mit Bytes anstelle von "Zeichen" können die meisten Algorithmen einfach und effizient für UTF-8 angepasst werden. Die Suche nach einer Zeichenfolge innerhalb einer langen Zeichenfolge kann zum Beispiel Byte von Byte durchgeführt werden. Die Eigenschaftssynchronisationseigenschaft verhindert falsch positive Ergebnisse.

Andere Multi-Byte

• UTF-8 kann jeden codieren Unicode Charakter. Files in different scripts can be displayed correctly without having to choose the correct code page or font. For instance, Chinese and Arabic can be written in the same file without specialized markup or manual settings that specify an encoding.
• UTF-8 ist Selbstsynchronisation: character boundaries are easily identified by scanning for well-defined bit patterns in either direction. If bytes are lost due to error or Korruption, one can always locate the next valid character and resume processing. If there is a need to shorten a string to fit a specified field, the previous valid character can easily be found. Many multi-byte encodings such as Schicht jis are much harder to resynchronize. Dies bedeutet auch, dass das Byte-orientiert String-Suchalgorithmen can be used with UTF-8 (as a character is the same as a "word" made up of that many bytes), optimized versions of byte searches can be much faster due to hardware support and lookup tables that have only 256 entries. Self-synchronization does however require that bits be reserved for these markers in every byte, increasing the size.
• Efficient to encode using simple Bitgewise Operations. UTF-8 does not require slower mathematical operations such as multiplication or division (unlike Schicht jis, GB 2312 and other encodings).
• UTF-8 will take more space than a multi-byte encoding designed for a specific script. East Asian legacy encodings generally used two bytes per character yet take three bytes per character in UTF-8.

UTF-16

• Byte encodings and UTF-8 are represented by byte arrays in programs, and often nothing needs to be done to a function when converting source code from a byte encoding to UTF-8. UTF-16 is represented by 16-bit word arrays, and converting to UTF-16 while maintaining compatibility with existing ASCII-based programs (such as was done with Windows) requires jeder API and data structure that takes a string to be duplicated, one version accepting byte strings and another version accepting UTF-16. If backward compatibility is not needed, all string handling still must be modified.
• Text encoded in UTF-8 will be smaller than the same text encoded in UTF-16 if there are more code points below U+0080 than in the range U+0800..U+FFFF. This is true for all modern European languages. It is often true even for languages like Chinese, due to the large number of spaces, newlines, digits, and HTML markup in typical files.
• Most communication (e.g. HTML and IP) and storage (e.g. for Unix) was designed for a Strom von Bytes. A UTF-16 string must use a pair of bytes for each code unit:
  • The order of those two bytes becomes an issue and must be specified in the UTF-16 protocol, such as with a Byte -Bestellmarke.
  • Wenn ein seltsam number of bytes is missing from UTF-16, the whole rest of the string will be meaningless text. Any bytes missing from UTF-8 will still allow the text to be recovered accurately starting with the next character after the missing bytes.

Derivate

The following implementations show slight differences from the UTF-8 specification. They are incompatible with the UTF-8 specification and may be rejected by conforming UTF-8 applications.

CESU-8

Unicode Technical Report #26^[74] assigns the name CESU-8 to a nonstandard variant of UTF-8, in which Unicode characters in ergänzende Ebenen are encoded using six bytes, rather than the four bytes required by UTF-8. CESU-8 encoding treats each half of a four-byte UTF-16 surrogate pair as a two-byte UCS-2 character, yielding two three-byte UTF-8 characters, which together represent the original supplementary character. Unicode characters within the Grundlegende mehrsprachige Ebene appear as they would normally in UTF-8. The Report was written to acknowledge and formalize the existence of data encoded as CESU-8, despite the Unicode -Konsortium discouraging its use, and notes that a possible intentional reason for CESU-8 encoding is preservation of UTF-16 binary collation.

CESU-8 encoding can result from converting UTF-16 data with supplementary characters to UTF-8, using conversion methods that assume UCS-2 data, meaning they are unaware of four-byte UTF-16 supplementary characters. It is primarily an issue on operating systems which extensively use UTF-16 internally, such as Microsoft Windows.

Im Oracle -Datenbank, das UTF8 character set uses CESU-8 encoding, and is deprecated. Das AL32UTF8 character set uses standards-compliant UTF-8 encoding, and is preferred.^[75][76]

CESU-8 is prohibited for use in HTML5 Unterlagen.^[77][78][79]

MySQL UTF8MB3

Im Mysql, das utf8mb3 character set is defined to be UTF-8 encoded data with a maximum of three bytes per character, meaning only Unicode characters in the Grundlegende mehrsprachige Ebene (i.e. from UCS-2) sind unterstützt. Unicode characters in ergänzende Ebenen are explicitly not supported. utf8mb3 is deprecated in favor of the utf8mb4 character set, which uses standards-compliant UTF-8 encoding. utf8 is an alias for utf8mb3, but is intended to become an alias to utf8mb4 in a future release of MySQL.^[80] It is possible, though unsupported, to store CESU-8 encoded data in utf8mb3, by handling UTF-16 data with supplementary characters as though it is UCS-2.

Modifiziert UTF-8

Modifiziert UTF-8 (MUTF-8) originated in the Java -Programmiersprache. In Modified UTF-8, the Nullcharakter (U+0000) uses the two-byte overlong encoding 11000000 10000000 (hexadezimal C0 80), Anstatt von 00000000 (hexadezimal 00).^[81] Modified UTF-8 strings never contain any actual null bytes but can contain all Unicode code points including U+0000,^[82] which allows such strings (with a null byte appended) to be processed by traditional NULL-terminierte Zeichenfolge Funktionen. Alle bekannten modifizierten UTF-8-Implementierungen behandeln auch die Ersatzpaare wie in CESU-8.

In der normalen Verwendung unterstützt die Sprache das Standard-UTF-8 beim Lesen und Schreiben von Zeichenfolgen durch InputStreamReader und Ausgangsstreamwriter (Wenn es sich um den Standardzeichen der Plattform handelt oder wie vom Programm angefordert). Es verwendet jedoch modifizierte UTF-8 für Objekt Serialisierung^[83] unter anderen Anwendungen von Dateneingabe und Datenausgabefür die Java Native Interface,^[84] und zum Einbetten konstanter Saiten in Klassendateien.^[85]

Das Dex -Format definiert durch Dalvik Verwendet auch das gleiche modifizierte UTF-8, um Stringwerte darzustellen.^[86] Tcl Verwendet auch das gleiche modifizierte UTF-8^[87] als Java für die interne Darstellung von Unicode-Daten, verwendet aber strikte CESU-8 für externe Daten.

WTF-8

In WTF-8 (wobaches Transformationsformat, 8-Bit) ungepaart Ersatzhälften (U+D800 durch U+DFFF) sind erlaubt.^[88] Dies ist notwendig, um möglicherweise invaliden UTF-16 wie Windows-Dateinamen zu speichern. Viele Systeme, die sich mit UTF-8 befassen, funktionieren auf diese Weise, ohne es als eine andere Codierung zu betrachten, da es einfacher ist.^[89]

(Der Begriff "WTF-8" wurde ebenfalls humorvoll verwendet, um sich zu beziehen fälschlicherweise doppelt kodierter UTF-8^[90][91] manchmal mit der Implikation, dass CP1252 Bytes sind die einzigen, die codiert sind.)^[92]

Pep 383

Version 3 der Python -Programmiersprache Behandelt jedes Byte eines ungültigen UTF-8-Bytestream als Fehler (siehe auch ändert sich mit dem neuen UTF-8-Modus in Python 3.7^[93]); Dies ergibt 128 verschiedene mögliche Fehler. Es wurden Erweiterungen erstellt, damit eine Byte-Sequenz, von der angenommen wird, dass sie UTF-8 ist Bytes zur Ausgabe UTF-8. Der häufigste Ansatz besteht darin, die Codes in U+DC80 zu übersetzen ... U+DCFF, die niedrige (nachfolgende) Ersatzwerte und damit "ungültig" UTF-16 sind, wie von verwendet von Python's Pep 383 (oder "surrogateescape") Ansatz.^[94] Eine andere Kodierung rief Mirbs Optu-8/16 konvertiert sie in u+EF80 ... u+efff in a Privatnutzungsbereich.^[95] In beiden Ansätzen wird der Bytewert in den niedrigen acht Bits des Ausgabescodepunkts codiert.

Diese Codierungen sind sehr nützlich, da sie vermeiden, dass sie mit "ungültigen" Byte -Zeichenfolgen bis viel später, wenn überhaupt, umzugehen und "Text" und "Daten" -Byte -Arrays das gleiche Objekt zu ermöglichen. Wenn ein Programm UTF-16 intern verwenden möchte, müssen diese Dateinamen erhalten und verwenden, die ungültige UTF-8 verwenden können.^[96] Da die Windows-Dateisystem-API UTF-16 verwendet, ist die Notwendigkeit, ungültiges UTF-8 zu unterstützen, weniger.^[94]

Damit die Codierung reversibel ist, müssen die Standard-UTF-8-Codierungen der Codepunkte für fehlerhafte Bytes als ungültig angesehen werden. Dies macht die Codierung mit WTF-8 oder CESU-8 (jedoch nur für 128 Codepunkte) unvereinbar. Bei der erneuten Kodierung ist es notwendig, auf Sequenzen von Fehlercodepunkten zu achten, die in gültige UTF-8 zurückkehren, die möglicherweise von böswilliger Software verwendet werden, um unerwartete Zeichen in die Ausgabe zu erhalten, obwohl dies keine ASCII-Zeichen erzeugen kann, sodass sie berücksichtigt werden. vergleichsweise sicher, da böswillige Sequenzen (wie z. Cross-Site-Scripting) Normalerweise verlassen Sie sich auf ASCII -Zeichen.^[96]

Siehe auch

• ALT -Code
• Vergleich der E -Mail -Clients § Funktionen
• Vergleich von Unicode -Codierungen
  • GB 18030
  • UTF-EBCDIC
• Ikonv
• Prozentualender § Aktueller Standard
• Specials (Unicode Block)
• Unicode und E -Mail
• Unicode und HTML
  • Zeichenkodierungen in HTML

Anmerkungen

Verweise

Externe Links

• Original UTF-8-Papier (oder pdf) zum Plan 9 von Bell Labs
• UTF-8-Testseiten:
  • Andreas Prilop Archiviert 2017-11-30 bei der Wayback -Maschine
  • Jost Gippert
  • World Wide Web Konsortium
• UNIX/Linux: UTF-8/Unicode FAQ, Linux unicode howto, UTF-8 und Gentoo
• Zeichen, Symbole und das Unicode -Wunder an Youtube