UTF-8 (hat UCS Transformation GeFormat8-bissen), ist eine variable Breite, die verschlüsselt, der jeden Charakter in der Codierung von Unicode vertreten kann.

Es wurde für die rückwärts gerichtete Vereinbarkeit mit ASCII entworfen und die Komplikationen von endianness und Byte-Ordnungszeichen in UTF-16 und UTF-32 zu vermeiden.

UTF-8 ist die dominierende Charakter-Verschlüsselung für das Weltweb geworden, für mehr als Hälfte aller Webseiten verantwortlich seiend. Internet Engineering Task Force (IETF) verlangt, dass alle Internetprotokolle die Verschlüsselung identifizieren, die für Charakter-Daten verwendet ist, und der unterstützte Charakter encodings muss UTF-8 einschließen. Internet Mail Consortium (IMC) empfiehlt, dass alle E-Mail-Programme im Stande sind, Post mit UTF-8 zu zeigen und zu schaffen. UTF-8 wird auch als die Verzug-Charakter-Verschlüsselung in Betriebssystemen, Programmiersprachen, APIs und Softwareanwendungen zunehmend verwendet.

UTF-8 verschlüsselt jeden der 1,112,064 Codepunkte in der Codierung von Unicode mit einem bis vier 8-Bit-Bytes (genannte "Oktette" im Unicode Standard). Codepunkte mit niedrigeren numerischen Werten (d. h., codieren Sie früher Positionen in der Codierung von Unicode, die dazu neigen, öfter in der Praxis vorzukommen), werden mit weniger Bytes verschlüsselt. Die ersten 128 Charaktere von Unicode, die isomorph ASCII entsprechen, werden mit einem einzelnen Oktett mit demselben binären Wert wie ASCII verschlüsselt, gültigen ASCII Text gültigen UTF-8-encoded Unicode ebenso machend.

Der offizielle IANA-Code für die UTF-8 Charakter-Verschlüsselung ist.

Geschichte

Bis zum Anfang 1992 war die Suche für eine gute Verschlüsselung des Byte-Stroms von Mehrbyte-Codierungen auf. Der Draft-ISO 10646 Standard hat einen nichterforderlichen Anhang genannt UTF-1 enthalten, der eine Verschlüsselung des Byte-Stroms seiner 32-Bit-Codepunkte zur Verfügung gestellt hat. Diese Verschlüsselung war auf dem Leistungsboden nicht befriedigend, aber hat wirklich den Begriff eingeführt, dass Bytes in der ASCII Reihe 0-127 sich in UTF vertreten, dadurch rückwärts gerichtete Vereinbarkeit zur Verfügung stellend.

Im Juli 1992 suchte das X/Open Komitee XoJIG nach einer besseren Verschlüsselung. Dave Prosser von Unix Systemlaboratorien hat einen Vorschlag für denjenigen vorgelegt, der schnellere Durchführungseigenschaften hatte und die Verbesserung eingeführt hat, die ASCII 7-Bit-Charaktere nur selbst vertreten würden; alle Mehrbyte-Folgen würden nur Bytes einschließen, wo das hohe Bit gesetzt wurde.

Im August 1992 wurde dieser Vorschlag von einem Vertreter von IBM X/Open zu Interessenten in Umlauf gesetzt. Ken Thompson des Plans 9, den die Betriebssystemgruppe an Glockenlaboratorien dann eine entscheidende Modifizierung zur Verschlüsselung gemacht hat, um ihm zu erlauben, zu selbstsynchronisieren, meinend, dass es nicht notwendig war, vom Anfang der Schnur zu lesen, Codepunkt-Grenzen zu finden. Das Design von Thompson wurde am 2. September 1992 entworfen, auf einem Set in einem Tischgast von New Jersey damit Rauben Hecht Aus. Die folgenden Tage, der Hecht und Thompson haben es durchgeführt und haben Plan 9 aktualisiert, es überall zu verwenden, und haben dann ihren Erfolg zurück X/Open mitgeteilt.

UTF-8 wurde zuerst auf der USENIX Konferenz in San Diego vom 25-29 Januar 1993 offiziell präsentiert.

Im November 2003 wurde UTF-8 durch RFC 3629 zu vier Bytes eingeschränkt, um die Einschränkungen der UTF-16 Charakter-Verschlüsselung zu vergleichen.

Beschreibung

Das Design UTF‑8 wird im Tisch des Schemas, wie ursprünglich vorgeschlagen, von Dave Prosser am leichtesten gesehen und nachher von Ken Thompson modifiziert:

Die hervorstechenden Eigenschaften des obengenannten Schemas sind wie folgt:

1. Ein-Byte-Codes werden nur für die ASCII-Werte 0 bis 127 verwendet. In diesem Fall hat der UTF-8-Code denselben Wert wie der ASCII-Code. Das Bit der hohen Ordnung dieser Codes ist immer 0.
2. Codepoints, die größer sind als 127, werden durch Mehrbyte-Folgen vertreten, die aus einem Hauptbyte und einem oder mehr Verlängerungsbytes zusammengesetzt sind. Das Hauptbyte hat zwei oder mehr hohe Ordnung 1s, während Verlängerungsbytes alle '10' in der Position der hohen Ordnung haben.
3. Die Zahl der hohen Ordnung 1s im Hauptbyte einer Mehrbyte-Folge zeigt die Zahl von Bytes in der Folge an, so dass die Länge der Folge bestimmt werden kann, ohne die Verlängerungsbytes zu untersuchen.
4. Einzelne Bytes, Hauptbytes und Verlängerungsbytes teilen Werte nicht. Das macht das Schema "selbst das Synchronisieren", dem Anfang eines Charakters erlaubend, dadurch gefunden zu werden, an den meisten fünf Bytes (drei Bytes im wirklichen UTF‑8, wie erklärt, unten) zu unterstützen.
5. Das Schema konnte außer 6-Byte-Folgen und den Leitungsbytes erweitert werden FE und FF sind dafür verfügbar.

Die ersten 128 Charaktere (US-ASCII) brauchen ein Byte. Die folgenden 1,920 Charaktere brauchen zwei Bytes, um zu verschlüsseln. Das schließt lateinische Briefe mit diakritischen Zeichen und Charakteren vom griechischen, dem Kyrillischen, dem koptischen, dem armenischen, dem hebräischen, dem arabischen, Syriac und den Tāna Alphabeten ein. Drei Bytes sind für Charaktere im Rest des Grundlegenden Mehrsprachigen Flugzeugs erforderlich (der eigentlich alle Charaktere in der üblichen Anwendung enthält). Vier Bytes sind für Charaktere in den anderen Flugzeugen von Unicode erforderlich, die weniger allgemeine CJK Charaktere und verschiedene historische Schriften und mathematische Symbole einschließen.

Die ursprüngliche Spezifizierung hat Zahlen bis zu 31 Bit (die ursprüngliche Grenze der Universalen Codierung) bedeckt. Im November 2003 wurde UTF-8 durch RFC 3629 eingeschränkt, um an U + zu enden, um die Einschränkungen der UTF-16 Charakter-Verschlüsselung zu vergleichen. Das hat alle 5- und 6-Byte-Folgen und ungefähr Hälfte der 4-Byte-Folgen entfernt.

Beispiele

Lay-Out von Codepage

Legende:

Zellen sind Kontrollcharaktere, Zellen sind Zeichensetzung, Zellen sind Ziffern, und Zellen sind ASCII Briefe.

Zellen mit einem großen Punkt sind Verlängerungsbytes. Die hexadecimal Zahl gezeigt nach "+" ist Pluszeichen der Wert der 6 Bit, die sie hinzufügen.

Zellen sind die Anfang-Bytes für eine Folge von vielfachen Bytes, die am linken Rand der Reihe gezeigte Länge. Der Text zeigt die Blöcke von Unicode, die durch Folgen verschlüsselt sind, die mit diesem Byte anfangen, und der in der Zelle gezeigte Hexadecimal-Codepunkt ist das verschlüsselte Verwenden des Werts des niedrigsten Charakters dieses Anfang-Byte. Als ein Anfang-Byte sowohl überlangen als auch gültigen encodings bilden konnte, wird der niedrigste non-overlong-encoded codepoint gezeigt, durch ein Sternchen "*" gekennzeichnet.

Zellen müssen in einer gültigen UTF-8 Folge nie erscheinen. Die ersten zwei (C0 und C1) konnten nur für die überlange Verschlüsselung von grundlegenden ASCII Charakteren verwendet werden. Die restlichen roten Zellen zeigen Anfang-Bytes von Folgen an, die nur Zahlen verschlüsseln konnten, die größer sind als die 0x10FFFF Grenze von Unicode. Das Byte 244 (Hexe 0xF4) konnte auch einige Werte verschlüsseln, die größer sind als 0x10FFFF; solch eine Folge ist auch ungültig.

Ungültige Byte-Folgen

Nicht alle Folgen von Bytes sind gültiger UTF-8. Ein UTF-8 Decoder sollte bereit sein zu:

• die roten ungültigen Bytes im obengenannten Tisch
• ein unerwartetes Verlängerungsbyte
• ein Anfang-Byte, das nicht von genug Verlängerungsbytes gefolgt ist
• eine Folge, die zu einem Wert decodiert, der eine kürzere Folge (eine "überlange Form") verwenden sollte.
• Eine 4-Byte-Folge (mit F4 anfangend), der zu einem Wert decodiert, der größer ist als U+10FFFF

Viele frühere Decoder würden glücklich versuchen, diese zu decodieren. Sorgfältig gefertigter ungültiger UTF-8 konnte sie auslassen entweder oder ASCII Charaktere wie NUL, Hieb oder Notierungen schaffen lassen. Ungültiger UTF-8 ist verwendet worden, um Sicherheitsgültigkeitserklärungen in hohen Profil-Produkten einschließlich des IIS Webservers des Microsofts und des Katers des Apachen servlet Behälter zu umgehen.

Staaten "Durchführungen des Entzifferungsalgorithmus MÜSSEN gegen die Entzifferung ungültiger Folgen schützen." Der Unicode Standard verlangt Decoder zu "... Vergnügen jede schlecht-gebildete Codeeinheitsfolge als eine Fehlerbedingung. Das versichert, dass es weder interpretieren noch eine schlecht-gebildete Codeeinheitsfolge ausstrahlen wird."

Viele UTF-8 Decoder werfen Ausnahmen beim Antreffen auf Fehler, da solche Fehler darauf hinweisen, dass der Eingang nicht eine UTF-8-Schnur überhaupt ist. Das kann drehen, was harmlose Fehler sonst sein würde (eine Nachricht wie "keine solche Datei" erzeugend), in eine Leugnung des Dienstprogrammfehlers. Zum Beispiel würde Pythonschlange 3.0 sofort abgehen, wenn die Befehl-Linie ungültigen UTF-8 enthielte, so war es unmöglich, ein Pythonschlange-Programm zu schreiben, das solchen Eingang behandeln konnte.

Eine immer populärere Auswahl ist, Fehler mit einer getrennten API, und für Konverter zu entdecken, um das erste Byte zu einem Ersatz zu übersetzen und fortzusetzen, mit dem folgenden Byte grammatisch zu analysieren. Populärer Ersatz ist:

• Das Ersetzungszeichen "�" (U+FFFD)
• Der ungültige Code von Unicode spitzt U+DC80 an.. U+DCFF, wo die niedrigen 8 Bit der Wert des Bytes sind.
• Interpretieren Sie die Bytes gemäß ISO-8859-1 oder CP1252.

Das Ersetzen von Fehlern ist "lossy": Mehr als eine UTF-8-Schnur wandelt sich zu demselben Ergebnis von Unicode um. Deshalb sollte der ursprüngliche UTF-8 versorgt werden, und Übersetzung sollte nur verwendet werden, wenn man den Text dem Benutzer zeigt.

Ungültige Codepunkte

Gemäß der UTF-8 Definition (RFC 3629) ist der hohe und niedrige Stellvertreter, der halb durch UTF-16 (U+D800 durch U+DFFF) verwendet ist, nicht gesetzliche Werte von Unicode, und die UTF-8-Verschlüsselung von ihnen ist eine ungültige Byte-Folge und sollte so, wie beschrieben, oben behandelt werden.

Ob eine wirkliche Anwendung das mit dem Stellvertreter tun sollte, sind Hälften diskutabel. Das Erlauben von ihnen erlaubt lossless Lagerung von ungültigem UTF-16, und erlaubt CESU, der (beschrieben unten) verschlüsselt, decodiert zu werden. Es gibt andere Codepunkte, die viel wichtiger sind, um zu entdecken und, wie der umgekehrte-BOM U+FFFE oder die C1-Steuerungen zurückzuweisen, die durch die unpassende Konvertierung des CP1252 Textes oder doppelte Verschlüsselung von UTF-8 verursacht sind. Diese sind im HTML ungültig.

Offizieller Name und Varianten

Der offizielle Name ist "UTF-8". Alle Briefe sind Großschrift, und der Name wird mit Bindestrich geschrieben. Diese Rechtschreibung wird in allen Dokumenten in Zusammenhang mit der Verschlüsselung verwendet.

Wechselweise kann der Name "utf-8" durch alle Standards verwendet werden, die sich der Liste von Internet Assigned Numbers Authority (IANA) anpassen (die CSS, HTML, XML und HTTP Kopfbälle einschließen), weil die Behauptung unempfindlicher Fall ist.

Andere Beschreibungen, die den Bindestrich weglassen oder ihn durch einen Raum, wie "utf8" oder "UTF 8" ersetzen, werden als richtig durch die Regierungsstandards nicht akzeptiert. Trotzdem können die meisten Agenten wie Browser sie verstehen, und so haben Standards vorgehabt, vorhandene Praxis zu beschreiben (wie HTML5), kann ihre Anerkennung effektiv verlangen.

MySQL lässt den Bindestrich in der folgenden Abfrage weg:

BESTIMMEN SIE NAMEN 'utf8'

Ableitungen

Die folgenden Durchführungen zeigen geringe Unterschiede zur UTF-8 Spezifizierung. Sie sind mit der UTF-8 Spezifizierung unvereinbar.

CESU-8

Viele Stücke der Software haben UTF-8 Konvertierungen für UCS-2 Daten hinzugefügt und haben ihre UTF-8 Konvertierung nicht verändert, als UCS-2 durch den Stellvertreter-Paar ersetzt wurde, der UTF-16 unterstützt. Das Ergebnis besteht darin, dass jede Hälfte eines UTF-16 Stellvertreter-Paares als UTF-8 seine eigene 3-Byte-Verschlüsselung verschlüsselt wird, auf 6-Byte-Folgen aber nicht 4 für Charaktere außerhalb des Grundlegenden Mehrsprachigen Flugzeugs hinauslaufend. Orakel-Datenbanken verwenden das, sowie Java und Tcl, wie beschrieben, unten, und wahrscheinlich sehr viel von anderer Windows-Software, wo die Programmierer die Kompliziertheiten von UTF-16 nicht gewusst haben. Obwohl der grösste Teil des Gebrauchs zufällig ist, ist ein angenommener Vorteil, dass das UTF-16 binäre Sortieren-Ordnung bewahrt, wenn CESU-8 sortiert binär ist.

Modifizierter UTF-8

In Modifiziertem UTF-8 wird der ungültige Charakter (U+0000) als 0xC0,0x80 verschlüsselt; das ist nicht gültiger UTF-8, weil es nicht die kürzestmögliche Darstellung ist.

Modifizierte UTF-8-Schnuren enthalten nie irgendwelche wirklichen ungültigen Bytes, aber können alle Codepunkte von Unicode einschließlich U+0000 enthalten, der solchen Schnuren (mit einem ungültigen Byte angehangen) erlaubt, durch traditionelle ungültig begrenzte Zeichenkettenfunktionen bearbeitet zu werden.

Alle bekannte Modifizierte UTF-8 Durchführungen behandeln auch die Stellvertreter-Paare als in CESU-8.

Im normalen Gebrauch unterstützt die javanische Programmiersprache normalen UTF-8, wenn sie liest und Schnuren durch schreibt und. Jedoch verwendet es Modifizierten UTF-8 für die Gegenstand-Anordnung für die javanische Eingeborener-Schnittstelle, und um unveränderliche Schnuren in Klassendateien einzubetten. Tcl verwendet auch dasselbe hat UTF-8 als Java für die innere Darstellung von Daten von Unicode modifiziert, aber verwendet strengen CESU-8 für Außendaten.

Byte-Ordnungszeichen

Viele Windows-Programme (einschließlich des Windows-Notizbuches) fügen die Bytes 0xEF, 0xBB, 0xBF am Anfang jedes als UTF-8 gesparten Dokumentes hinzu. Das ist die UTF-8-Verschlüsselung des Byte-Ordnungszeichens (BOM) von Unicode, und wird allgemein einen UTF-8 BOM genannt, wenn auch es für die Byte-Ordnung nicht wichtig ist. Der BOM kann auch erscheinen, wenn eine andere Verschlüsselung mit einem BOM zu UTF-8 übersetzt wird, ohne ihn abzuziehen. Ältere Textaufbereiter können den BOM als "ï" ¿" am Anfang des Dokumentes zeigen.

Der Unicode Standard empfiehlt gegen den BOM für UTF-8. Die Anwesenheit des UTF-8 BOM kann Zwischenfunktionsfähigkeitsprobleme mit der vorhandenen Software verursachen, die UTF-8 sonst behandeln konnte; zum Beispiel:

• Programmiersprache parsers nicht ausführlich entworfen für UTF-8 kann häufig UTF-8 in Schnur-Konstanten und Anmerkungen behandeln, aber kann den BOM am Anfang der Datei nicht grammatisch analysieren.
• Programme, die Dateitypen durch Hauptdarsteller identifizieren, können scheitern, die Datei zu identifizieren, wenn ein BOM da ist, selbst wenn der Benutzer der Datei den BOM auslassen konnte. Ein Beispiel ist die Bude-Syntax von Unix. Ein anderes Beispiel ist Internet Explorer, der Seiten in der Standardweise nur machen wird, wenn es mit einer Dokumententyp-Behauptung anfängt.

Wenn die Vereinbarkeit mit vorhandenen Programmen nicht wichtig ist, konnte der BOM verwendet werden, um UTF-8-Verschlüsselung zu identifizieren. Weil Überprüfung, wenn Text gültiger UTF-8 ist, sehr zuverlässig ist (die Mehrheit von zufälligen Byte-Folgen sind nicht gültiger UTF-8) solcher Gebrauch sollte nicht notwendig sein. Programme, die Information am Anfang einer Datei einfügen, werden diese Identifizierung brechen (ein Beispiel ist Off-Linebrowser, die die entstehende URL-ADRESSE zum Anfang der Datei hinzufügen).

In Japan besonders, "wird UTF-8, der ohne BOM verschlüsselt", manchmal "UTF-8N" genannt.

Vorteile und Nachteile

Allgemein

Vorteile

• Die ASCII Charaktere werden von sich als einzelne Bytes vertreten, die irgendwo anders nicht erscheinen, der UTF-8 mit der Mehrheit von vorhandenen APIs arbeiten lässt, die Byte-Schnuren nehmen, aber nur eine kleine Anzahl von ASCII-Codes besonders behandeln. Das entfernt das Bedürfnis, eine neue Version von Unicode jeder API zu schreiben, und macht es viel leichter, vorhandene Systeme zu UTF-8 umzuwandeln, als jede andere Verschlüsselung von Unicode.
• UTF-8 ist die einzige Verschlüsselung für XML Entitäten, die keinen BOM oder eine Anzeige der Verschlüsselung verlangt.
• UTF-8 und UTF-16 sind der Standard encodings für den Text von Unicode in HTML-Dokumenten mit UTF-8 als die bevorzugte und am meisten verwendete Verschlüsselung.
• UTF-8 Schnuren können als solcher durch einen einfachen heuristischen Algorithmus ziemlich zuverlässig anerkannt werden. Die Wahrscheinlichkeit einer zufälligen Schnur von Bytes, die nicht reiner ASCII ist gültiger UTF-8 zu sein, ist 3.9 % für eine Zwei-Byte-Folge, und nimmt exponential für längere Folgen ab. ISO/IEC 8859-1 wird noch mit geringerer Wahrscheinlichkeit als UTF-8 mis-anerkannt: Die einzigen non-ASCII Charaktere darin würden in Folgen sein müssen, die entweder mit einem akzentuierten Brief oder mit dem Multiplikationssymbol anfangen und mit einem Symbol enden. Das ist ein Vorteil, den die meisten anderen encodings nicht haben, Fehler (mojibake) verursachend, wenn die Empfang-Anwendung nicht erzählt wird und die richtige Verschlüsselung nicht erraten kann. Sogar wortbasierter UTF-16 kann für das Byte encodings falsch sein (wie im "Strauch hat die Tatsachen" Programmfehler verborgen).
• Das Sortieren von UTF-8-Schnuren als Reihe von nicht unterzeichneten Bytes wird dieselben Ergebnisse wie das Sortieren von ihnen gestützt auf Codepunkten von Unicode erzeugen.
• Anderer Byte-basierter encodings kann dieselbe API durchführen. Das bedeutet jedoch, dass die Verschlüsselung identifiziert werden muss. Weil die anderen encodings kaum gültiger UTF-8, eine zuverlässige Weise sein werden durchzuführen, ist das, UTF-8 anzunehmen und auf ein Vermächtnis umzuschalten, das nur verschlüsselt, wenn auf mehrere ungültige UTF-8 Byte-Folgen gestoßen wird.

Nachteile

• Ein UTF-8 parser, der mit jetzigen Versionen des Standards nicht entgegenkommend ist, könnte mehrere verschiedene pseudo-UTF-8 Darstellungen akzeptieren und sie zu derselben Produktion von Unicode umwandeln. Das stellt einen Weg für die Information zur Verfügung, um zu lecken, vorige Gültigkeitserklärungsroutinen haben vorgehabt, Daten in seiner Acht-Bit-Darstellung zu bearbeiten.

Im Vergleich zum einzelnen Byte encodings

Vorteile

• UTF-8 kann jeden Charakter von Unicode verschlüsseln, das Bedürfnis vermeidend, sich zu belaufen und eine "Codeseite" zu setzen oder sonst anzuzeigen, welche Codierung im Gebrauch und der erlaubenden Produktion auf vielfachen Sprachen zur gleichen Zeit ist. Für viele Sprachen hat es Verschlüsselung von mehr als einem einzelnem Byte im Gebrauch gegeben, so sogar wissend, dass die Sprache ungenügende Information war, um es richtig zu zeigen.
• Die Bytes 0xfe und 0xff erscheinen nicht, so vergleicht ein gültiger UTF-8 Strom nie das UTF-16 Byte-Ordnungszeichen und kann so damit nicht verwirrt sein. Die Abwesenheit von 0xFF (\377) beseitigt auch das Bedürfnis, diesem Byte in Telnet (und FTP-Kontrollverbindung) zu entkommen.

Nachteile

• Verschlüsselter Text von UTF-8 ist größer als die passende Verschlüsselung des einzelnen Bytes abgesehen von ASCII einfachen Charakteren. Im Fall von Sprachen, die 8-Bit-Codierungen mit nichtlateinischen Alphabeten verwendet haben, die in der oberen Hälfte (wie die meisten Kyrillischen und griechischen Alphabet-Codeseiten) verschlüsselt sind, werden Briefe in UTF-8 die Größe doppelt sein. Für einige Sprachen wie Thai und der Devanagari des Hindis werden Briefe die Größe dreifach sein (das hat Einwände in Indien und anderen Ländern verursacht).
• Es ist in UTF-8 (oder jede andere Mehrbyte-Verschlüsselung) möglich, eine Schnur in der Mitte eines Charakters zu spalten oder zu stutzen, der auf eine ungültige Schnur hinauslaufen kann. Das wird im richtigen Berühren von UTF-8 nicht geschehen.
• Wenn die Codepunkte Größe alle gleich sind, sind Maße einer festgelegten Zahl von ihnen leicht. Wegen der ASCII-Zeitalter-Dokumentation, wo "Charakter" als ein Synonym für "das Byte" verwendet wird, wird das häufig wichtig betrachtet. Jedoch durch das Messen von Schnur-Positionen mit Bytes statt "Charaktere" können die meisten Algorithmen an UTF-8 leicht und effizient angepasst werden.

Im Vergleich zu anderem Mehrbyte encodings

Vorteile

• UTF-8 verwendet die Codes 0-127 nur für die ASCII Charaktere. Das bedeutet, dass UTF-8 eine ASCII Erweiterung ist und mit der beschränkten Änderung kann, durch die Software unterstützt werden, die eine ASCII Erweiterung unterstützt und non-ASCII Charaktere als freier Text behandelt.
• UTF-8 kann jeden Charakter von Unicode verschlüsseln. Dateien auf verschiedenen Sprachen können richtig gezeigt werden, ohne die richtige Codeseite oder Schriftart wählen zu müssen. Zum Beispiel können Chinesisch und Arabisch (in demselben Text) ohne spezielle Codes eingefügte oder manuelle Einstellungen unterstützt werden, um die Verschlüsselung zu schalten.
• UTF-8 "ist gleichzeitig selbst": Charakter-Grenzen werden leicht gefunden, wenn man entweder vorwärts oder umgekehrt sucht. Wenn Bytes wegen des Fehlers oder der Bestechung verloren werden, kann man immer den Anfang des folgenden Charakters ausfindig machen und so den Schaden beschränken. Viele Mehrbyte encodings sind viel härter gleichzeitig wiederzusein.
• Orientierte Schnur-Suche-Algorithmus jedes Bytes kann mit UTF-8 Daten verwendet werden, da die Folge von Bytes für einen Charakter irgendwo anders nicht vorkommen kann. Etwas ältere variable Länge encodings (wie Verschiebung JIS) hatte dieses Eigentum nicht und hat so Schnur vergleichende Algorithmen eher kompliziert gemacht. In Shift-JIS konnten das Endbyte eines Charakters und das erste Byte des folgenden Charakters wie ein anderer gesetzlicher Charakter, etwas aussehen, was in UTF-8 nicht geschehen kann.
• Effizient, um verwendende einfache Bit-Operationen zu verschlüsseln. UTF-8 verlangt langsamere mathematische Operationen wie Multiplikation oder Abteilung (verschieden vom veralteten UTF-1 nicht, der verschlüsselt).

Nachteile

• Für bestimmte Sprachen wird UTF-8 mehr Raum nehmen als eine ältere Mehrbyte-Verschlüsselung. Ostasiatische Schriften haben allgemein zwei Bytes pro Charakter in ihrem Mehrbyte encodings noch nehmen drei Bytes pro Charakter in UTF-8.

Im Vergleich zu UTF-16

Vorteile

• Ein Textbyte-Strom kann nicht losslessly sein, der zu UTF-16 wegen der möglichen Anwesenheit von Fehlern in der Byte-Strom-Verschlüsselung umgewandelt ist. Das verursacht unerwartet und häufig strenge Probleme, die versuchen, vorhandene Daten in einem System zu verwenden, das UTF-16 als eine innere Verschlüsselung verwendet. Ergebnisse sind Sicherheitsprogrammfehler, DoS, wenn schlechte Verschlüsselung eine Ausnahme und Datenverlust wirft, wenn sich verschiedene Byte-Ströme zu demselben UTF-16 umwandeln. Wegen der ASCII Vereinbarkeit und des hohen Grads der Muster-Anerkennung in UTF-8 können zufällige Byte-Ströme losslessly durch ein System damit passiert werden, weil Interpretation bis zur Anzeige aufgeschoben werden kann.
• Das Umwandeln zu UTF-16, während es Vereinbarkeit mit vorhandenen Programmen (solchen aufrechterhält, die mit Windows getan wurden), verlangt jede API und Datenstruktur, die eine zu kopierende Schnur nimmt. Ungültige encodings lassen den kopierten APIs nicht genau zu einander kartografisch darstellen, häufig es unmöglich machend, etwas Handlung mit einem von ihnen zu tun.
• Charaktere außerhalb des grundlegenden mehrsprachigen Flugzeugs sind nicht ein spezieller Fall. UTF-16 ist häufig falsch, um die veraltete unveränderliche Länge UCS-2 Verschlüsselung zu sein, führend, um zu codieren, der für den grössten Teil des Textes arbeitet, aber plötzlich für non-BMP Charaktere scheitert.
• In UTF-8 verschlüsselter Text ist häufig kleiner als (oder dieselbe Größe wie) derselbe in UTF-16 verschlüsselte Text.
• Das ist immer für den Text damit wahr nur codieren Punkte unter U+0800 (der alle modernen europäischen Sprachen einschließt), weil jede Codepunkt-UTF-8-Verschlüsselung ein oder zwei Bytes dann ist.
• Selbst wenn Text Codepunkte zwischen U+0800 und U+FFFF enthält, könnte es so viele Codepunkte unter U+0080 enthalten (den UTF-8 in einem Byte verschlüsselt), dass die UTF-8-Verschlüsselung noch kleiner ist. Als HTML-Preiserhöhung und Linie sind terminators Codepunkte unter U+0080, der grösste Teil der HTML-Quelle, ist wenn verschlüsselt, in UTF-8 sogar für asiatische Schriften kleiner.
• Non-BMP Charaktere (U+10000 und oben) werden in UTF-8 in vier Bytes, dieselbe Größe wie in UTF-16 verschlüsselt.
• Der grösste Teil der Kommunikation und Lagerung wurden für einen Strom von Bytes entworfen. Eine UTF-16-Schnur muss ein Paar von Bytes für jede Codeeinheit verwenden:
• Die Ordnung jener zwei Bytes wird ein Problem und muss im UTF-16 Protokoll, solcher als mit einem Byte-Ordnungszeichen angegeben werden.
• Wenn eine ungerade Zahl von Bytes von UTF-16 vermisst wird, wird der ganze Rest der Schnur sinnloser Text sein. Irgendwelche Bytes, die von UTF-8 fehlen, werden noch dem Text erlauben, genau wieder erlangt zu werden, mit dem folgenden Charakter nach den fehlenden Bytes anfangend. Wenn teilweiser Charakter entfernt wird, ist die Bestechung immer erkennbar.

Nachteile

• Ein vereinfachter parser für UTF-16 wird kaum ungültige Folgen zu ASCII umwandeln. Da die gefährlichen Charaktere in den meisten Situationen ASCII sind, ist ein vereinfachter UTF-16 parser viel weniger gefährlich als ein vereinfachter UTF-8 parser.
• Charaktere U+0800 durch U+FFFF verwenden drei Bytes in UTF-8, aber nur zwei in UTF-16. Infolgedessen konnte der Text in (zum Beispiel) Chinesisch, Japanisch oder Hindi mehr Raum in UTF-8 nehmen, wenn es mehr von diesen Charakteren gibt als, gibt es ASCII Charaktere. Das geschieht für den reinen Text, aber selten für HTML-Dokumente. Zum Beispiel nehmen sowohl der japanische UTF-8 als auch die Hindi-Artikel Unicode über die Wikipedia mehr Raum in UTF-16 als in UTF-8.
• In UCS-2 (aber nicht UTF-16) sind Codepunkte von Unicode Größe alle gleich, Maße einer festgelegten Zahl von ihnen leicht machend. Wegen der ASCII-Zeitalter-Dokumentation, wo "Charakter" als ein Synonym für "das Byte" verwendet wird, wird das häufig wichtig betrachtet. Die meisten UTF-16 Durchführungen, einschließlich Windows, messen non-BMP Charaktere als 2 Einheiten in UTF-16, weil das die einzige praktische Weise ist, die Schnuren zu behandeln. Eine ähnliche Veränderlichkeit in der Charakter-Größe gilt für UTF-8.

Siehe auch

• Alt codieren
• Charakter encodings im HTML
• Vergleich der E-Mails

clients#Features

• Vergleich von Unicode encodings
• GB 18030
• Iconv — eine standardisierte API hat gepflegt, sich zwischen dem verschiedenen Charakter encodings umzuwandeln
• ISO/IEC 8859
• Specials (Block von Unicode)
• Unicode und E-Mail
• Unicode und HTML
• Universale Codierung
• UTF-8 in URIs
• UTF-9 und UTF-18
• UTF-16/UCS-2

Links

Es gibt mehrere aktuelle Definitionen von UTF-8 in verschiedenen Standarddokumenten:

• RFC 3629 / STD 63 (2003), der UTF-8 als ein Standardinternetprotokoll-Element gründet
• Der Unicode Standard, die Version 6.0, §3.9 D92, §3.10 D95 (2011)
• ISO/IEC 10646:2003 Anhang D (2003)

Sie ersetzen die in den folgenden veralteten Arbeiten gegebenen Definitionen:

• ISO/IEC 10646-1:1993 Zusatzartikel 2 / Anhang R (1996)
• Der Unicode Standard, die Version 5.0, §3.9 D92, §3.10 D95 (2007)
• Der Unicode Standard, die Version 4.0, §3.9-§3.10 (2003)
• Der Unicode Standard, die Version 2.0, der Anhang A (1996)
• RFC 2044 (1996)
• RFC 2279 (1998)
• Der Unicode Standard, die Version 3.0, §2.3 (2000) plus die Berichtigung #1: UTF-8 Kürzeste Form (2000)
• Unicode Standardanhang #27: Unicode 3.1 (2001)

Sie sind in ihrer allgemeinen Mechanik mit den Hauptunterschieden alle gleich, die auf Problemen solcher als erlaubt Reihe von Codepunkt-Werten und das sichere Berühren des ungültigen Eingangs sind.

• Ursprüngliches UTF-8 Papier (oder pdf) für den Plan 9 von Glockenlaboratorien
• RFC 5198 definiert UTF-8 NFC für den Netzaustausch
• UTF-8 prüfen Seiten durch Andreas Prilop, Jost Gippert und das Konsortium des World Wide Web
• Wie man E-Mail-Kunden konfiguriert, um UTF-8 Text zu senden
• Unix/Linux: UTF-8/Unicode häufig gestellte Fragen, Linux Unicode HOWTO, UTF-8 und Gentoo
• Unicode/UTF-8-character zeigt Tisch UTF-8 in einer Vielfalt von Formaten (mit Unicode und HTML, der Information verschlüsselt)
• Unicode und Mehrsprachige WWW-Browser von Unicode Resources von Alan Wood beschreiben Unterstützung und zusätzliche Konfiguration Unicode/UTF-8 in modernen Browsern
• JSP Wiki Browser-Vereinbarkeitsseitendetails spezifische Probleme mit UTF-8 in älteren Browsern
• Mathematische Symbole in Unicode
• Grafische Ansicht von UTF-8 im Konverter-Forscher von ICU