UTF-16

UTF-16
Unifont Full Map.png
Die ersten 216 Unicode -Codepunkte. Der Streifen von fester Grau in der Nähe des Bodens sind die von UTF-16 verwendeten Ersatzhälften (der weiße Bereich unter dem Streifen ist die Privatnutzungsbereich)
Sprachen) International
Standard Unicode Standard
Einstufung Unicode -Transformationsformat, Codierung der variablen Breite
Erweitert UCS-2
Transformationen / codiert ISO/IEC 10646 (Unicode)

UTF-16 (16-Bit Unicode Transformationsformat) ist a Zeichenkodierung In der Lage, alle 1.112.064 gültigen Zeichen zu codieren Codepunkte von Unicode (in der Tat wird diese Anzahl der Codepunkte durch das Design von UTF-16 diktiert). Die Codierung ist variable Länge, wie Codepunkte mit einem oder zwei 16-Bit codiert werden Codeeinheiten. UTF-16 entstand aus einer früheren veralteten 16-Bit UCS-2 (für 2-Byte Universal Character Set), sobald klar wurde, dass mehr als 216 (65.536) Codepunkte wurden benötigt.[1]

UTF-16 wird von Systemen wie der verwendet Microsoft Windows API, die Java -Programmiersprache und JavaScript/Ecmascript. Es wird auch manchmal auch für verwendet einfacher Text und Wortverarbeitungsdatendateien auf Microsoft Windows. Es wird selten für Dateien verwendet Unix-artig Systeme. Seit Mai 2019 hat Microsoft begonnen, unterstützt zu werden UTF-8 (sowie UTF-16) und fördern deren Verwendung.[2]

UTF-16 ist das einzige webkodierende, der nicht kompatibel ist ASCII[3] und nie im Internet an Popularität gewonnen, wo es von unter 0,002% (etwas mehr als 1 Tausendstel 1 Prozent) Webseiten verwendet wird.[4] UTF-8Im Vergleich dazu macht 98% aller Webseiten aus.[5] Das Web Hypertext Application Technology Working Group (Whatwg) Betrachtet UTF-8 "die obligatorische Codierung für alle [Text]" und dass Browseranwendungen aus Sicherheitsgründen nicht UTF-16 verwenden sollten.[6]

Es wird von verwendet von SMS (d. H. Die UTF-16 variable Länge benötigt, um alle zu unterstützen Emoji Charaktere, der SMS-Standard angibt den Vorgänger feste Breite UCS-2 die die meisten nicht unterstützen).

Geschichte

In den späten 1980er Jahren begannen die Arbeiten zur Entwicklung einer einheitlichen Kodierung für einen "universellen Charakter -Set" (UCS) Das würde frühere sprachspezifische Encodings durch ein koordiniertes System ersetzen. Ziel war es, alle erforderlichen Charaktere aus den meisten Sprachen der Welt sowie Symbole aus technischen Bereichen wie Wissenschaft, Mathematik und Musik einzubeziehen. Die ursprüngliche Idee bestand darin, die typischen 256-Zeichen-Codierungen zu ersetzen, die 1 Byte pro Charakter benötigten, durch eine Codierung mit 65.536 (216) Werte, die 2 Bytes (16 Bit) pro Zeichen erfordern würden.

Zwei Gruppen arbeiteten parallel daran, ISO/IEC JTC 1/SC 2 und die Unicode -KonsortiumLetztere repräsentieren hauptsächlich Hersteller von Computergeräten. Die beiden Gruppen versuchten, ihre Charakterzuweisungen so zu synchronisieren, damit sich die sich entwickelnden Codierungen gegenseitig kompatibel wären. Die frühe 2-Byte-Kodierung wurde ursprünglich "Unicode" bezeichnet, wird aber jetzt "UCS-2" bezeichnet.[7]

Als es immer klarer wurde, dass 216 Charaktere würden nicht ausreichen,[1] IEEE führte einen größeren 31-Bit-Raum und eine Codierung ein (UCS-4) Das würde 4 Bytes pro Charakter erfordern. Dies wurde von dem widerstanden Unicode -Konsortiumbeide, weil 4 Bytes pro Charakter viel Gedächtnis und Speicherplatz verschwendeten, und weil einige Hersteller bereits stark in 2-Byte-per-Charakter-Technologien investiert waren. Das UTF-16-Codierungsschema wurde als Kompromiss entwickelt und im Juli 1996 mit Version 2.0 des Unicode-Standards eingeführt.[8] Es ist vollständig in RFC 2781 spezifiziert, veröffentlicht im Jahr 2000 von der Ietf.[9][10]

In der UTF-16-Codierung zeigt Code weniger als 216 werden mit einer einzelnen 16-Bit-Codeeinheit codiert, die dem numerischen Wert des Codepunkts entspricht, wie im älteren UCS-2. Die neueren Codepunkte sind größer oder gleich 216 werden durch einen zusammengesetzten Wert verwendet zwei 16-Bit-Code-Einheiten. Diese beiden 16-Bit-Codeeinheiten werden aus dem ausgewählt UTF-16-Ersatzbereich 0xd800–0xdfff was zuvor nicht zugeordnet worden war. Werte in diesem Bereich werden nicht als Zeichen verwendet, und UTF-16 bietet keine rechtliche Möglichkeit, sie als einzelne Codepunkte zu codieren. Ein UTF-16-Stream besteht daher aus einzelnen 16-Bit-Codepunkten außerhalb des Ersatzbereichs für Codepunkte in der Grundlegende mehrsprachige Ebene (BMP) und Paare von 16-Bit-Werten innerhalb des Ersatzbereichs für Codepunkte über dem BMP.

UTF-16 ist in den neuesten Versionen sowohl des internationalen Standards angegeben ISO/IEC 10646 und der Unicode -Standard. "UCS-2 sollte jetzt als veraltet angesehen werden. Es bezieht sich nicht mehr auf ein Codierungsformular in 10646 oder im Unicode-Standard."[11] UTF-16 wird niemals erweitert, um eine größere Anzahl von Codepunkten zu unterstützen oder die Codepunkte zu unterstützen, die durch Ersatzstoffe ersetzt wurden, da dies die Unicode-Stabilitätsrichtlinie in Bezug auf allgemeine Kategorie oder Ersatzcodepunkte verletzen würde.[12] (Jedes Schema, das ein bleibt a Selbstsynchronisierungscode müsste mindestens einen BMP -Codepunkt zuweisen, um eine Sequenz zu starten. Die Änderung des Zwecks eines Codepunkts wird nicht zugelassen.)

Beschreibung

Jeder Unicode-Codepunkt wird entweder als ein oder zwei 16-Bit codiert Codeeinheiten. Wie diese 16-Bit-Codes als Bytes gespeichert werden, hängt dann von der 'ab.Endiangess'des Textdatei oder des Kommunikationsprotokolls.

Ein "Charakter" braucht möglicherweise von nur zwei Bytes bis vierzehn[13] oder noch mehr Bytes zu erfassen. Zum Beispiel an Emoji -Flaggencharakter Nimmt 8 Bytes, da es "aus einem Paar Unicode -Skalarwerte konstruiert wird"[14] (Und diese Werte sind außerhalb des BMP und erfordern jeweils 4 Bytes).

U+0000 bis U+D7FF und U+E000 bis U+FFFF

U+D800 bis U+DFFF haben einen besonderen Zweck, siehe unten.

Sowohl UTF-16 als auch UCS-2 codieren Codepunkte in diesem Bereich als einzelne 16-Bit-Codeeinheiten, die numerisch gleich den entsprechenden Codepunkten sind. Diese Codepunkte in der Grundlegende mehrsprachige Ebene (BMP) sind die nur Codepunkte, die in UCS-2 dargestellt werden können. Ab Unicode 9.0 fallen einige moderne nicht-latinische asiatische, mittlere östliche und afrikanische Skripte wie die meisten außerhalb dieses Bereichs Emoji Figuren.

Codepunkte von u+010000 bis u+10ffff

Codepunkte aus den anderen Ebenen (genannt Ergänzende Ebenen) werden als zwei 16-Bit codiert Codeeinheiten genannt Ersatzpaar, nach dem folgenden Schema:

UTF-16 Decoder
Niedrig
Hoch
DC00 DC01 ... Dfff
D800 010000 010001 ... 0103ff
D801 010400 010401 ... 0107ff
⋮ ⋮ ⋮ ⋱ ⋮
DBFF 10fc00 10fc01 ... 10ffff
  • 0x10000 wird vom Codepunkt vom Codepunkt abgezogen (U)eine 20-Bit-Nummer hinterlassen (U ') im HEX -Zahlenbereich 0x00000–0xfffff. Hinweis für diese Zwecke, U ist definiert als nicht größer als 0x10ffff.
  • Die hohen zehn Bits (im Bereich 0x000–0x3ff) werden zu 0xD800 hinzugefügt, um den ersten 16-Bit zu ergeben Codeeinheit oder hoher Ersatz (W1), was im Bereich sein wird 0xd800–0xdbff.
  • Die niedrigen zehn Bits (auch im Bereich 0x000–0x3ff) werden zu 0xDC00 hinzugefügt, um den zweiten 16-Bit zu ergeben Codeeinheit oder Niedrige Ersatz (W2), was im Bereich sein wird 0xdc00–0xdfff.

Visuell dargestellt, die Verteilung von U ' zwischen W1 und W2 sieht aus wie:[15]

U' = yyyyyyyyyyxxxxxxxxxx  // U - 0x10000 W1 = 110110yyyyyyyyyy      // 0xD800 + yyyyyyyyyy W2 = 110111xxxxxxxxxx      // 0xDC00 + xxxxxxxxxx

Das hoher Ersatz und Niedrige Ersatz sind auch als "führende" bzw. "nachfolgende" Ersatzbezeichnungen bezeichnet, die zu den führenden und nachfolgenden Bytes von UTF-8 analog sind.[16]

Da die Bereiche für die hohe Leihmutter (0xd800–0xdbff), Niedrige Ersatzstoffe (0xdc00–0xdfff) und gültige BMP -Zeichen (0x0000–0xd7ff, 0xe000–0xffff) sind disjunktEs ist nicht möglich, dass ein Ersatz für einen BMP -Charakter oder für zwei benachbarte Angaben entspricht Codeeinheiten wie ein legal aussehen Ersatzpaar. Dies vereinfacht die Suche sehr. Es bedeutet auch, dass UTF-16 ist Selbstsynchronisation Auf 16-Bit Codeeinheit kann durch die Wertebereiche bestimmt werden, in denen es fällt). UTF-8 teilt diese Vorteile, aber viele frühere Multi-Byte-Codierungsschemata (wie z. Schicht jis und andere asiatische Multi-Byte-Codierungen) erlaubten keine eindeutige Suche und konnten nur durch erneutes Parsen von Beginn der Zeichenfolge synchronisiert werden (UTF-16 ist nicht selbstsynchronisiert, wenn ein Byte verloren geht oder wenn die Durchführung bei einem zufälligen Byte beginnt ).

Da die am häufigsten verwendeten Zeichen alle im BMP sind, wird die Handhabung von Ersatzpaaren oft nicht gründlich getestet. Dies führt zu anhaltenden Fehler und potenziellen Sicherheitslöchern, auch in beliebten und gut bewerteten Anwendungssoftware (z. CVE-2008-2938, Cve-2012-2135).

Das Ergänzende Ebenen enthalten Emoji, historische Skripte, weniger verwendete Symbole, weniger verwendete chinesische Ideografien usw. Da die Codierung von ergänzenden Ebenen 20 signifikante Bits enthält (10 von 16 Bits in jedem der hoch und Niedrige Ersatzstoffe), 220 Codepunkte können codiert und in 16 Ebenen von 2 unterteilt werden16 Codespunkte jeweils. Einschließlich der separat gehandelten Basis mehrsprachigen Ebene gibt es insgesamt 17 Flugzeuge.

U+D800 bis U+DFFF

Der Unicode-Standard behält diese Codepunktwerte dauerhaft für die UTF-16-Codierung der hohen und niedrigen Ersatzwerte vor, und sie werden niemals ein Zeichen zugewiesen, daher sollte es keinen Grund geben, sie zu codieren. Der offizielle Unicode-Standard besagt, dass keine UTF-Formulare, einschließlich UTF-16, diese Codepunkte codieren können.

UCS-2, UTF-8 und jedoch UTF-32 Kann diese Codepunkte auf triviale und offensichtliche Weise codieren, und eine große Menge an Software tut dies, obwohl der Standard feststellt, dass solche Anordnungen als Codierungsfehler behandelt werden sollten.

Es ist möglich, ein eindeutig zu codieren ungepaarter Ersatz (Ein hoher Ersatzcodepunkt, der nicht von einem niedrigen oder einem niedrigen, dem eine hohe nicht vorausgeht) im Format von UTF-16 unter Verwendung einer Codeeinheit, die dem Codepunkt entspricht, im Format von UTF-16 nicht gefolgt. Das Ergebnis ist nicht gültig UTF-16, aber die Mehrheit der UTF-16-Encoder- und Decoder-Implementierungen tut dies dann bei der Übersetzung zwischen Codings. Windows ermöglicht ungepaarte Ersatz an Dateinamen und anderen Orten, was im Allgemeinen bedeutet, dass sie trotz ihres Ausschlusses vom Unicode -Standard von Software unterstützt werden müssen.

Beispiele

So codieren u+10437 () zu utf-16:

  • Subtrahieren Sie 0x10000 vom Codepunkt und bleiben Sie 0x0437.
  • Für das hohe Ersatz, schalten Sie rechts um 10 (dividieren Sie durch 0x400) und fügen Sie dann 0xD800 hinzu, was zu 0x0001 + 0xd800 = 0xD801 führt.
  • Nehmen Sie für das niedrige Ersatz die niedrigen 10 Bit (Rest der Dividierung durch 0x400) und fügen Sie dann 0xDC00 hinzu, was zu 0x0037 + 0xDC00 = 0xDC37 führt.

Um U+10437 () aus UTF-16 zu dekodieren:

  • Nehmen Sie das hohe Ersatz (0xD801) und subtrahieren Sie 0xD800 und multiplizieren Sie dann mit 0x400, was zu 0x0001 × 0x400 = 0x0400 führt.
  • Nehmen Sie das niedrige Ersatz (0xDC37) und subtrahieren 0xDC00, was zu 0x37 führt.
  • Fügen Sie diese beiden Ergebnisse zusammen (0x0437) hinzu und fügen Sie schließlich 0x10000 hinzu, um den endgültigen dekodierten UTF-32-Codepunkt 0x10437 zu erhalten.

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

Charakter Binärcodepunkt Binärer UTF-16 UTF-16 Hex
Codeeinheiten		 UTF-16BE
Hex -Bytes		 UTF-16LE
Hex -Bytes
$ U+0024 0000 0000 0010 0100 0000 0000 0010 0100 0024 00 24 24 00
€ U+20AC 0010 0000 1010 1100 0010 0000 1010 1100 20AC 20 ac AC 20
U+10437 0001 0000 0100 0011 0111 1101 1000 0000 0001 1101 1100 0011 0111 D801 DC37 D8 01 DC 37 01 D8 37 DC
U+24b62 0010 0100 1011 0110 0010 1101 1000 0101 0010 1101 1111 0110 0010 D852 DF62 D8 52 DF 62 52 D8 62 df

Codierungsschemata der Byte-Ordnung

UTF-16 und UCS-2 erzeugen eine Sequenz von 16-Bit-Codeeinheiten. Da die meisten Kommunikations- und Speicherprotokolle für Bytes definiert sind und jede Einheit zwei 8-Bit-Bytes nimmt, kann die Reihenfolge der Bytes von der abhängen Endiangess (Byte -Ordnung) der Computerarchitektur.

Um die Byte -Reihenfolge von Codeeinheiten zu erkennen, UTF-16 erlaubt a Byte -Bestellmarke (BOM), ein Codepunkt mit dem Wert U+Feff, um dem ersten tatsächlichen codierten Wert vorauszusehen.[NB 1] (U+Feff ist das Unsichtbare Null-Breiten-nicht-bahnbrechender Raum/Zwnbsp -Zeichen.)[NB 2] Wenn die Endian-Architektur des Decoders dem des Encoders übereinstimmt, erkennt der Decoder den 0xFeff-Wert, aber ein Dekodierer-Decoder interpretiert die BOM als die als die Nichtcharakter Wert U+FFFE für diesen Zweck reserviert. Dieses falsche Ergebnis liefert einen Hinweis zur Durchführung von Byte-Swapping für die verbleibenden Werte.

Wenn die BOM fehlt, empfiehlt RFC 2781[NB 3] Diese Big-Endian (BE) -Codierung wird angenommen. In der Praxis nehmen viele Anwendungen aufgrund von Fenstern, die standardmäßig Little-Endian (LE) bestellen, Little-Endian-Codierung an. Es ist auch zuverlässig, Endianess zu erkennen, indem sie nach Null -Bytes suchen, unter der Annahme, dass Zeichen weniger als U+0100 sehr häufig sind. Wenn mehr Bytes (ab 0) null sind, dann ist es Big-Endian.

Der Standard ermöglicht auch, dass die Bytereihenfolge durch Angabe explizit angegeben werden UTF-16BE oder UTF-16LE als Codierungstyp. Wenn die Byte -Reihenfolge explizit auf diese Weise angegeben ist, ist eine BOM speziell nicht Sollte auf den Text vorbereitet werden, und ein U+Feff am Anfang sollte als zwnbsp -Zeichen behandelt werden. Die meisten Anwendungen ignorieren in allen Fällen trotz dieser Regel eine BOM.

Zum Internet Protokolle, Iana hat "UTF-16", "UTF-16BE" und "UTF-16LE" als Namen für diese Codierungen genehmigt (die Namen sind unempfindlich). Die Aliase UTF_16 oder UTF16 kann in einigen Programmiersprachen oder Softwareanwendungen von Bedeutung sein, sind jedoch keine Standardnamen in Internet -Protokollen.

Ähnliche Bezeichnungen, UCS-2BE und UCS-2LE, werden verwendet, um Versionen von zu zeigen UCS-2.

Verwendungszweck

UTF-16 wird für Text in der OS-API aller derzeit unterstützten Versionen von verwendet Microsoft Windows (und mindestens alle seitdem einschließlich Windows CE/2000/XP/2003/Vista/7[17]) einschließlich Windows 10. In Windows XP ist in jeder Schriftart, die mit Windows für europäische Sprachen geliefert wird, kein Codepunkt über U+FFFF enthalten.[18][19] Älter Windows NT Systeme (vor Windows 2000) unterstützen nur UCS-2.[20] Dateien und Netzwerkdaten sind in der Regel eine Mischung aus UTF-16-, UTF-8- und Legacy-Byte-Codierungen.

Während sogar Windows XP eine UTF-8-Unterstützung gegeben hat, gab es zwar eine Unterstützung[21] es war verbessert (Insbesondere die Möglichkeit, eine Datei mit UTF-8 zu benennen) in Windows 10 Insiderbau 17035 und das Update im April 2018. Ab Mai 2019 empfiehlt Microsoft Software, UTF-8 anstelle von UTF-16 zu verwenden.[2]

Das Ibm i Betriebssystem designiert Ccsid (Codepage) 13488 für UCS-2-Codierung und CCSID 1200 für UTF-16-Codierung, obwohl das System sie beide als UTF-16 behandelt.[22]

UTF-16 wird von der verwendet Qualcomm Brew Betriebssysteme; das .NETZ Umgebungen; und die Qt plattformgrafisch Widget Toolkit.

Symbian OS Wird in Nokia S60 Handys und Sony Ericsson verwendet UIQ Handys verwendet UCS-2. iPhone Handys verwenden UTF-16 für Kurznachrichtendienst anstelle von ucs-2 beschrieben in der 3GPP TS 23.038 (GSM) und IS-637 (CDMA) Standards.[23]

Das Joliet -Dateisystem, benutzt in CD-ROM Medien, codiert Dateinamen mit UCS-2BE (bis zu 64 Unicode-Zeichen pro Dateinamen).

Das Python Die Sprachumgebung verwendet offiziell nur UCS-2 seit Version 2.0, aber der UTF-8-Decoder für "Unicode" erzeugt originelle UTF-16. Seit Python 2.2 werden "breite" Builds von Unicode unterstützt, die verwendet werden UTF-32 stattdessen;[24] Diese werden hauptsächlich unter Linux verwendet. Python 3.3 verwendet nie mehr UTF-16, stattdessen wird eine Codierung, die die kompakteste Darstellung für die angegebene Zeichenfolge ergibt, aus ASCII/Latin-1, UCS-2 und UTF-32 ausgewählt.[25]

Java Ursprünglich UCS-2 verwendet und UTF-16 ergänzende Charakterunterstützung in hinzugefügt J2SE 5.0.

JavaScript Kann UCS-2 oder UTF-16 verwenden.[26] Ab ES2015 wurden String-Methoden und regelmäßige Expressionsflags in die Sprache hinzugefügt, die den Umgang mit Zeichenfolgen aus einer kodierenden Sicht ermöglichen.

In vielen Sprachen benötigen zitierte Saiten eine neue Syntax, um Nicht-BMP-Zeichen als C-Stil zu zitieren "\ uxxxx" Die Syntax begrenzt sich ausdrücklich auf 4 Sechskantigstellen. Die folgenden Beispiele veranschaulichen die Syntax für das Nicht-BMP-Zeichen "" (U+1D11e, Musiksymbol G Clef). Am häufigsten (verwendet von C ++, C#, Dund mehrere andere Sprachen) müssen einen oberen Fall 'u' mit 8 Sechskantigstellern wie verwenden, z. "\ U0001d11e".[27] In Java 7 reguläre Ausdrücke, ICUund Perl die Syntax "\ x {1d11e}" muss benutzt werden; In ähnlicher Weise in ECMaskript 2015 (JavaScript), das Escape -Format ist "\ u {1d11e}". In vielen anderen Fällen (wie Java außerhalb von regulären Ausdrücken),[28] Der einzige Weg, um Nicht-BMP-Zeichen zu erhalten, besteht darin, beispielsweise die Ersatzhälften einzeln einzeln einzeln einzugeben: "\ ud834 \ udd1e" für u+1d11e.

String-Implementierungen basierend auf UTF-16 definieren typischerweise die Längen der Zeichenfolge und ermöglichen die Indexierung in Bezug auf diese 16-Bit Codeeinheiten, nicht in Bezug auf Codepunkte. Weder Codepunkte noch Codeeinheiten entsprechen irgendetwas, was ein Endbenutzer als „Zeichen“ erkennen kann. Die Dinge, die Benutzer als Zeichen identifizieren können, können im Allgemeinen aus einem Basiscodepunkt und einer Abfolge von Kombination von Zeichen bestehen (oder eine Abfolge von Codepunkten einer anderen Art sein, beispielsweise Hangul -Konjizieren von Jamos) - Unicode bezieht sich auf dieses Konstrukt als Graphem Cluster[29]- Und als solche müssen Anwendungen, die sich mit Unicode -Zeichenfolgen befassen, unabhängig von der Codierung, mit der Tatsache fertig werden, dass dies ihre Fähigkeit einschränkt, Strings willkürlich zu teilen und zu kombinieren.

UCS-2 wird auch von der unterstützt Php Sprache[30] und Mysql.[7]

Schnell, Version 5, ApfelDie bevorzugte Anwendungssprache, die von UTF-16 auf UTF-8 als bevorzugte Codierung umgestellt wurde.[31]

Siehe auch

Anmerkungen

  1. ^ Die UTF-8-Codierung erzeugt Byte-Werte streng weniger als 0xFE, so dass entweder Byte in der BOM-Sequenz auch die Codierung als UTF-16 identifiziert (vorausgesetzt, UTF-32 ist nicht erwartet).
  2. ^ Die Verwendung von U+Feff als Zeichen zwnbsp anstelle von als bom wurde zugunsten von u+2060 (Word -Joiner) veraltet; sehen Byte Order Mark (BOM) FAQ bei unicode.org. Wenn eine Anwendung jedoch eine anfängliche BOM als Zeichen interpretiert, ist das zWNBSP -Zeichen unsichtbar, sodass die Auswirkung minimal ist.
  3. ^ RFC 2781 Abschnitt 4.3 besagt, dass "der Text als Big-Endian interpretiert werden sollte", wenn es keine gebliebene BOM gibt. " Gemäß Abschnitt 1.2 wird die Bedeutung des Begriffs "sollte" von geregelt RFC 2119. In diesem Dokument heißt es in Abschnitt 3: "... es kann in bestimmten Umständen gültige Gründe vorliegen, einen bestimmten Punkt zu ignorieren, aber die vollen Auswirkungen müssen vor der Auswahl eines anderen Kurs verstanden und sorgfältig abgewogen werden."

Verweise

  1. ^ a b "Was ist UTF-16?". Das Unicode -Konsortium. Unicode, Inc. Abgerufen 29. März 2018.
  2. ^ a b "Verwenden Sie die Windows UTF -8 -Code -Seite - UWP -Anwendungen". docs.microsoft.com. Abgerufen 2020-06-06. Ab der Windows-Version 1903 (Mai 2019-Update) können Sie die ActiveCodePage-Eigenschaft im AppXManifest für verpackte Apps oder das Fusion-Manifest für entpackte Apps verwenden, um einen Prozess zur Verwendung von UTF-8 als Prozesscode-Seite zu erzwingen. [..] CP_ACP gleich CP_UTF8 Nur wenn Sie unter Windows Version 1903 (Mai 2019-Update) oder höher ausgeführt werden und die oben beschriebene Aktivität von ActiveCodePage auf UTF-8 eingestellt ist. Andernfalls ehrt es die Seite "Legacy System Code". Wir empfehlen die Verwendung CP_UTF8 ausdrücklich.
  3. ^ "HTML Living Standard". W3.org. 2020-06-10. Abgerufen 2020-06-15. UTF-16-Codierungen sind die einzigen Codierungen, die diese Spezifikation als nicht um ASCII-kompatible Codierungen behandeln muss.
  4. ^ "Nutzungsstatistik von UTF-16 für Websites, Juni 2021". w3techs.com. Abgerufen 2021-06-17.
  5. ^ "Nutzungsstatistik von UTF-8 für Websites, November 2021". w3techs.com. Abgerufen 2021-11-10.
  6. ^ "Codierungsstandard". coding.spec.whatwg.org. Abgerufen 2018-10-22. Die UTF-8-Codierung ist die am besten geeignete Codierung für den Austausch von Unicode, der universelle codierte Zeichensatz. Daher erfordert diese Spezifikation für neue Protokolle und Formate sowie vorhandene Formate, die in neuen Kontexten bereitgestellt wurden, die UTF-8-Codierung. [..] Die hier beschriebenen Probleme verschwinden, wenn sie ausschließlich UTF-8 verwenden. Dies ist einer der vielen Gründe, warum UTF-8 jetzt die obligatorische Codierung für alle Text Dinge im Web ist.
  7. ^ a b "MySQL :: Mysql 5.7 Referenzhandbuch :: 10.1.9.4 Der UCS2-Zeichensatz (UCS-2 Unicode-Codierung)". dev.mysql.com.
  8. ^ "Fragen zu Codierungsformen". Abgerufen 2010-11-12.
  9. ^ ISO/IEC 10646: 2014 "Informationstechnologie - Universal Coded Character Set (UCS)" Abschnitte 9 und 10.
  10. ^ Der Unicode -Standard Version 7.0 (2014) Abschnitt 2.5.
  11. ^ "Die Unicode® Standard Version 10.0 - Kernspezifikation. Anhang C Beziehung zu ISO/IEC 10646" (PDF). Unicode -Konsortium. Abschnitt C.2 Seite 913 (PDF Seite 10)
  12. ^ "Unicode -Charakter -Codierungsstabilitätsrichtlinien". unicode.org.
  13. ^ "Es ist nicht falsch, dass" ‍eitung ".Length == 7". hSivonen.fi. Abgerufen 2021-03-15.
  14. ^ "Apple Developer Dokumentation". Entwickler.apple.com. Abgerufen 2021-03-15.
  15. ^ Yerdeau, Francois; Hoffman, Paul (Februar 2000). "UTF-16, eine Codierung von ISO 10646". Tools.ietf.org. Abgerufen 2019-06-18.
  16. ^ Allen, Julie D.; Anderson, Deborah; Becker, Joe; Cook, Richard, Hrsg. (2014). "3.8 Ersatz" (PDF). Die Unicode Standard, Version 7.0 - CORE -Spezifikation. Blick auf die Berge: Das Unicode -Konsortium. p. 118. Abgerufen 3. November 2014.
  17. ^ Unicode (Windows). Abgerufen 2011-03-08 "Diese Funktionen verwenden UTF-16 (Wide Character) -Codierung (…) für native Unicode-Codierung auf Windows-Betriebssystemen."
  18. ^ "Unicode". microsoft.com. Abgerufen 2009-07-20.
  19. ^ "Ersatz- und ergänzende Charaktere". microsoft.com. Abgerufen 2009-07-20.
  20. ^ "Beschreibung des Speicherns von UTF-8-Daten in SQL Server". microsoft.com. 7. Dezember 2005. Abgerufen 2008-02-01.
  21. ^ "[Aktualisiert] Patch für cmd.exe für Windows XP für CP 65001 - Seite 2 - dostips.com". www.dostips.com. Abgerufen 2021-06-17.
  22. ^ "UCS-2 und seine Beziehung zu Unicode (UTF-16)". IBM. Abgerufen 2019-04-26.
  23. ^ Selph, Chad (2012-11-08). "Abenteuer in Unicode SMS". Dämmerung. Archiviert von das Original Am 2012-11-09. Abgerufen 2015-08-28.
  24. ^ "PEP 261 - Unterstützung für" breite "Unicode -Zeichen". Python.org. Abgerufen 2015-05-29.
  25. ^ "PEP 0393 - Flexible String -Darstellung". Python.org. Abgerufen 2015-05-29.
  26. ^ "JavaScripts interne Zeichenkodierung: UCS-2 oder UTF-16? · Mathias Bynens".
  27. ^ "ECMA-334: 9.4.1 Unicode Escape-Sequenzen". en.csharp-online.net. Archiviert von das Original Am 2013-05-01.
  28. ^ Lexikalische Struktur: Unicode entkommt in "Die Java -Sprachspezifikation, dritte Ausgabe". Sun Microsystems, Inc.. 2005. Abgerufen 2019-10-11.
  29. ^ "Glossar der Unicode -Begriffe". Abgerufen 2016-06-21.
  30. ^ "PHP: Unterstützte Zeichenkodierungen - Handbuch". php.net.
  31. ^ "UTF-8 String". Swift.org. 2019-03-20. Abgerufen 2020-08-20.

Externe Links