Unicode. Geschichte und aktuelle Herausforderungen der digitalen Zeichenkodierung

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Geschichte von Unicode
2.1 Vorgeschichte - die Entwicklung der verschiedenen Zeichensätze
2.1.1 Baudot-Code
2.1.2 Murray-Code
2.1.3 Fielddata-Zeichensatz
2.1.4 US-ASCII
2.1.5 Lokalisierte 7-Bit-Zeichensätze
2.1.6 Lokalisierte 8-Bit-Zeichensätze
2.1.7 Ostasiatische Schriftsysteme
2.2 Die Geburt von Unicode
2.2.1 Erste Versuche bei Xerox
2.2.2 Die Rolle von Apple
2.2.3 Die Unicode-Arbeitsgruppe
2.2.4 Das Unicode-Konsortium
2.2.5 ISO-Standardisierung
2.2.6 Notation für Codepunkte
2.3 Stetige Weiterentwicklung bis heute
2.3.1 Mehr Zeichen mit UCS-4/UTF32
2.3.2 Von UCS-2 zu UTF-16
2.3.3 UTF-8
2.3.4 Aufbau und Umfang von Unicode heute

3 Probleme und Herausforderungen
3.1 Technische Schwierigkeiten
3.1.1 Limitierungen von Schriftarten
3.1.2 Rendern von Zeichen
3.1.3 Email-Adressen
3.1.4 Aufwärtskompatibilität von Software
3.1.5 Schwierigkeiten mit BOM
3.1.6 Normalisierung
3.2 Sicherheitsaspekte
3.3 Weitergehende Nutzung von Symbolen
3.4 Akzeptanz in Ostasien
3.5 Umfang der CJK-Zeichen

4 Fazit und Ausblick

Literatur

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

1 Han-Vereinheitlichung: Han-Zeichen in CJK-Schriften

2 Vergleich verschiedener UTF-Kodierungen

3 Unicode-Ebenen

1 Einleitung

Mit der zunehmenden Globalisierung und der umfassenden Ausbreitung des Inter­nets bekommt der internationale Austausch von Informationen immer größere Be­deutung. Von Anfang an waren die limiterten Computer-Zeichensätze dabei proble­matisch. Seit einigen Jahren wird mit Unicode versucht, die Probleme umfassend zu lösen.

Die vorliegende Arbeit gibt einen Überblick über die Geschichte von Unicode und zeigt einige aktuelle Probleme im Zusammenhang mit Unicode auf. Dafür wurde vor allem auf den Internet-Seiten der verschiedenen Standardisierungsorganisationen wie Unicode Consortium, ITU, IETF, W3C recherchiert.

Im Abschnitt zwei der Arbeit wird ein historischer Überblick gegeben werden, der die Entwicklung hin zu Unicode aufzeigt, er endet mit einer Bestandsaufnahme der Verwendung und Verbreitung von Unicode im Jahr 2015. Der dritten Abschnitt soll einige der aktuellen Probleme und Herausforderungen aufzeigen, die im Zusam­menhang mit Unicode stehen. Im letzten Abschnitt wird ein Fazit gezogen und ein Ausblick zu dem Thema gegeben.

2 Geschichte von Unicode

2.1 Vorgeschichte - die Entwicklung der verschiedenen Zeichensätze

2.1.1 Baudot-Code

Die Geschichte der Zeichenkodierung kann bis ins 19. Jahrhundert zurückverfolgt werden. Bei der damals bereits verbreiteten Telegrafie mit Morsecode war immer spezialisiertes Bedienpersonal für die Umwandlung von Text in Morsecode und zu­rück notwendig. Um die Nachrichtentexte automatisch zu codieren, entwickelte 1870 der französischer Ingenieur und Erfinder Jean-Maurice-Émile Baudot (1845-1903) einen 5-Bit-Code und entsprechende Sende- und Empfangsgeräte. Da die hierbei ver­fügbaren 31 Kodierungen (00000b kann nicht verwendet werden) nicht ausreichen, um zumindest alle Buchstaben und Ziffern zu kodieren, wurden zwei Kodierungs­Ebenen verwendet, zwischen denen mit speziellen Steuerzeichen umgeschaltet wer­den konnte. Die erste Ebene enthielt im Wesentlichen die Großbuchstaben und in der zweiten Ebene waren Ziffern und einige Sonderzeichen kodiert. Im Jahr 1874 wurde das Verfahren in Frankreich patentiert. In den folgenden Jahren fand das Baudot-Fernschreibersystem Verbreitung in Frankreich, Europa und darüber hin­aus.

Bereits in dieser Zeit vor über 100 Jahren gab es jedoch schon das Problem der vielen verschiedenen Zeichen für die europäischen Sprachen, was zu national unter­schiedlichen Zeichenbelegungen führte.

Im Jahr 1926 wurde Baudot zu Ehren die Maßeinheit für die Anzahl der übertrage­nen Symbole pro Sekunde Baud genannt.^[1]

2.1.2 Murray-Code

Der neuseeländische Ingenieur Donald Murray (1865-1945) entwickelte 1901 für ei­ne erleicherte Texteingabe einen Fernschreiber mit Tastatur, ähnlich der zu der Zeit üblichen Schreibmaschienen mit QWERTY-Tasten. Außerdem änderte er die Codie­rung, wobei er sich an der Häufigkeit der Zeichen orientierte, um den Verschleiß der Geräte zu minimieren. Murray führte auch ein Steuerzeichen für einen Zeilenwechsel ein, um Telegrammtexte unterteilen zu können. Später kamen weitere Steuerzeichen hinzu, um sog. Blattschreiber ansteuern zu können, die ganze Seiten beschreiben konnten und nicht nur linear einen Papierstreifen. Der Murray-Code wurde 1932 als CCITT-2 bzw. ITA2 standardisiert und wurde zum Standard-Code in Telex-Netzen.^[2] Die ursprünglich syncrone Übertragung wurde bei CCITT-2 durch eine asyncrone übersetzt, welche jedem Zeichen ein Start- und ein Stopbit hinzufügt. Die Geschwin­digkeit der Fernschreiber in den Telex-Netzen betrug bis zu 600 Zeichen pro Minute, also 10 Baud. Teilweise wurde später noch eine dritte Kodierungsebene eingeführt, um z.B. auch kyrillische Zeichen übertragen zu können.

2.1.3 Fielddata-Zeichensatz

Fielddata war ein US-amerikanisches Militärprojekt in den 1950er und 60er Jah­ren zur umfassenden elektronischen Informationssammlung und -verarbeitung. Zwar wurde das Projekt 1962 aufgrund von Reorganisationsmaßnahmen gestoppt, jedoch wurde im Laufe der Arbeiten ein 6-Bit Zeichensatz definiert, welcher kein Um­schalten zwischen verschiedenen Kondierungsebenen erforderte und als Vorläufer des ASCII-Zeichensatzen angesehen werden kann.

2.1.4 US-ASCII

Das US-amerikanisches Standardisierungs-Institut ASA versuchte eine neue Kon- dierung zu definieren, welche alle Zeichen und Steuercodes der damals bestehenden Standards CCITT-2/ITA2, Fieldata und EBCDIC enthält. Da hierfür die 64 ver­schiedene Codepunkte eines 6-Bit-Systems nicht ausreichend waren, und man aus technischen Erwägungen ein System mit mehreren Ebenen ablehnte, musste ein 7- Bit-Code mit 128 möglichen Codepunkten eingesetzt werden. Der ersten Version von 1963 fehlten noch die Kleinbuchstaben, welche in der Revision von 1968 hin­zugefügt wurden. Dieser ASCII-Zeichensatz ist bis heute gültig. Schon bald wurde die Unterstützung von ASCII für alle staatlichen Systeme der USA gefordert und der neue Standard verbreitete sich rasch. Von Anfang an war ASCII nur als eines von mehreren nationales Kodierungs-Systemen vorgesehen. ASCII ist eigentlich die nationale Version Nr. 6 der internationalen Norm ISO 646.

2.1.5 Lokalisierte 7-Bit-Zeichensätze

In der internationalen Norm ISO 646 sind 1963 verschiedene nationale 7-Bit-Zeichen­sätze definiert worden, die zum Großteil mit US-ASCII übereinstimmen. Da jedoch viele Codepunkte mit den nationalen Schriftzeichen belegt sind, sind die Kodierun­gen nicht kompatibel zu ASCII, vor allem bei den für die Programmierung wichtigen Sonderzeichen. ISO 646 fand daher keine große Verbreitung.

2.1.6 Lokalisierte 8-Bit-Zeichensätze

Als sich Rechnersysteme mit 8, 16 oder 32 Bit durchsetzten und es üblich wurde, für ein Zeichen 8 Bit, also 1 Byte zu verarbeiten und abzuspeichern, bot sich die Gelegenheit, abermals den Zeichensatz zu erweitern, auf nunmehr 256 Codepunkte. Dies ermöglichte Zeichensätze, welche zu ASCII kompatibel waren, da die ersten 128 Zeichen unverändert übernommen werden konnten und nur die oberen 128 Zeichen neu vergeben wurden. Aufgrund fehlender Normierung wurde von den großen IT- Firmen eine Vielzahl proprietärer Kodierungen entwickelt. So gab es für den IBM PC mit dem Betriebs-System DOS die code page 437, von Digital Equipment für das VT220-Terminal DEC-MCS (Multinational Character Set), von Apple Mac OS Roman.3 Diese Systeme waren zwar zu ASCII kompatibel (als Übermenge), jedoch nicht untereinander.

Schließlich wurde von der ISO, der Internationalen Organisation für Normung, der Standard ISO/IEC 8859 verabschiedet, welcher in 10 Unternormen (später 15) ver­schiedene Zeichensätze definiert, welche alle in der unteren Hälfte ASCII enthal­ten, aber in der oberen Hälfte die verschiedenen nationalen Schriftzeichen des latei­nischen, kyrillischen, grieschischen, Arabischen und Hebräischen Alphabets kodie­ren. Microsoft entwickelte aus ISO 8859-1 wiederum den proprietären Zeichensatz Windows-1252. Hier wurden für den Bereich 0x80 bis 0x9F diverse weitere Symbole und Sonderzeichen definiert, da dieser Bereich bei ISO 8859-1 von der Standardisie­rung ausgenommen wurde.

Somit gab es zwar eine Norm für Zeichensätze, jedoch musste man nun für jedes Do­kument wissen bzw. mit angeben, mit welchem Zeichensatz es kodiert ist. Ausserdem war es nicht möglich, verschiedene Schriftsysteme in einem Dokument darzustellen. Zu erwähnen ist auch noch EBCDIC, ein 8-Bit-Zeichensatz von IBM für Main­frames (System/360) entwickelt. EBCDIC ist zwar völlig inkompatibel mit ASCII, hat es jedoch in der Mainframe-Welt zu einiger Verbreitung gebracht. In EBCDIC gibt es reservierte Bereiche für lokale Schriftzeichen, was auch hier zu verschieden Codepage-Varianten führte, die jedoch nie streng normiert wurden.

2.1.7 Ostasiatische Schriftsysteme

Für die verschiedenen asiatischen Schriftsysteme mit Tausenden von Zeichen waren die 8-Bit-Zeichensätze ohnehin völlig unzureichend. Daher wurden in Asien schon sehr früh eigene Lösungen für das Kodierungsproblem entwickelt, wie Big5 (Tai­wan), Shift-JIS (Japan), GB2312 (China). Es handelt sich jeweils um Double-Byte­Kodierungen (DBCS) mit variabler Länge (ein oder 2 Byte) und weitestgehender Kompatibilität mit ASCII. Bei der EUC-CN-Kodierung von GB2312 beispielsweise sind die Zeichen 0-127 identisch mit ASCII, höhere Byte-Werte kodieren 2-Byte- Zeichen, wobei nicht nur die chinesischen Zeichen, sondern auch japanische Hiragana und Katakana, griechische und kyrillische Schrift, chinesische Lautschrift (Bopomo- fo) und viele weitere Sonderzeichen kodiert werden können.

2.2 Die Geburt von Unicode

2.2.1 Erste Versuche bei Xerox

Die US-amerikanische Firma Xerox gründete 1970 im kalifornischen Palo Alto ein großes Forschungs- und Entwicklungszentrum, das Xerox PARC. Nach dem Aus­laufen der Kopier-Patente wollte man auf diesem Weg die führende Rolle bei der Büro-Technik behalten. Im PARC wurden viele innovative Technologien entwickelt, die richtungsweisend für die IT der folgenden Jahrzente wurden. Bis auf den Laser­drucker gelang es Xerox jedoch nicht, die Entwicklungen erfolgreich zu vermarkten. Jedoch pflegte man einen offenen Kommunikationsstil und tauschte sich mit Inge­nieuren anderer Firmen aus, die das PARC besuchen konnten, wie z.B. Steve Jobs von Apple und Bill Gates von Microsoft. In den 1980er Jahren sammelte man bei Xerox mit dem völlig neu entwickeltem (aber wenig erfolgreichen) Bürocomputer­system ’Xerox Star’ schon erste Erfahrung mit Internationalisierung, der Xerox Character Code Standard war bereits ein 16-Bit-Code.

2.2.2 Die Rolle von Apple

Mark Davis von Apple war 1985 in Japan, um an einem neuen Kanji-Macintosh zu arbeiten, also einem Macintosh-Computer, der die japanischen Schriftzeichen verarbeiten kann. Hier lernte er bei der Arbeit mit den japanischen Ingenieuren den Shift-JIS-Standard kennen. Shift-JIS hat sowohl Zeichen mit einem Byte als auch mit zwei Byte. Dies machte die Anpassungen an der Macintosh-Software kompliziert. Zum ersten Mal kam die Idee eines komplett neuen, einheitlichen Zeichensatzes für viele Schriftsysteme auf, diese wurde jedoch zunächst nicht weiter verfolgt. ^[3]

2.2.3 Die Unicode-Arbeitsgruppe

Später, im Jahr 1987, erfuhr Davis von Joseph D. Becker, der zusammen mit Lee Collins bei Xerox bereits an einem solchen neuen, einheitlichen Kodierungs-System für alle Sprachen arbeitete. Von da an arbeitete man gemeinsam an dem Projekt, dem Becker den Namen Unicode gab - für “unique, universal, and uniform charac­ter encoding”. Anfang 1988 waren die wichtigsten Vorarbeiten beendet: Vergleich der Zeichenverarbeitung bei fester und variabler Zeichenlänge, Untersuchung des gesam­ten zusätzlichen Speicherbedarfs bei Zwei-Byte-Text und die vorläufige Erfassung des Gesamtumfangs der weltweiten Schriftzeichen. Basierend auf diesen Untersu­chungen und der Erfahrungen mit anderen Zeichenkodierungen entwarfen Becker, Collins und Davis die Grundzüge der Unicode-Architektur.^[4]

In seiner Veröffentlichung ’Unicode 88’ von 1988 beschrieb Becker bereits viele der Konzepte, die Unicode haben sollte. ^{[5] [6]} Jedes Zeichen sollte mit der festen Länge von 16 Bit codiert werden, da man davon ausging, daß 65536 Codepunkte für alle ak­tuell bestehenden Schriftzeichen mehr als ausreichend sind. Es sollten Bereiche für die private Nutzung reserviert werden, in denen ggf. auch Zeichen historischer Texte codiert werden können. Unicode sollte also nur für die Schriftzeichen der Gegenwart einen Standard festlegen, wobei aber jedes Zeichen der bestehenden Standards ab­gebildet werden sollte. Jedes Zeichen sollte nur ein mal codiert sein. Die Zeichen der chinesischen, japanischen und koreanischen Systeme (CJK-Zeichen) sollten vor der Aufnahme in Unicode zuerst vereinheitlicht werden, da es sonst zu einer mehrfachen Kodierung gleicher oder ähnlicher Zeichen mit gleicher Bedeutung kommen würde (Han-Vereinheitlichung, siehe Abb. 1).

In den Jahren 1989 und 1990 schlossen sich weitere Firmen der Unicode-Arbeitsgruppe an, z.B. Sun Microsystems, Microsoft und NeXT (die neue Firma von Steve Jobs

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Han-Vereinheitlichung: Beispiel für Han-Zeichen in den CJK- Schrifsystemen: zh-CN=chinesische Kurzschrift, zh-TW chinesische Langschrift, ja=Japanisch, ko=Koreanisch ^[7]

nach seinem Weggang von Apple). Ende 1990 war der Großteil der bestehenden Zeichensätze auf Unicode abgebildet und der endgültige Entwurf fertig für die Be­gutachtung.^[8]

2.2.4 Das Unicode-Konsortium

Das Unicode-Konsortium (engl. Unicode Consortium) wurde im Januar 1991 als gemeinnützige Organisation gegründet, die sich über die Beiträge ihrer Mitglieder finanziert. Ziel sollte die Entwicklung, Erweiterung und Verbreitung des Unicode­Standards sein. Die erste Ausgabe des Unicode-Standards (Version 1.0.0) wurde im Oktober 1991 veröffentlicht, enthielt jedoch noch nicht die chinesischen Zeichen, da die Arbeit an der Han-Vereinheitlichung noch nicht abgeschlossen war.^[9] Erst die Version 1.0.1 vom Juni 1992 enthält auch die CJK-Schriftzeichen, wobei nun insgesamt 28.359 Codepunkte vergeben sind.

2.2.5 ISO-Standardisierung

Ende der 1980er Jahre arbeitet man auch bei der ISO, der Internationalen Orga­nisation für Standardisierung, an einem sogenannten Universal Character Set, kurz UCS. Der Standard war als ISO 10646 vorgesehen, in Anlehnung an ISO 646, der alten Norm für internationale 7-Bit-Zeichensätze. ISO 10646 sollte ein Code mit 4 Byte (32 Bit) pro Zeichen sein und sämtliche Zeichen aller Sprachen der Welt ko­dieren können. Angesichts des Umfangs des Projekts zogen sich die Arbeiten lange hin und es wurde kein Konsens gefunden. Als Kompromiss einigte man sich 1991 schließlich darauf, vorerst nur den inzwischen bestehenden Unicode-Standard mit seinen 16 Bit als Basic Multilingual Plane, also eine eine von vielen Ebenen, in UCS aufzunehmen. Weitere Ebenen sollten später standardisiert werden. Die Co­dierung wird von der ISO UCS-2 genannt, da für die Kodierung 2 Oktetts pro Zeichen verwendet werden. Mit UCS-2 können daher nur die Zeichen der BMP ko­diert werden. Im Gegensatz dazu soll UCS-4 mit 4-Byte den (noch zu definierenden) Gesamtumfang der Zeichen kodieren können.

Die Arbeitsgruppe, die ISO 10646 entwickelt, hat die Bezeichnung ISO/IEC/ JTC1/ SC2/ WG2 und kooperiert eng mit dem Unicode-Konsortium zusammen. Infolge dessen wurden auch in Unicode einige Änderungen vorgenommen und neue Zei­chen aufgenommen. Die neue Version 1.1 wurde 1993 veröffentlicht, zusammen mit dem identischen Standard ISO/IEC 10646-1:1993. Seit dieser Zeit werden alle neuen Versionen Unicode und ISO 10646 immer inhaltlich syncron gehalten.^[10]

2.2.6 Notation für Codepunkte

Für Codepunkte, also im Wesentlichen für die Unicode-Zeichen wurde eine spe­zielle Schreibweise festgelegt: U+xxxx, wobei x eine Hexadezimalziffer ist. Füh­rende Nullen sind auch aufzunehmen. Der lateinische Buchstabe ’A’ z.B. wird in Unicode-Notation als U+0041 geschrieben, das Eurozeichen ’€’ ist U+20AC. Hö­here Codepunkte (jenseite der BMP) sind mit 6 Hexadezimalziffern zu schreiben. Da der Unicode-Standard 17 Ebenen zu je 65536 Codepunkten umfasst, liegen alle Codepunkte in dem Bereich von U+0000 bis U+10FFFF.

2.3 Stetige Weiterentwicklung bis heute

2.3.1 Mehr Zeichen mit UCS-4/UTF32

Mit jeder neuen Unicode Version werden weitere Schriftsysteme aufgenommen. Mit Version 3.1 vom März 2001 wurde mit 94.205 erstmals die Grenze von 65536 (64kibi) Codepunkten überschritten, die zwei Byte pro Zeichen von UCS-2 reichen nun also für die Codierung nicht mehr aus. Da dies absehbar war, wurden schon rechtzeitig vorher mit Unicode Version 2.0 die technischen Voraussetzungen dafür geschaffen und neue Codierungen definiert. Eine mögliche Lösung ds Problems ist die Verwen­dung von 32-Bit-Integer zur Kodierung eines Zeichens, wie es bereits in ISO 10646 mit UCS-4 vorgesehen ist. Der Vorteil von UCS-4 ist, dass aufgrund der fixen Länge pro Zeichen die Algorithmen zur Zeichenverarbeitung einfacher sind als bei Codie­rung mit variabler Länge. Auf Seite der Programmierung muss im Wesentlichen nur der Datentyp geändert werden auf einen 32-Bit-Typ, nicht jedoch die Algorithmen. Die Nachteile von UCS-4 sind der erhöhte Speicherbedarf und die Inkompatibilität mit bestehenden UCS-2-Datensätzen. Aus diesen Gründen wird UCS-4 vor allem zur internen Repräsentation von Unicode-Zeichenketten verwendet. Das Unicode Con­sortium hat den Standard UCS-4 unverändert als UTF-32 übernommen, lediglich einzelne Termini unterscheiden sich bei ISO und Unicode Consortium.

2.3.2 Von UCS-2 zu UTF-16

Eine andere Möglichkeit mehr Zeichen zu kodieren wurde mit der UTF-16-Codierung entwickelt. Hierbei wurde UCS-2 erweitert, um mit einem Trick die Codepunkte über 65535 zu adressieren: In der BMP waren nicht alle Codepunkte vergeben wor­den, es gab größere freie Bereiche. Der Bereich von 0xD800 bis 0xDFFF, also 2048 Codepunkte, wurde jetzt verwendet, um Zeichen aus höheren Ebenen (z.B. der Sup­plementary Multilingual Plane, SMP) zu adressieren. Diese 2048 noch nicht verge­benen Codepunkte wurden unterteilt in eine obere und eine untere Hälfte zu je 1024 Codepunkten, gleichbedeutend einem Informationsgehalt von je 10 Bit. Bei Unicode werden die beiden Bereiche als ’low surrogate’ und ’high surrogate’ bezeichnet. Ein Codepunkt über U+FFFF wird nun mit einem Paar aus low und high surrogate adressiert. Somit sind 1024 * 1024, also 1.048.576 weitere Codepunkte möglich.

2.3.3 UTF-8

Die heute wichtigste Codierung für Unicode ist UTF-8. Dieses Verfahren mit varia­bler Codelänge (1 bis 4 Byte) ist ein Kompromiss aus Kompatibilität und Flexibili­tät. UTF-8 wurde bereits 1992 entworfen von Robert C. Pike (*1956) zusammen mit Ken Thompson (*1943), dem Mitentwickler von Unix und der Programmiersprache C. Tompsen und Pike wurden von IBM-Entwicklern der X/Open Group gebeten, eine neue Dateisystem-sichere Zeichenkodierung für UNIX zu begutachten. Pike und Thompson machten den Vorschlag eine bessere Codierung zu liefern und konnten schon nach wenigen Tagen den Entwurf und erste Implementierungen von UTF-8 präsentieren.^[11]

In UTF-8 werden die ASCII-Zeichen unverändert übernommen, so dass ein Zeichen genau einem Byte (<128) entspricht. Somit sind alle bestehenden ASCII-Texte be­reits gültiges UTF8. Alle anderen Unicode-Zeichen werden mit einer Bytefolge mit Werten >127 codiert, das höchstwertige Bit ist also auf jeden Fall 1. Das erste Byte eines Multibyte-Zeichens beginnt immer mit 11b. Wenn die ersten drei Bit 110b sind, so handelt es sich um ein 2 Byte-Zeichen. Das zweite Byte (ein sog. Trail- Byte) beginnt immer mit 10b, wodurch es eindeutig von dem 1. Byte unterschieden werden kann, gefolgt von 6 informationstragenden Bits. Ein 2-Byte Zeichen hat also in UTF-8 die Form 110xxxxx,10yyyyyy (binär). Mit den 11 informationstragenden Bits xxxxxyyyyyy können theoretisch 2048 verschiedene Kodepunkte abgebildet wer­ den. Tatsächlich dürfen jedoch nur die Zeichen U+0080..U+07FF als 2-Byte-Zeichen kodiert werden. Für die Zeichen U+0000 bis U+007F, also die ASCII-Zeichen, muss zwingen die 1-Byte-Form verwendet werden. Ganz allgemein gilt bei UTF-8 die Regel, daß ein Zeichen immer mit der kürzest möglichen Bytefolge kodiert werden muss.

Da auch 2048 Zeichen für Unicode unzureichend sind gibt es auch noch 3-Byte- Zeichen und 4-Byte-Zeichen. Bei einem 3-Byte-Zeichen beginnt das erste Byte mit 111b gefolgt von einer 0, es folgen diesmal 2 weite Bytes, die wieder mit 10b anfangen. Ein 3-Byte-Zeichen hat demnach die Form 1110xxxx,10yyyyyy,10zzzzzz, es gibt also 16 informationstragende Bits, mit denen sich die Kodepunkte U+0800..U+FFFF abbilden lassen. Analog sind auch 4-Byte Zeichen definiert, deren Wertebereich (21 Bit) aber von Unicode nicht mehr voll ausgeschöpft wird (U+10000..U+10FFFF). Im ursprünglichen Entwurf von Unicode waren auch 5- und 6-Byte-Zeichen vorge­sehen, was bis zu 31 Bit, also über 2 Mrd. Codepunkte bedeuten würde. Weil sich Unicode aber auf 1.112.064 Zeichen beschränkt, wurde im Jahr 2003 UTF-8 auf diesen auch mit UTF-16 kodierbaren Bereich (U+0000..U+10FFFF) beschränkt. ^[12] UTF-8 hat eine Reihe von Vorteilen, was sicher auch zu der weiten Verbreitung beigetragen hat:

- UTF-8 ist rückwärtskompatibel zu ASCII, da UTF-8 eine Obermenge von ASCII darstellt. Bestehende ASCII-Texte sind also bereits gültiges UTF-8.
- Andererseite sind Texte mit lateinischen Unicode-Buchstaben auch auf nicht- UTF-8-fähigen System noch gut lesbar. Lediglich die Nicht-ASCII-Zeichen ge­hen verloren bzw. werden falsch dargestellt.
- Software, die das NULL-Byte (U+0000) als Ende einer Zeichenkette interpre­tiert, kann genau so auch mit UTF-8 verfahren, denn das NULL-Byte wird nicht bei anderen Kodepunkten verwendet.
- Systeme, die für Transport und Speicherung von ASCII bzw. ISO 8859-1 ent­wickelt wurden, können i.d.R. auch UTF-8 verarbeiten, nur für die Ein- und Ausgabe muss die Kodierung berücksichtigt werden.
- Die Datenmenge erhöht sich gegenüber ISO 8859-1 nur um wenige Prozent bei Sprachen, die eine Variante des lateinischen Alphabets verwenden.
- UTF-8 benötigt kein BOM, da es nur auf Folgen von Bytes basiert, demzufolge unabhängig von ’Little Endian’ oder ’Big Endian’ ist. Es kann aber am Anfang des Textes das BOM-Zeichen angegeben werden, das dann mit den 3 Bytes 0xEF 0xBB 0xBF kodiert ist.
- Bei einem UFT-8-Bytestrom kann ein System (im Gegensatz zu UFT-16 und UTF-32) auch mittendrin anfangen einen String zu lesen, die einzelnen Zeichen können zuverlässig erkannt werden.
- Zeichenketten in UTF-8 können vorwärts und rückwärts mit den gängigen Algorithmen durchsucht werden.
Einige Nachteile von UTF-8 müssen jedoch auch bedacht werden:
- Der Speicherbedarf von Zeichenketten in UTF-8 ist aufgrund der variablen Zeichenlänge nicht linear zur Zeichenanzahl, sondern kann nur mit maximal 4 Byte/Zeichen * Zeichenanzahl nach oben abgeschätzt werden.
- Für die ostasiatischen Schriften ist bei UTF-8 der Speicherbedarf mit 3 bis 4 Byte/Zeichen immer höher als mit den älteren Codierungs-Systemen Big5, GB2312 oder Shift-JIS, welche alle Zeichen mit maximal 2 Byte codieren. In der Regel ist für CJK-Texte mit 2 Byte/Zeichen auch UTF-16 kürzer als UTF- 8.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Beispiel für verschiedene UTF-Kodierungen^[13]

Abbildung 2 zeigt exemplarisch für einige Zeichen, wie sie mit den verschiedenen UTF-Kodierungen im Speicher als Bytes, Words, oder DWords abgebildet werden.

2.3.4 Aufbau und Umfang von Unicode heute

Mit jeder neuen Unicode-Version werden neue Schriften und Symbole aufgenom­men sowie Unstimmigkeiten der Spezifikation beseitigt. Die aktuelle Version 7.0.0 umfasst 113.021 Zeichen, darunter mit ’Linear A’ sogar die erste Unicode-Schrift, die noch nicht entziffert ist. Es gibt also im gesamten Kodierungsraum noch ausrei­chend Reserven für die Zukunft. Die Spezifikation von Unicode teilt den verfügbaren Kodierungsraum in 17 Ebenen (engl. planes) zu je 65536 (256*256) Codepunkten auf. Ein Codepunkt muss dabei nicht unbedingt einem Zeichen entsprechen, es gibt z.B. auch Steuerzeichen, Modifikationszeichen oder die Surrogates. Die erste Ebene (bzw. Ebene 0) ist die BMP, die ’Basic Multilingual Plane’, also die mehrsprachi­ge Basis-Ebene. Sie enthält die wichtigsten Zeichen der heute verwendeten Spra­chen. Das sind auch gleichzeitig alle Zeichen, die mit UCS-2 codiert werden können (U+0000..U+FFFF). Für die allermeisten Fälle im alltäglichen Gebrauch sind die Zeichen der BMP ausreichend. Die nächste Ebene, die ’Supplementary Multilingual Plane’ (SMP), also die ergänzende mehrsprachige Ebene, enthält u.a. historische und antike Schriftsysteme wie ’Linear B’ oder ägyptische Hieroglyphen, Emojis, Notenschrift und mathematische alphanumerische Symbole.

Die dritte Ebene, die ’Supplementary Ideographic Plane’ (SIP), kodiert weitere CJK- Zeichen, die noch nicht in früheren Versionen aufgenommen wurden. Die nachfol­gende Plane 3 ist für weitere CJK-Schriftzeichen reserviert. Die Ebenen von Plane 4 bis Plane 13 sind momentan im Unicode-Standard nicht vergeben.

Plane 14, Supplementary Special-purpose Plane (SSP, die Ergänzende Ebene für spezielle Verwendungen) enthält Kontrollzeichen zur Sprachmarkierung, von deren Verwendung heute jedoch abgeraten wird. ^[14]

Die beiden letzten Ebenen, Plane 15 und Plane 16 sind für den privaten Gebrauch reserviert (Private Use Area, PUA) - eine Gruppe von Anwendern kann für diesen Bereich einen eigene Standard definieren und z.B. in einem Font kodieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Unicode-Ebenen^[15]

Abbildung 3 zeigt eine schematische Darstellung der Unicode-Ebenen, in der ersten Ebene, der BMP sind die unterschiedlichen Codeblöcke farblich hervorgehoben.

Für die physische Zeichenkodierung von Unicode-Text dominiert heute das Verfah­ren UTF-8, es hat sich als Quasi-Standard für die Speicherung und Übertragung von Texten etabliert. Im Internet steigt der Anteil von UTF-8-kodierten Webseiten kontinuierlich an und beträgt Anfang 2015 schon über 82%, die älteren asiatischen Systeme GB2312 und Shift-JIS haben mit ca. 1% der Webseiten nur noch geringe Bedeutung. ^[16]

UTF-16 wird heute vor allem zur internen Repräsentation von Zeichenketten ver­wendet, z.B. bei JAVA-Umgebungen. In Dateisystemen wie z.B. NTFS oder HFS+ findet UTF-16 Verwendung für die Speicherung der Datei- und Verzeichnisnamen.

3 Probleme und Herausforderungen

3.1 Technische Schwierigkeiten

3.1.1 Limitierungen von Schriftarten

Ein ganz grundsätzliches Problem bei der Verwendung von Unicode ist, dass die Dateiformate für Schriftarten (Fonts), wie z.B. TrueType oder OpenType nur 216 verschiedene Zeichen unterstützen. TrueType wurde etwa zur selben Zeit wie die ersten Versionen von Unicode entwickelt und daher sah man nur die Notwendig­keit für maximal 65.536 Zeichen. Die meisten Schriftarten enthalten jedoch ohnehin nur einen kleinen Teil der BMP-Zeichen, meist einige Tausend. Das Problem lässt sich durch Verwendung verschiedener Schriftarten innerhalb eines Dokumentes lö­sen. Bei PDF-Dokumenten können die verwendeten Schriftarten sogar in die Datei eingebettet werden.

3.1.2 Rendern von Zeichen

Schriftzeichen müssen nicht nur definiert werden, sondern auch von einem Ausga­besystem gerendert und dargestellt werden. Dies ist eine nicht unerhebliche Her­ausforderung für die Entwickler, müssen doch Details und Eigenheiten von vielen hunderten Schriftsystemen berücksichtigt werden. Das geht von der Darstellung von Ligaturen über wechselnde Schriftrichtung, veränderte Darstellung von Zeichen am Ende eines Wortes bis zum korrekten Shaping-Support durch eine robuste Shaping- Engine.

3.1.3 Email-Adressen

Viele Dienste im Internet verwenden heute zur Authentifizierung eine Kombination aus Email-Adresse und Passwort. Mit der zunehmenden Verbreitung von Unicode muss dies auch hier berücksichtigt werden, um nicht bestimmte Benutzer auszu- schliessen. Mit Einführung der internationalisierten Domainnamen (IDN) kann der Domänen-Teil (domain part) der Email-Adresse Unicode-Zeichen enthalten, der lo­kale Teil (local part) vor dem ist ohnehin frei wählbar und kann daher auch Unicode enthalten. Dies alles muß bei der Implementierung einer Authentifizierung mittels Email berücksichtigt werden, dazu gehört z.B. die Validierung der Einga­bedaten (z.B. durch reguläre Ausdrücke) oder die Länge der zulässigen Datenfelder bei Eingabe und Speicherung in der Datenbank.

3.1.4 Aufwärtskompatibilität von Software

Der Unicode-Standard wird ständig weiterentwickelt. Mit jeder neuen Version steigt der Umfang der definierten Zeichen. Software mit Unicode-Support muss daher so robust sein, daß auch Texte mit Zeichen aus zukünftigen Unicode-Versionen nicht zu einem unkontrollierten Verhalten führen. Der maximale Gesamtumfang von Unicode ist bereits auf 1.112.064 Zeichen festgelegt, was den technischen Rahmen für jeden künftigen Unicode-Standard vorgibt. Unbekannte Zeichen müssen von einem IT- System ggf. gesondert dargestellt werden, dürfen aber nicht aus den Daten entfernt werden.

3.1.5 Schwierigkeiten mit BOM

Das Byte Order Mark (U+FEFF), kurz BOM, wurde geschaffen um auf einem Ziel­system die Endianess eines Textes erkennen zu können. Das BOM ist definiert als ein Leerzeichen mit der Länge Null. In diesem Zusammenhang wurde das Zeichen U+FFFE als ein ungültiges Zeichen definiert. So erkennt das Zielsystem, ob die Reihenfolge der Bytes in einem 16-Bit-Wort oder einem 32-Bit-DWort vertauscht werden muss. Eine Unicode-Zeichenkette kann mit einem BOM beginnen, vor allem UTF-16-Daten, muss aber nicht. Auch bei UTF-8 kann am Anfang ein BOM stehen, was in einer charakteristischen Folge der 3 Bytes EF BB BF resultiert.

Bei Zeichenketten-Operationen, wie Ausschneiden von Teilstrings oder Zusammen­setzen zu neuen Zeichenketten muss das BOM berücksichtigt werden. Es sollte durch solche Operationen nicht innerhalb der Zeichenkette stehen, denn dann gilt es nicht mehr als BOM, sondern Leerzeichen der Länge Null. Zeichenkettenvergleiche funk­tionieren dann möglicherweise nicht mehr, oder die Länge der Zeichenketten ändert sich unerwartet.

Programme die nicht mit einem BOM umgehen können funktionieren nicht mehr korrekt, wenn sie solch eine Eingabe erhalten. Unter Linux und Unix z.B. gibt es für ausführbahre Script-Dateien die sog. Shebang-Mechanismus, wobei am Dateianfang die Zeichenfolge ’#!’ erwartet wird, gefolgt von dem Pfad zu dem zu verwendeten Interpreter. Wird beim Bearbeiten und Speichern der Script-Datei ein Format mit BOM gewählt kommt es beim Aufruf des Scriptes zu Problemen, da der Shebang- Mechanismus nicht mehr greift.

3.1.6 Normalisierung

Viele Zeichen können in Unicode auf verschiedene Weise kodiert werden: als einzel­nes Zeichen oder als eine Zeichenkombination. Die deutschen Umlaute zum Beispiel können mit den Codepunkten, die ihrer früheren Position in ISO 8859-1 entspre­chen, kodiert werden oder als normale Vokale ’a’, ’o’ und ’u’ gefolgt von einem kombinierenden diakritischen Zeichen ’ (hier Trema, U+0308). Weitere Beispiele sind hoch-/tiefgestellte Zeichen, numerische Brüche, veränderte Schriftart (z.B. bei Zeichen für mathematische Mengen) oder Varianten chinesischer Zeichen.

Daher wurden verschiedene Arten von Normalisierung festgelegt, also Verfahren, um einen Text in eine bestimmte Normalform zu überführen. Nur so können Unicode- Texte verglichen werden, z.B. für den Anwendungsfall der Zeichenkettensuche. Am weitesten verbreitet ist die kanonischen Komposition (Normalization Form Canoni­cal Composition, NFC). ^[17]

3.2 Sicherheitsaspekte

Seit dem Jahr 2010 sind die sog. Internationalisierte Domainnamen (IDN) möglich. Dies sind Domainnamen, welche nicht-ASCII-Zeichen des Unicode-Zeichensatzes enthalten.^[18] Auf der einen Seite führt das zunehmende Aufkommen der IDN zu einer Fragmentierung des Internet, zur Ausbildung lokaler Cluster. Nur ein Teil der Weltbevölkerung ist in der Lage, eine Internet-Adresse mit arabischer oder chinesi­scher Schrift einzugeben. Die Beschränkung auf ASCII-Zeichen war sozusagen ein kleinster gemeinsamer Nenner, ASCII kann auf jeder Tastatur der Welt problem­los eingegeben. Die Eingabe von IDN ist bestenfalls mittels ’kopieren und einfügen’ möglich.

Das größere Problem der IDN ist der Sicherheitsaspekt. Bei der Vielzahl von Zeichen in Unicode gibt es viele Zeichen die sehr ähnlich, oder kaum zu unterscheiden sind, wie bei ASCII bereits die Ziffer ’0’ und der große Buchstabe ’O’. Internet-Nutzer könnten so von einem Angreifer auf gefälschte Internetseiten gelockt werden, oh­ne das anhand der Internet-Adresse erkennen zu können. Hier gibt der Benutzer dann z.B. seine geheimen Daten wie PIN oder TANs ein, die vom Angreifer dann mißbraucht werden.

Ein Anwenderprogramm, z.B. ein Browser, sollte daher mittels einer Heuristik er­kennen können, ob eine Internet-Adresse Zeichen aus verschiedenen Unicodeblöcken verwendet und den Benutzer in einem solchen Fall warnen. ^[19]

3.3 Weitergehende Nutzung von Symbolen

In Unicode war es von Anfang an vorgesehen, auch verschiedene, häufig gebrauchte Symbole zu kodieren. In letzter Zeit wurden aber immer mehr Icons, Smilys, Emo- jis etc. aufgenommen, meist auch farbig - die konkrete Darstellung ist Aufgabe des Renderers und der Schriftart. Hier besteht die Gefahr, daß viele Codepunkte ’ver­braucht’ werden für sehr spezielle Zeichen, welche eigentlich besser im PUA-Bereich aufgehoben wären, wo Zeichen für den eigenen Gebrauch definiert werden können. So finden sich in der Unicode-Datenbank inzwischen 11 Emojis für ’Blume’, 12 ver­schiedene Varianten von ’Quadrat’ und 10 Versionen von ’Eisenbahn’ um nur ein paar Beispiele zu nennen. ^[20] Der Nutzen dieser vielen, oft sehr ähnlichen Symbole ist umstritten bis fragwürdig.

3.4 Akzeptanz in Ostasien

Unicode hatte einen schweren Start in Japan und anderen ostasiatischen Ländern und noch immer gibt es große Vorbehalte. Einerseits gab es in diesen Regionen be­reits funktionierende Schriftsysteme, die ASCII und ostasiatische Zeichen abdeckten, was die Motivation zu umfangreichen Änderungen natürlich reduzierte. Andererseits hatte man die Befürchtung, daß nun in einer Kommission auf einem anderen Kon­tinent Entscheidungen über die eigene Schriftsprache gefällt würden, also über den Kern der kulturellen Identität. Teilweise wurde nicht verstanden, daß in Unicode zwischen dem Zeichen und seiner Darstellung getrennt wird. So entstand das Miss­verständnis, dass mit der Han-Vereinheitlichung die Zeichen der verschiedenen Län­der ’in einen Topf geworfen’ wurden. Es hängt jedoch bei Unicode von der gewählten Schriftart ab, ob ein Zeichen im japanischen oder im chinesischen Stil ausgegeben wird (sofern es sich um vereinheitlichte Zeichen handelt).^[21]

3.5 Umfang der CJK-Zeichen

Der Umfang der CJK-Zeichen ist mit der Zeit in anfangs nicht erwartete Höhe gestiegen. Dies machte dann auch die Einführung weiterer Unicode-Ebenen, wie der SMP und der SIP notwendig. Die verschiedenen ostasiatischen Länder reichen immer wieder neue Zeichen für die Aufnahme in den Unicode-Standard ein. Vor allem aus Taiwan kommen Tausende von Zeichen, die nur als Namen einzelner oder weniger Personen existieren und die nur minimale Variationen anderer bestehender Schriftzeichen sind. Es stellt sich die Frage, ob hierfür nicht Variantenselektoren oder der PUA-Bereich die bessere Lösung sind. Bei anderen eingereichten Zeichen

kann die Herkunft und tatsächliche Nutzung nicht sauber nachgewiesen werden, aufgenommen wurden sie aber bisher dennoch. ^[22]

4 Fazit und Ausblick

Unicode ist ein wichtiger Baustein für die konsequente Weiterentwicklung der In­formationstechnik in einer globalisierten Welt. Von den Anfängen der Telegrafie bis zum heutigen Stand war es ein langer Weg. Heute ist Unicode die ’lingua Franca’ des Informationsaustausches. Im Internet hat sich Unicode weitestgehend durchgesetzt und ist bei den meisten modernen Datenformaten wie z.B. XML die empfohlene Zeichenkodierung. In Zukunft ist damit zu rechnen, daß der Anteil an Program­men mit Unicode-Unterstützung weiter steigen wird, ebenso wie der Umfang der mit Unicode kodierten Daten. In künftigen Versionen des Standards werden weitere Schriftsysteme aufgenommen werden, jedoch eher gering verbreitete Schriften von Minderheiten, historische Schriften oder weitere seltene chinesische Han-Zeichen. Software-Entwickler müssen sich aber auf die Besonderheiten von Unicode einstellen, was die Arbeit insgesamt aufwändiger und komplexer macht, wobei aber geeignete Software-Bibliotheken unterstützen können.

Literatur

[Becker, J.D. (1988)] Unicode 88 , Xerox Corporation, Palo Alto, CA, 1988

Internetquellen:

[Andrew West (2007)] A Brief History of CJK-C URL: http://babelstone. blogspot.de/2007/06/brief-history-of-cjk-c.html, Abruf am 31.1.2015

[bayern-online.com (2015)] Baudot-Mehrfachtelegraf URL: http://www. bayern-online.com/v2261/artikel.cfm/203/Baudot-Mehrfachtelegraf. html, Abruf am 29.1.2015

[IETF (1992)] RFC 1345: Character Mnemonics and Character Sets URL: https: //tools.ietf.org/html/rfc1345, Abruf am 29.1.2015

[IETF (2003)] RFC 3629: UTF-8, a transformation format of ISO 10646 URL: http: //tools.ietf.org/html/rfc3629, Abruf am 30.1.2015

[IETF (2010)] RFC 5891: Internationalized Domain Names in Applications (IDNA): Protocol URL: https://tools.ietf.org/html/rfc5891, Abruf am 31.1.2015

[ITU (1988)] INTERNATIONAL TELEGRAPH ALPHABET No. 2 URL: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-S. 1-198811-S!!PDF-E&type=items, Abruf am 29.1.2015

[Pike, R.C. (2003)] UTF-8 history URL: http://www.cl.cam.ac.uk/~mgk25/ucs/ utf-8-history.txt, Abruf am 29.1.2015

[Unicode Consortium (2009)] Early Years of Unicode URL: http://unicode.org/ history/earlyyears.html, Abruf am 29.1.2015

[Unicode Consortium (2014a)] The Unicode Standard Version 7.0 - Core Specifica­tion, Chapter 2: General Structure URL: http://www.unicode.org/versions/ Unicode7.0.0/ch02.pdf, Abruf am 30.1.2015

[Unicode Consortium (2014b)] The Unicode Standard Version 7.0 - Tags URL: http://www.unicode.org/charts/PDF/UE0000.pdf, Abruf am 31.1.2015

[Unicode Consortium (2014c)] The Unicode Standard Version 7.0- Core Specifica­tion, Appendix C: Relationship to ISO/IEC 10646 URL: http://www.unicode. org/versions/Unicode7.0.0/appC.pdf, Abruf am 29.1.2015

[Unicode Consortium (2014e)] The Unicode Standard Version 7.0 - Core Specifi­cation, Appendix E: Han Unification History URL: http://www.unicode.org/ versions/Unicode7.0.0/appE.pdf, Abruf am 29.1.2015

[Unicode Consortium (2014f)] Unicode Character Encoding Stability Poli­cy URL: http://www.unicode.Org/policies/stability_policy.html# Normalization, Abruf am 31.1.2015

[Unicode Consortium (2014g)] Unicode Technical Standard #39 - UNICODE SE­CURITY MECHANISMS URL: http://www.unicode.org/reports/tr39/, Ab­ruf am 31.1.2015

[Unicode Consortium (2014h)] Draft Emoji Annotations URL: http: //www.unicode.org/Public/emoji/1.0/emoji-annotations.html, Abruf am 31.1.2015

[Unicode Consortium (2014i)] Frequently Asked Questions - Chinese and Japanese URL: http://unicode.org/faq/han_cjk.html, Abruf am 31.1.2015

[W3C (2011)] Zeichencodierungen: grundlegende Konzepte URL: http://www.w3. org/International/articles/definitions-characters/, Abruf am 31.1.2015

[W3Techs (2015)] Historical yearly trends in the usage of character encodings for websites URL: http://w3techs.com/technologies/history_overview/ character_encoding/ms/y, Abruf am 31.1.2015

[Wikimedia Commons (2014)] Comparison of the characters ^lj, ^ (tradi­ tional variants) for Chinese (Mainland), Chinese (Taiwan), Japanese, Korean. URL: https://commons.wikimedia.org/wiki/File:Vergleich_zh-Hant-CN_ zh-Hant-TW_ja-Hani_ko-Hani.svg, Abruf am 31.1.2015

[...]

---

^[1] vgl. [bayern-online.com (2015)]

^[2] vgl. [ITU (1988)]

^[3] vgl. [IETF (1992)]

^[4] vgl. [Unicode Consortium (2009)]

^[5] vgl. [Unicode Consortium (2009)]

^[6] vgl. [Becker, J.D. (1988)]

^[7] Quelle: [Wikimedia Commons (2014)] https://commons.wikimedia.org/wiki/File: Vergleich_zh-Hant-CN_zh-Hant-TW_ja-Hani_ko-Hani.svg

^[8] vgl. [Unicode Consortium (2009)]

^[9] vgl. [Unicode Consortium (2014e)]

^[10] vgl. [Unicode Consortium (2014c)]

^[11] vgl. [Pike, R.C. (2003)]

^[12] vgl. [IETF (2003)]

^[13] Quelle: [Unicode Consortium (2014a)] S.41 Fig.2-12 http://www.unicode.org/versions/ Unicode7.0.0/ch02.pdf

^[14] vgl. [Unicode Consortium (2014b)]

^[15] Quelle: [W3C (2011)] http://www.w3.org/International/articles/ definitions-characters/

^[16] vgl. [W3Techs (2015)]

^[17] vgl. [Unicode Consortium (2014f)]

^[18] vgl. [IETF (2010)]

^[19] vgl. [Unicode Consortium (2014g)]

^[20] vgl. [Unicode Consortium (2014h)]

^[21] vgl. [Unicode Consortium (2014i)]

^[22] vgl. [Andrew West (2007)]