Warum gibt es mehrere Unicode-Codierungen?

Ich dachte, Unicode wurde entwickelt, um das Problem der vielen unterschiedlichen Codierungen zu umgehen, da bei den meisten früheren Versuchen (ASCII usw.) nur ein kleiner Adressraum (8 Bit) zur Verfügung stand.

Warum gibt es dann so viele Unicode-Codierungen? Sogar mehrere Versionen des (im Wesentlichen) gleichen, wie UTF-8, UTF-16 usw.

Weil die Leute nicht 21 Bits für jeden Charakter ausgeben wollen. Auf allen modernen Systemen würde dies im Wesentlichen bedeuten, drei Bytes pro Zeichen zu verwenden, was dreimal mehr ist als das, was die Leute gewohnt waren, so dass sie überhaupt nicht bereit waren, Unicode zu übernehmen. Es mussten Kompromisse gefunden werden: UTF-8 eignet sich z. B. hervorragend für englischen Text, da ältere ASCII-Dateien überhaupt nicht konvertiert werden müssen, aber für europäische Sprachen weniger nützlich und für asiatische Sprachen von geringem Nutzen sind.

Grundsätzlich hätten wir also eine einzige universelle Kodierung sowie eine einzige universelle Zeichentabelle definieren können, aber der Markt hätte dies nicht akzeptiert.

Unicode ist ein 21-Bit-Zeichen, das die eindeutig beschriebenen "CodePoints" codiert, wobei die einzelnen Codepunkte durch ein Symbol (eine grafische Darstellung) dargestellt werden.

• 16 Bits zur Identifizierung eines Codepunkts in einer Ebene (die meisten Codepunkte befinden sich in Ebene 0).
• 5 Bits zur Identifizierung der Ebene.

Die unterstützten Codierungen sind:

• UTF-8 (um jeden Punkt mit 8-Bit-Werten zu codieren)
• UTF-16 (um jeden Punkt mit 16-Bit-Werten zu codieren)
• UTF-32 (um jeden Punkt mit 32-Bit-Werten zu codieren)

Unabhängig von der Codierung ordnen sie sich beim Decodieren alle einem bestimmten Codepunkt zu, der dieselbe Bedeutung hat (weshalb es cool ist).

• 'A' (U + 65)
  UTF-32 => 0x00000041 UTF-16 => 0x0041 UTF-8 => 0x41
• LATIN SMALL LIGATURE OE '(U + 0153)
  UTF-32 => 0x00000153 UTF-16 => 0x0153 UTF-8 => 0xC5 0x93
• Nicht zugewiesen (U + 11153)
  UTF-32 => 0x00011153 UTF-16 => 0xD804 0xDD53 UTF-8 => 0xF0 0x91 0x85 0x93

UTF-8

Dies ist ein Format mit variabler Größe. Wobei jeder Codepunkt durch 1 bis 4 Bytes dargestellt wird.

UTF-16

Dies ist ein Format mit variabler Größe. Die Codepunkte in der "Mehrsprachigen Grundebene" (BMP oder Ebene 0) können durch 1 einzelnen 16-Bit-Wert dargestellt werden. Codepunkte in anderen Ebenen werden durch ein Ersatzpaar (2 16-Bit-Werte) dargestellt.

UTF-32

Dies ist ein Format mit fester Größe. Alle Codepunkte werden durch einen einzelnen 32-Bit-Wert dargestellt.

Ich denke, es ist nützlich, die beiden Ideen zu trennen:

1. Unicode - Zuordnung von Zeichen aus aller Welt zu Codepunkten.
2. Codierung - Zuordnung von Codepunkten zu Bitmustern (UTF-8, UTF-16 usw.).

UTF-8, UTF-16 und andere Kodierungen haben jeweils ihre eigenen Vor- und Nachteile. Wenden Sie sich dazu besser an Wikipedia .

UTF-7, UTF-8, UTF-16 und UTF-32 sind einfach algorithmische Transformationsformate derselben Kodierung (Kodepunkte) von Zeichen. Sie sind Kodierungen eines Systems zur Kodierung von Zeichen.

Sie sind auch algorithmisch einfacher vorwärts und rückwärts zu navigieren als die meisten vorherigen Schemata für den Umgang mit Zeichensätzen, die größer als 256 Zeichen sind.

Dies unterscheidet sich stark von der landes- und manchmal herstellerspezifischen Kodierung von Glyphen. Alleine auf Japanisch gab es eine Menge Variationen von JIS, ganz zu schweigen von EUC-JP und der Codepage-orientierten Umwandlung von JIS, die DOS / Windows-Maschinen mit der Bezeichnung Shift-JIS verwendeten. (Bis zu einem gewissen Grad gab es algorithmische Transformationen von diesen, aber sie waren nicht besonders einfach und es gab herstellerspezifische Unterschiede in den verfügbaren Zeichen. Multiplizieren Sie dies mit ein paar hundert Ländern und der schrittweisen Entwicklung komplexerer Schriftsysteme (Post-Greenscreen) Ära), und Sie hatten einen echten Albtraum.

Warum brauchen Sie diese Transformationsformen von Unicode? Da viele ältere Systeme Sequenzen mit 7-Bit-Zeichen im ASCII-Bereich voraussetzten, brauchten Sie eine saubere 7-Bit-Lösung, mit der Daten sicher und fehlerfrei durch diese Systeme geleitet werden können. Dann brauchten Sie UTF-7. Dann gab es modernere Systeme, die mit 8-Bit-Zeichensätzen umgehen konnten, aber Nullen hatten im Allgemeinen eine besondere Bedeutung, sodass UTF-16 für sie nicht funktionierte. 2 Bytes könnten die gesamte mehrsprachige Grundebene von Unicode in ihrer ersten Inkarnation codieren, sodass UCS-2 für Systeme, die von Grund auf "Unicode-fähig" sein sollten (wie Windows NT und die Java-VM), als vernünftiger Ansatz erscheint. dann erforderten die Erweiterungen darüber hinaus zusätzliche Zeichen, was zur algorithmischen Transformation der 21-Bit-Codierungen führte, die durch den Unicode-Standard reserviert wurden, und es wurden Ersatzpaare geboren; das erforderte UTF-16. Wenn Sie eine Anwendung hatten, bei der die Konsistenz der Zeichenbreite wichtiger war als die Effizienz der Speicherung, war UTF-32 (früher als UCS-4 bezeichnet) eine Option.

UTF-16 ist das einzige Problem, mit dem man sich aus der Ferne befassen muss. Dies lässt sich durch die geringe Anzahl von Zeichen, die von dieser Transformation betroffen sind, und durch die Tatsache, dass die führenden 16-Bit-Sequenzen in einem völlig anderen Bereich liegen als die nachfolgenden 16-Bit-Sequenzen. Es ist auch um Welten einfacher, als in vielen frühen ostasiatischen Codierungen vorwärts und rückwärts zu gehen, in denen Sie entweder einen Zustandsautomaten (JIS und EUC) für die Verarbeitung der Escape-Sequenzen benötigen oder möglicherweise mehrere Zeichen zurücksetzen müssen, bis Sie etwas gefunden haben, das garantiert ist nur ein führendes Byte sein (Shift-JIS). UTF-16 hatte einige Vorteile auf Systemen, die auch 16-Bit-Sequenzen effizient durchlaufen konnten.

Man könnte meinen, es sei denn, man müsse Dutzende (Hunderte, wirklich) verschiedener Codierungen durchstehen oder Systeme bauen, die mehrere Sprachen in unterschiedlichen Codierungen unterstützen, manchmal sogar im selben Dokument (wie WorldScript in den älteren MacOs-Versionen) der Unicode-Transformationsformate als unnötige Komplexität. Gegenüber früheren Alternativen wird die Komplexität jedoch drastisch reduziert, und jedes Format löst eine echte technische Einschränkung. Sie sind auch wirklich effizient untereinander konvertierbar und erfordern keine komplexen Nachschlagetabellen.

Unicode wurde nicht entwickelt, um das Problem der vielen verschiedenen Codierungen zu umgehen.

Unicode wurde entwickelt, um die gesamte Ausgabe einer Zahl zu umgehen, die je nach verwendeter Codepage viele verschiedene Dinge darstellt. Die Nummern 0 bis 127 stehen für die gleichen Zeichen in jeder Ansi-Codepage. Dies wird auch als ASCII-Diagramm oder Zeichensatz bezeichnet. In Ansi-Codepages, die 256 Zeichen zulassen, stehen die Nummern 128 bis 255 für verschiedene Zeichen in verschiedenen Codepages.

Zum Beispiel

• Die Zahl $ 57 steht für ein W in Großbuchstaben in allen Codepages, jedoch
• Die Zahl $ EC steht für das Inifinity-Symbol in Codepage 437 (USA), jedoch für einen "LATIN SMALL LETTER N WITH CEDILLA" in Codepage 775 (Baltikum).
• Das Cent-Zeichen hat die Nummer $ 9B in Codepage 437, aber die Nummer 96 in Codepage 775

Was Unicode tat, war dies alles auf den Kopf zu stellen. In Unicode gibt es keine "Wiederverwendung". Jede Zahl steht für ein einzelnes Zeichen. Die Zahl $ 00A2 in Unicode ist das Cent-Zeichen und das Cent-Zeichen wird an keiner anderen Stelle in der Unicode-Definition angezeigt.

Warum gibt es dann so viele Unicode-Codierungen? Sogar mehrere Versionen des (im Wesentlichen) gleichen, wie UTF-8, UTF-16 usw.

Es gibt keine mehreren Versionen derselben Kodierung. Es gibt mehrere Codierungen derselben Unicode-Zeichendefinitionszuordnung, die "erfunden" wurden, um die Speicheranforderungen für unterschiedliche Verwendungen der verschiedenen in Unicode vorhandenen lingualen Ebenen zu verwalten.

Unicode definiert (oder hat den Raum, um zu definieren) 4.294.967.295 eindeutige Zeichen. Wenn Sie diese ohne algorithmische Konvertierungen auf den Platten- / Arbeitsspeicher abbilden möchten, benötigen Sie 4 Bytes pro Zeichen. Wenn Sie Texte mit Zeichen aus allen Sprachebenen speichern müssen, ist UTF-32 (im Grunde genommen eine direkte 1-Zeichen- 4-Byte-Speicherkodierung der Unicode-Definition) wahrscheinlich das Richtige für Sie.

In kaum einem Text werden Zeichen aus allen Sprachen verwendet. Und dann scheint die Verwendung von 4 Bytes pro Zeichen eine große Verschwendung zu sein. Insbesondere, wenn Sie berücksichtigen, dass die meisten Sprachen auf der Erde in der sogenannten mehrsprachigen Grundebene (BMP) definiert sind: den ersten 65536-Zahlen der Unicode-Definition.

Und genau hier kam UTF-16 ins Spiel. Wenn Sie nur Zeichen aus dem BMP verwenden, speichert UTF-16 dies sehr effizient mit nur zwei Bytes pro Zeichen. Es werden nur mehr Bytes für Zeichen außerhalb des BMP verwendet. Die Unterscheidung zwischen UTF-16LE (Little Endian) und UTF-16BE (Big Endian) hat wirklich nur etwas damit zu tun, wie Zahlen im Computerspeicher dargestellt werden (Byte-Muster A0bedeutet hex $ A0 oder $ 0A).

Wenn Ihr Text noch weniger verschiedene Zeichen enthält, wie die meisten Texte in westeuropäischen Sprachen, möchten Sie die Speicheranforderungen für Ihre Texte noch weiter einschränken. Daher UTF-8, das ein einzelnes Byte zum Speichern der im ASCII-Diagramm vorhandenen Zeichen (die ersten 128 Ziffern) und eine Auswahl aus den Ansi-Zeichen (die zweiten 128 Ziffern der verschiedenen Codepages) verwendet. Es werden nur mehr Bytes für Zeichen außerhalb dieses "am häufigsten verwendeten Zeichensatzes" verwendet.

Um es noch einmal zusammenzufassen:

• Unicode ist eine Zuordnung der Zeichen in allen Sprachen der Erde (und einige klingonische, um zu starten) und einige (mathematisch, musikalisch usw.) zu einer eindeutigen Zahl.
• Codierungen sind Algorithmen, die definiert wurden, um Texte unter Verwendung der Nummern dieser eindeutigen Zeichentabelle so platzsparend wie möglich zu speichern, wenn die "durchschnittliche Verwendung" von Zeichen in Texten gegeben ist.

Unicode definiert die Zuordnung zwischen Zahlen und Zeichen. Wenn Sie jedoch eine Nummer an einen Empfänger senden, müssen Sie noch definieren, wie diese Nummer dargestellt werden soll. Dafür ist UTF da. Es definiert, wie eine Zahl in einem Byte-Stream dargestellt wird.

Das Grundprinzip von UTF-32 ist einfach: Es ist die einfachste Darstellung von Unicode-Codepunkten. Warum ist nicht alles in UTF-32? Zwei Hauptgründe:

Eins ist Größe . UTF-32 benötigt 4 Bytes für jedes Zeichen. Bei Text, der nur Zeichen an der Basis-Mehrsprachigkeit verwendet, ist dies doppelt so viel Speicherplatz wie bei UTF-16. Für englischen Text ist der Platz viermal so groß wie für US-ASCII.

Der größere Grund ist die Abwärtskompatibilität . Jede andere Unicode-Codierung als die "nicht codierte" UTF-32-Codierung wurde aus Gründen der Abwärtskompatibilität mit einem früheren Standard entwickelt.

• UTF-8: Abwärtskompatibilität mit US-ASCII.
• UTF-16: Abwärtskompatibilität mit UCS-2 (16-Bit-Unicode, bevor es über das BMP hinaus erweitert wurde).
• UTF-7: Abwärtskompatibilität mit nicht 8-Bit-bereinigten Mailservern.
• GB18030: Abwärtskompatibilität mit den Kodierungen GB2312 und GBK für Chinesisch.
• UTF-EBCDIC: Abwärtskompatibilität mit der Basic Latin-Teilmenge von EBCDIC.

Ich dachte, Unicode wurde entwickelt, um das Problem der vielen verschiedenen Codierungen zu umgehen

Es war und es tat. Es ist viel einfacher, zwischen UTF-8, -16 und -32 zu konvertieren, als mit dem alten System von Hunderten verschiedener Zeichenkodierungen für verschiedene Sprachen und verschiedene Betriebssysteme umzugehen.

Sie wissen, dass eine Zip-Datei eine Datei so komprimieren kann, dass sie viel kleiner ist (insbesondere Text), und diese dann zu einer identischen Kopie der Originaldatei dekomprimieren kann.

Der Zipping-Algorithmus verfügt tatsächlich über mehrere verschiedene Algorithmen mit verschiedenen Merkmalen zur Auswahl: gespeichert (keine Komprimierung), verkleinert, verkleinert (Methoden 1 bis 4), implodiert, Tokenisieren, entleert, entleert64, BZIP2, LZMA (EFS), WavPack, PPMd, wo es theoretisch alle versuchen und das beste Ergebnis wählen könnte, aber normalerweise einfach mit Entleert gehen.

UTF funktioniert ähnlich. Es gibt mehrere Codierungsalgorithmen mit jeweils unterschiedlichen Merkmalen, aber Sie wählen in der Regel nur UTF-8, da es im Gegensatz zu den anderen UTF-Varianten weitgehend unterstützt wird, was wiederum darauf zurückzuführen ist, dass es bitweise mit 7-Bit-ASCII kompatibel ist, was es einfach macht Verwendung auf den meisten modernen Computerplattformen, die normalerweise eine 8-Bit-Erweiterung von ASCII verwenden.