Unicode

(Auszug aus "XML in a Nutshell" von Elliotte Rusty Harold & W. Scott Means)

Unicode ist ein international standardisierter Zeichensatz, mit dem Sie Dokumente in jeder Sprache schreiben können, die Sie jemals in Ihrem Leben sprechen, lernen oder irgendwie anders wahrnehmen werden – es sei denn, Sie werden von Außerirdischen entführt. Version 4.0.1, die im Juni 2004 aktuelle Version, enthält 96.447 Zeichen aus den meisten der lebenden Sprachen der Welt, ebenso wie aus einigen toten. (Anmerkung der data2type-Redaktion: Version 7.0.0 von Juni 2014 enthält 113.021 Zeichen.) Unicode deckt mit Leichtigkeit das lateinische Alphabet ab. Unicode enthält außerdem vom Griechischen abgeleitete Sprachen, wie altes und modernes Griechisch, sowie die kyrillischen Schriften, die in Serbien und einem großen Teil der früheren Sowjetunion verwendet werden. Unicode deckt verschiedene ideographische Schriften ab, einschließlich des Han-Zeichensatzes, der für Chinesisch und Japanisch benutzt wird, der koreanischen Hangul-Silbenschrift sowie phonetischer Repräsentationen dieser Sprachen einschließlich Katakana und Hiragana. Es deckt die von rechts nach links laufenden arabischen und hebräischen Schriften ab. Und es enthält auch die verschiedenen Schriften, die auf dem indischen Subkontinent heimisch sind, inklusive Devanagari, Thai, Bengali, Tibetisch und viele andere. Und das ist weniger als die Hälfte der Schriften in Unicode 4.0. Vermutlich weniger als jeder Tausendste spricht heutzutage eine Sprache, die nicht vernünftig in Unicode repräsentiert werden kann. In der Zukunft soll Unicode um weitere Zeichen erweitert werden, wodurch sich diese geringe Zahl noch verkleinert. Potenziell kann Unicode mehr als eine Million Zeichen aufnehmen, aber niemand ist bereit, in der Öffentlichkeit zuzugeben, woher seiner Meinung nach die verbleibende Million Zeichen stammen werden. Nach ein paar Bier geben einige Entwickler bereitwillig zu, dass sie sich auf den Tag vorbereiten, an dem wir Teil der Intergalaktischen Föderation mit Tausenden intelligenter Spezies sind.

Der Unicode-Zeichensatz weist Zeichen Kodepunkten zu: Zahlen. Diese Zahlen können dann anhand verschiedener Schemas kodiert werden, einschließlich:

  • UCS-2
  • UCS-4
  • UTF-8
  • UTF-16

UCS-2 und UTF-16

UCS-2, auch als ISO-10646-UCS-2 bezeichnet, repräsentiert jedes Zeichen als zwei Byte langen, nicht vorzeichenbehafteten Integer-Wert zwischen 0 und 65.535. Das heißt, der Großbuchstabe A, Kodepunkt 65 in Unicode, wird durch die beiden Bytes 00 und 41 (als Hexadezimalwert) dargestellt. Der Großbuchstabe B, Kodepunkt 66, wird durch die beiden Bytes 00 und 42 repräsentiert. Die zwei Bytes 03 und A3 repräsentieren den griechischen Großbuchstaben Σ, Kodepunkt 931.

UCS-2 gibt es in zwei Spielarten: MSB (Big Endian) und LSB (Little Endian). Im MSB-UCS-2 kommt das höchstwertige Byte des Zeichens zuerst. Im LSB-UCS-2 ist die Reihenfolge umgekehrt. Das bedeutet, dass im MSB-UCS-2 der Großbuchstabe A #x0041 ist. (Aus Gründen, auf die wir noch eingehen werden, folgt dieses Werk der Konvention, dass hexadezimalen Zahlen ein #x vorangestellt wird. Zwei Hexadezimalstellen bilden ein Byte.) Im LSB-UCS-2 sind die Bytes vertauscht, und A ist #x4100. Im MSB-UCS-2 ist der Buchstabe B #x0042. Im LSB-UCS-2 ist er #x4200. Im MSB-UCS-2 ist der Buchstabe Σ #x03A3. Im LSB-UCS-2 ist er #xA303. Hier benutzen wir die MSB-Notation, allerdings können Parser nicht davon ausgehen. Sie müssen in der Lage sein, die Stellung der Bytes aus dem Dokument selbst zu erkennen.

Um zwischen MSB- und LSB-UCS-2 zu unterscheiden, beginnt ein Dokument, das in UCS-2 kodiert wurde, immer mit dem Unicode-Zeichen #xFEFF, einem geschützten Leerzeichen, dessen Breite null ist. Üblicherweise wird dieses Zeichen Byte-Order-Markierung (Markierung der Byte-Reihenfolge) genannt. Dieses Zeichen hat den Vorteil, dass es unsichtbar ist. Werden seine Bytes vertauscht, tritt darüber hinaus der Effekt ein, dass das entstehende Zeichen #xFFFE gar nicht existiert. Ein Programm kann sich daher die beiden ersten Bytes eines UCS-2-Dokuments anschauen und – je nachdem, ob die Bytes #xFEFF oder #xFFFE sind – auf der Stelle feststellen, ob die Kodierung eines Dokuments MSB ist oder nicht.

UCS-2 besitzt jedoch drei wichtige Nachteile:

  • Dateien, die fast ausschließlich Text in lateinischen Zeichen enthalten, sind in UCS-2 fast zweimal so lang, wie sie in einem Zeichensatz wären, dessen Zeichen nur ein Byte lang sind, wie ASCII oder Latin-1.
  • UCS-2 ist nicht abwärts- oder aufwärtskompatibel zu ASCII. Werkzeuge, die auf ein Byte lange Zeichensätze eingestellt sind, können eine UCS-2-Datei oftmals nicht vernünftig verarbeiten, selbst wenn die Datei nur Zeichen aus dem ASCII-Zeichensatz enthält. Beispielsweise würde ein Programm, das in C geschrieben wurde und erwartet, dass das Null-Byte Strings abschließt, sich an einer UCS-2-Datei verschlucken, die hauptsächlich englischen Text enthält, da fast jedes zweite Byte null ist.
  • UCS-2 ist auf 65.536 Zeichen begrenzt.

Das letzte Problem ist in der Praxis nicht so bedeutend, da die ersten 65.536 Kodepunkte von Unicode bereits den Bedarf der meisten Menschen befriedigen, mit Ausnahme von toten Sprachen wie Ugaritisch, fiktiven Schriften wie Tengwar sowie musikalische und einige mathematische Symbole. Unicode stellt jedoch eine Methode bereit, um Kodepunkte jenseits von 65.535 zu repräsentieren, indem bestimmte zwei Byte lange Sequenzen als Hälfte eines Ersatzpaares erkannt werden. Ein Unicode-Dokument, das UCS-2 plus Ersatzpaare benutzt, liegt in der so genannten UTF-16-Kodierung vor.

Die anderen beiden Probleme werden wahrscheinlich die meisten Entwickler betreffen. UTF-8 ist eine alternative Kodierung zu Unicode, die beide Probleme löst.

UTF-8

UTF-8 ist eine Kodierung variabler Länge für Unicode. Die Zeichen 0 bis 127, das heißt der ASCII-Zeichensatz, werden mit jeweils einem Byte kodiert, genau wie in ASCII. In ASCII repräsentiert das Byte mit dem Wert 65 den Buchstaben A. In UTF-8 repräsentiert das Byte mit dem Wert 65 ebenfalls den Buchstaben A. Es gibt eine Eins-zu-Eins-Abbildung von ASCII-Zeichen auf UTF-8-Bytes. Das bedeutet: Reine ASCII-Dateien sind ebenso akzeptable UTF-8-Dateien.

UTF-8 repräsentiert die Zeichen 128 bis 2.047 in jeweils zwei Bytes. Das ist ein Bereich, der die meisten nicht-ideographischen Schriften abdeckt. Die Zeichen von 2.048 bis 65.535, hauptsächlich aus Chinesisch, Japanisch und Koreanisch, werden in jeweils drei Bytes dargestellt. Zeichen mit Kodepunkten über 65.535 werden in jeweils vier Bytes kodiert. Für eine Datei, die hauptsächlich aus lateinischen Buchstaben besteht, halbiert dieses System effektiv die Dateigröße gegenüber UCS-2. Besteht eine Datei dagegen vor allen Dingen aus Japanisch, Chinesisch oder einer der Sprachen des indischen Subkontinents, kann die Dateigröße um 50 Prozent anwachsen. Für die meisten anderen lebenden Sprachen ist die Dateigröße in etwa die gleiche wie bei einer UCS-2-Kodierung.

UTF-8 ist vermutlich die am weitesten unterstützte Kodierung von Unicode. Es ist zum Beispiel die Kodierung, in der Java-.class-Dateien Strings abspeichern, es ist die native Kodierung von BeOS, und es ist die Default-Kodierung, die ein XML-Prozessor annimmt, es sei denn, durch eine Byte-Order-Markierung oder eine Encoding-Deklaration wurde etwas anderes festgelegt. Wenn ein Programm Ihnen mitteilt, dass es Unicode speichert, ist es ziemlich wahrscheinlich, dass es eigentlich UTF-8 benutzt.

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema XML bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

  


Copyright © 2005 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "XML in a Nutshell" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de