UTF-16 (Unicode 16-Bit-Transformationsformat) ist eine Charakter-Verschlüsselung für Unicode, der dazu fähig ist, 1,112,064 Zahlen zu verschlüsseln (genannt Codepunkte) im Coderaum von Unicode von 0 bis 0x10FFFF. Es erzeugt ein Ergebnis der variablen Länge von entweder einer oder zwei 16-Bit-Codeeinheiten pro Codepunkt.

Der ältere UCS-2 (Universale 2-Byte-Codierung) ist ein ähnlicher Charakter, der verschlüsselt, der durch UTF-16 in der Version 2.0 des Standards von Unicode im Juli 1996 ersetzt wurde. Es erzeugt ein Format der festen Länge durch das einfache Verwenden des Codepunkts als die 16-Bit-Codeeinheit und erzeugt genau dasselbe Ergebnis wie UTF-16 für 96.9 % aller Codepunkte in der Reihe 0-0xFFFF einschließlich aller Charaktere, die ein Wert damals zugeteilt worden waren.

UTF-16 wird im Anhang Q des internationalen normalen ISO/IEC 10646 offiziell definiert. Es wird auch in "Der Unicode Normalen" Version 2.0 und höher, sowie im RFC des IETF 2781 beschrieben.

Beschreibung

Der Unicode-Coderaum wird in siebzehn Flugzeuge 2 (65,536) geteilt Code spitzt jeden an, obwohl einige Codepunkte zugeteilte Charakter-Werte noch nicht gewesen sind, werden einige für den privaten Gebrauch vorbestellt, und einige werden als Nichtcharaktere dauerhaft vorbestellt. Die Codepunkte in jedem Flugzeug haben die Hexadecimal-Werte xx0000 zu xxFFFF, wo xx ein Hexe-Wert von 00 bis 10 ist, wichtig seiend, welchem Flugzeug die Werte gehören.

Code spitzt U+0000 auf U+D7FF und U+E000 zu U+FFFF an

Das erste Flugzeug (spitzt Code U+0000 auf U+FFFF an), enthält die am häufigsten verwendeten Charaktere und wird das Grundlegende Mehrsprachige Flugzeug oder BMP genannt. Sowohl UTF-16 als auch UCS-2 verschlüsseln gültige Codepunkte in dieser Reihe als einzelne 16-Bit-Codeeinheiten, die den entsprechenden Codepunkten numerisch gleich sind. Die Codepunkte im BMP sind die einzigen Codepunkte, die in UCS-2 vertreten werden können.

Code spitzt U+10000 auf U+10FFFF an

Codepunkte von den anderen Flugzeugen (hat Ergänzende Flugzeuge genannt), werden in UTF-16 von Paaren von 16-Bit-Codeeinheiten genannt ein Stellvertreter-Paar durch das folgende Schema verschlüsselt:

• 0x10000 wird vom Codepunkt abgezogen, eine 20-Bit-Zahl in der Reihe 0 verlassend.. 0xFFFFF.
• Die zehn ersten Bit (eine Zahl in der Reihe 0.. 0x3FF) werden zu 0xD800 hinzugefügt, um die erste Codeeinheit zu geben oder Stellvertreter zu führen, der in der Reihe sein wird (vorherige Versionen des Unicode Standards haben diese als hohe Stellvertreter gekennzeichnet).
• Die niedrigen zehn Bit (auch in der Reihe 0.. 0x3FF) werden zu 0xDC00 hinzugefügt, um die zweite Codeeinheit zu geben oder Stellvertreter zu schleppen, der in der Reihe sein wird (vorherige Versionen des Unicode Standards haben diese als niedrige Stellvertreter gekennzeichnet).

Seit den Reihen für die Leitungsstellvertreter, schleppen Sie Stellvertreter, und gültige BMP Charaktere sind zusammenhanglos, Suchen werden vereinfacht: Es ist für einen Teil eines Charakters nicht möglich, einen verschiedenen Teil eines anderen Charakters zu vergleichen. Es bedeutet auch, dass UTF-16 gleichzeitig selbstist: Der Anfang des folgenden Charakters im Anschluss an eine gegebene Codeeinheit kann durch das Überprüfen nur dass eine Codeeinheit gefunden werden. UTF-8 teilt diese Vorteile, aber viele frühere Verschlüsselungsschemas haben eindeutige Suche nicht erlaubt und konnten nur durch die Wiedersyntaxanalyse vom Anfang der Schnur synchronisiert werden.

Weil die meistens verwendeten Charaktere alle im Grundlegenden Mehrsprachigen Flugzeug sind, wird das Berühren von Stellvertreter-Paaren häufig nicht gründlich geprüft. Das führt zu beharrlichen Programmfehlern und potenziellen Sicherheitslöchern sogar in der populären und gut nachgeprüften Anwendungssoftware.

Code spitzt U+D800 auf U+DFFF an

Der Unicode Standard bestellt dauerhaft diese Codepunkt-Werte für die UTF-16-Verschlüsselung der Leitung und Spur-Stellvertreter vor, und sie werden ein Charakter nie zugeteilt, also sollte es keinen Grund geben, sie zu verschlüsseln. Der offizielle Standard von Unicode sagt, dass der ganze UTF Formen, einschließlich UTF-16, diese Codepunkte nicht verschlüsseln kann.

Jedoch können UCS-2, UTF-8 und UTF-32 diese Codepunkte auf triviale und offensichtliche Weisen physisch verschlüsseln, und große Beträge der Software tun so, wenn auch der Standard feststellt, dass solche Maßnahmen als Verschlüsselung von Fehlern behandelt werden sollten. Es ist möglich, sie in UTF-16 eindeutig zu verschlüsseln, so lange sie nicht in einer Leitung + sind, schleppen Paar, durch das Verwenden einer dem Codepunkt gleichen Codeeinheit. Die Mehrheit von UTF-16 encoder und Decoder-Durchführungen übersetzt zwischen encodings, als ob das, der Fall gewesen

ist

Byte-Ordnung, die Schemas verschlüsselt

UTF-16 und UCS-2 erzeugen eine Folge von 16-Bit-Codeeinheiten. Jede Einheit nimmt so zwei 8-Bit-Bytes, und die Ordnung der Bytes kann vom endianness (Byte-Ordnung) der Computerarchitektur abhängen.

Um beim Erkennen der Byte-Ordnung von Codeeinheiten zu helfen, erlaubt UTF-16 Byte Order Mark (BOM), einer Codeeinheit mit dem Wert U+FEFF, dem ersten wirklichen codierten Wert voranzugehen. (U+FEFF ist das unsichtbare Nullbreite-geschützte Leerzeichen (ZWNBSP) Charakter.), Wenn die endian Architektur der Decoder-Matchs dieser der encoder, der Decoder den 0xFEFF-Wert entdeckt, aber ein Gegenteil - endian Decoder interpretiert den BOM als der Nichtcharakter, schätzen U+FFFE vorbestellt für diesen Zweck. Dieses falsche Ergebnis stellt einen Hinweis zur Verfügung, um das Tauschen des Bytes für die restlichen Werte durchzuführen. Wenn der BOM vermisst wird, sagt der Standard, dass große-endian Verschlüsselung angenommen werden sollte. (In der Praxis, wegen Windows, das wenig-endian verwendet, bestellen standardmäßig, viele Anwendungen nehmen auch wenig-endian Verschlüsselung standardmäßig an.), Wenn es keinen BOM gibt, sucht eine Methode, eine UTF-16-Verschlüsselung anzuerkennen, nach dem Raumcharakter (U+0020), die in Texten auf den meisten Sprachen sehr üblich sind.

Der Standard erlaubt auch der Byte-Ordnung, ausführlich durch das Spezifizieren von UTF-16BE oder UTF-16LE als der Verschlüsselungstyp festgesetzt zu werden. Wenn die Byte-Ordnung ausführlich dieser Weg angegeben wird, wie man spezifisch annimmt, ist ein BOM nicht prepended zum Text, und ein U+FEFF am Anfang sollte als ein ZWNBSP Charakter behandelt werden. Viele Anwendungen ignorieren den BOM-Code am Anfang jeder Verschlüsselung von Unicode. WWW-Browser verwenden häufig einen BOM als ein Hinweis in der Bestimmung der Charakter-Verschlüsselung.

Für Internetprotokolle hat IANA "UTF-16", "UTF-16BE" und "UTF-16LE" als die Namen für diese encodings genehmigt. (Die Namen sind unempfindlicher Fall.) Die Decknamen können UTF_16 oder UTF16 auf einigen Programmiersprachen oder Softwareanwendungen bedeutungsvoll sein, aber sie sind nicht Standardnamen in Internetprotokollen.

UCS-2 Verschlüsselung wird definiert, um nur groß-endian zu sein. In der Praxis der grösste Teil des Softwareverzugs zu wenig-endian, und Griffe eine Führung BOM, die Byte-Ordnung als in UTF-16 zu definieren. Obwohl die ähnlichen Benennungen UCS-2BE und UCS-2LE die UTF-16-Etiketten imitieren, vertreten sie offizielle Verschlüsselungsschemas nicht.

Verwenden Sie in Hauptbetriebssystemen und Umgebungen

UTF-16 wird für den Text in der OS API in Microsoft Windows 2000/xp/2003/vista/ce verwendet. Ältere Systeme des Windows NT (vor Windows 2000) unterstützen nur UCS-2. In Windows XP wird kein Codepunkt über U+FFFF in jede Schriftart eingeschlossen, die mit Windows für europäische Sprachen geliefert ist. Dateien und Netzdaten neigen dazu, eine Mischung von UTF-16, UTF-8 und Vermächtnis-Byte encodings zu sein. Zum Beispiel ist die Registrierung eine Byte-Verschlüsselung, und Windows wird häufig Dateinamen von entfernten Systemen als Byte encodings zeigen, mojibake hinauslaufend, wenn tatsächlich sie UTF-8 sind.

UTF-16 wird durch das Qualcomm-GEBRÄU Betriebssysteme verwendet; die.NET Umgebungen; der Kakao von Mac OS X und Kernfundament-Fachwerk; und die Quer-Plattform von Qt grafisches Produkt-Werkzeug.

Symbian OS hat in Hörern von Nokia S60 und Sony Ericsson verwendet UIQ Hörer verwenden UCS-2.

Das Dateisystem von Joliet, das in CD-ROM-Medien verwendet ist, verschlüsselt Dateinamen mit UCS-2BE (bis zu vierundsechzig Charaktere von Unicode pro Datei).

Die Pythonschlange-Sprachumgebung verwendet offiziell nur UCS-2 innerlich seit der Version 2.0, aber der UTF-8 Decoder zu "Unicode" erzeugt richtigen UTF-16. Da Pythonschlange 2.2, "breit" Unicode baut, werden unterstützt, die UTF-32 statt dessen verwenden, werden diese in erster Linie auf Linux verwendet. In der Pythonschlange werden 3.3 Schnuren eine Struktur verwenden, die ein oder mehr von ASCII oder UTF-8 oder UCS-2 oder UTF-32 abhängig davon versorgen kann, welche Codepunkte in der Schnur sind, und was sich formt, die Daten ist am meisten kürzlich gebeten worden.

Java hat ursprünglich UCS-2 verwendet, und hat UTF-16 ergänzende Charakter-Unterstützung in J2SE 5.0 hinzugefügt. Jedoch, non-BMP Charaktere verlangen, dass der individuelle Stellvertreter Hälften individuell zum Beispiel eingegangen wird: "\uD834\uDD1E" für U+1D11E.

Auf vielen Sprachen hat zitiert Schnuren brauchen eine neue Syntax, um non-BMP Charaktere anzusetzen, weil die "\uXXXX" Syntax ausführlich sich zu 4 Hexe-Ziffern beschränkt. Das allgemeinste (verwendet durch C#, D und mehrere andere Sprachen) soll eine Großschrift 'U' mit 8 Hexe-Ziffern wie "\U0001D11E" In Java 7 regelmäßige Ausdrücke verwenden, abstrakte Codepunkte können (und in Charakter-Klassen, die Flugzeuge 1-16 einschließen, muss), mit "\x {HHHHHH}" Syntax angegeben werden, die in ICU und Perl verwendet ist, wo "H" 1-6 ASCII Hexe-Ziffern sein kann, um die volle Reihe von Unicode zu bedecken.

Diese Durchführungen die ganze Rückkehr die Zahl von 16-Bit-Codeeinheiten aber nicht die Zahl von Unicode codiert Punkte, wenn Sie die Entsprechung von strlen auf ihren Schnuren verwenden, und dass das Indexieren in eine Schnur die mit einem Inhaltsverzeichnis versehene Codeeinheit, nicht den mit einem Inhaltsverzeichnis versehenen Codepunkt zurückgibt. Der Begriff "Charakter" wird definiert und auf vielfache Weisen innerhalb der Fachsprache von Unicode gebraucht, so ist eine Zählung von ihnen nicht möglich. Der grösste Teil der Verwirrung ist wegen der veralteten ASCII-Zeitalter-Dokumentation mit dem Begriff "Charakter", als eine feste Größe "Byte" beabsichtigt war.

Beispiele

* sind Passende Schriftart und Software erforderlich, den richtigen glyphs zu sehen.

Beispiel UTF-16 Verschlüsselung des Verfahrens

Der Charakter am Code spitzt an, dass U+64321 (hexadecimal) in UTF-16 verschlüsselt werden soll. Da es über U+FFFF ist, muss es mit einem Stellvertreter-Paar wie folgt verschlüsselt werden:

v = 0x64321

v′ = v - 0x10000

= 0x54321

= 0101 0100 0011 0010 0001

vh = v′>> 10

= 01 0101 0000//höhere 10 Bit

v′

vl = v′ & 0x3FF

= 11 0010 0001//sinken um 10 Bit

v′

w1 = 0xD800 + vh

= 1101 1000 0000 0000

+ 01 0101 0000

= 1101 1001 0101 0000

= 0xD950//codieren zuerst Einheit von UTF-16, der verschlüsselt

w2 = 0xDC00 + vl

= 1101 1100 0000 0000

+ 11 0010 0001

= 1101 1111 0010 0001

= 0xDF21//die zweite Codeeinheit von UTF-16, der verschlüsselt

Siehe auch

• Vergleich von Unicode encodings
• Flugzeug von Unicode
• UTF-8

Links

• Ein sehr kurzer Algorithmus, für das Stellvertreter-Paar für jeden codepoint zu bestimmen
• Unicode technisches Zeichen #12: UTF-16, um zu bearbeiten
• Unicode häufig gestellte Fragen: Wie ist der Unterschied zwischen UCS-2 und UTF-16?
• Unicode Charakter-Namenindex
• RFC 2781: UTF-16, eine Verschlüsselung von ISO 10646
• java.lang. Schnur-Dokumentation, Stellvertreter besprechend, der behandelt