XML-Know How

Unicode (ISO 10646)

Die Grenzen des ISO-Entity-Konzeptes, die mit der zunehmenden Globalisierung immer mehr als Einschränkung empfunden werden, haben zur Entwicklung einer alternativen Lösung für die neutrale Zeichenkodierung geführt. Diese Lösung heißt Unicode und ist mittlerweile auch als internationaler Standard ISO 10646 definiert.

Wie oben gezeigt, führt die historisch bedingte Konvention, dass Computer Schriftzeichen intern als ein einziges Byte von 8 Bit repräsentieren, zu einer Beschränkung des Wertebereichs für Zeichencodes auf die Spanne 0–255. Will man nicht mit Entities arbeiten, gibt es nur eine Möglichkeit, dieses Problem zu lösen: Der Wertebereich muss vergrößert werden.

Hierzu wurden ursprünglich zwei konkurrierende Entwürfe erarbeitet, von der ISO und dem Unicode Consortium. Letzteres repräsentiert im Wesentlichen große amerikanische Softwarefirmen. 1993 wurden die Zeichenbelegungen der beiden Entwürfe ISO 10646-1 und UnicodeTM zu dem harmonisiert, was wir heute unter Unicode verstehen. Man einigte sich auf eine Zwei-Oktet-Folge, d. h. pro Zeichen werden 2 Byte Speicherplatz verwendet. Entsprechend ist Unicode ein 16-Bit-Code, mit dem man 216 = 65 536 Zeichen repräsentieren kann. Erstes Ziel ist, die Schriftzeichen aller Staatssprachen eindeutig und einheitlich zu kodieren.

Nicht alle dieser 65 536 Zeichenadressen werden dabei standardisiert belegt: Eine private use area (nutzerdefinierter Bereich) erlaubt es, ca. 2 000 Adressen mit nutzerspezifischen Zeichen zu belegen.

Über sogenannte surrogate pairs, d. h. die Kombination von zwei 16-Bit-Codes, kann man weitere 1 408 576 Zeichen ansprechen. Damit hofft man, alle Schriftzeichen, die es gibt und jemals gegeben hat, erfassen zu können. Darüberhinaus werden auch technische Symbole, musikalische Zeichen, Lautschrift etc. abgebildet. Noch sind aber bei weitem nicht alle Zeichenadressen belegt.

Interessant für die Verlagsbranche ist auch der Ansatz der »Level-3-Implementierung«, der fliegende Akzente (combining diacritics) vorsieht und es erlaubt, Diakritika mit (fast) beliebigen Grundzeichen zu kombinieren. Diese für viele wissenschaftliche Publikationen essentielle Eigenschaft wird allerdings von professioneller Software bisher nicht unterstützt (das Werksatzprogramm TUSTEP hat in dieser Hinsicht fast eine Alleinstellung auf dem Markt).

Der Unicode-Standard ist permanenten Änderungen unterworfen. Laufend werden Vorschläge für die Aufnahme neuer Zeichen gemacht und technische Erweiterungen realisiert. Allerdings werden Zeichen nur zugefügt, Neu-Zuordnungen werden strikt vermieden, wodurch eine Abwärtskompatibilität der Versionen sichergestellt ist. Inzwischen ist Unicode bei der Version 4 angelangt, vom Äquivalent ISO 10646 existieren nicht weniger als acht Versionen. Nicht alle diese Standards sind von den Softwareherstellern bereits umgesetzt.

Zudem gibt es für die konkrete softwareseitige Ablage der Unicode-Zeichen verschiedene Wege. Es gibt also nicht nur verschiedene Unicode-Versionen, sondern auch verschiedene Speicherformate (encodings), wie z. B. die von XML standardmäßig akzeptierten Formate UTF-8 und UCS-2. Es kann daher vorkommen, dass an sich Unicode-fähige Software mit selteneren Unicode-Formaten Probleme hat.

Anders als bei den ISO-Entities, die mit dem 7-Bit-Code den schon vorhandenen kleinsten gemeinsamen Nenner aller Computersysteme verwenden, muss die Unicode-Funktionalität erst in die Software implementiert werden. Das trifft auf Betriebssysteme ebenso zu wie auf Anwendungssoftware (Webbrowser, Textverarbeitungsprogramme oder Satzprogramme). Nur die neuesten Versionen können mit Unicode umgehen.

Bei Unicode wird Abwärtskompatibilität daher solange ein Problem sein, bis alle relevanten Anwender zuverlässig Unicode-fähige Software verwenden. Da z. B. die Windows-Betriebssysteme erst ab der Version Windows 2000 Unicode wirklich implementiert haben (frühere Versionen benötigen ein Update und weisen Funktionsbeschränkungen auf), wird dieser Zustand noch einige Jahre auf sich warten lassen. Erst wenn die Zahl der Nutzer, die mit früheren Versionen arbeiten, vernachlässigt werden kann, wird sich Unicode in der Breite durchsetzen, wie es heute beim ASCII-Code der Fall ist.

Geduld mit Unicode ist auch aus anderen Gründen angeraten. So lässt die Zuverlässigkeit bei der Umsetzung dieses Standards oft noch zu wünschen übrig. Momentan kann man sich noch nicht bei allen Programmen darauf verlassen, dass die Kodierung beim Abspeichern sicher erhalten bleibt – auch wenn der Hersteller das Programm als Unicode-fähig bezeichnet.

Ein weiteres Problem ist, dass sich Unicode-Dateien nur schwer überprüfen lassen. Das liegt an dem Unicode-Grundgedanken, nach dem ein Zeichen nicht durch sein Aussehen definiert ist (Zeichen im Sinne von grafischer Gestalt: engl. glyph), sondern durch seine Bedeutung (Buchstabe oder Symbol mit einer bestimmten Bedeutung in einem bestimmten Kontext: engl. character). Da ein und dasselbe Zeichen verschiedene Bedeutungen haben kann, existieren in Unicode oft verschiedene Adressen für ein Zeichen.

Das Zeichen »°« z. B. gibt es in Unicode einmal als degree sign (Gradzeichen) und als Zeichen ring above (hochgestellter Ring) in unterschiedlichen Kodierungen (00B0 und 02DA). Die bekannte Textverarbeitung Microsoft Word stellt nicht nur diese beiden Kodierungen identisch dar (was völlig korrekt ist und mitunter auch vom Zeichensatz abhängt), sondern verwendet darüber hinaus dasselbe Zeichen am Bildschirm für geschützte Leerzeichen.

Der einzige Weg, die Korrektheit des Codes zu kontrollieren, führt daher über die Darstellung des Hexadezimalwertes des Zeichens und die Überprüfung, ob der Code auch wirklich der richtige ist. Das ist freilich sehr aufwändig.

Die Kodierung der ISO-Entities kann dagegen mit jedem Texteditor sichtbar gemacht werden. Zudem sind die Entity-Kürzel an die englischen Bezeichnungen für das Zeichen angelehnt, so dass man sie sich relativ leicht merken kann (z. B.   für no-breaking space; geschütztes Leerzeichen). Unicode-Adressen wird sich kaum jemand merken können.

Ein Lösungsansatz für dieses Problem, den manche Programme bereits verfolgen, ist die Integration der sprachlichen Zeichenbeschreibung in das Programm, so dass für jedes markierte Zeichen diese Beschreibung angezeigt werden kann. Das Problem des unterschiedlich kodierbaren »°« ist gelöst, wenn je nach der Kodierung in der Statuszeile des Programms »degree sign« oder »ring above« angezeigt wird. Da diese sprachliche Beschreibung Teil des Unicode-Standards ist, ist die Implementierung solcher Funktionen an sich unproblematisch.

Eine weitere Schwierigkeit stellen derzeit noch die Zeichensätze dar, die für Ausgabemedien wie Bildschirm oder Drucker vorhanden sein müssen, um die Unicode-kodierten Zeichen auch tatsächlich alle darzustellen. Zeichensätze, die sich Unicode-Zeichensätze nennen, erfüllen zwar den Anspruch, ihre Zeichen nach Unicode zu adressieren. Den Anspruch, alle Zeichen einer bestimmten Unicode-Version zu beinhalten, hat freilich keiner dieser Fonts. Ein einziger Font mit allen Unicode-Zeichen hätte einen Speicherbedarf von knapp 100 MB! Daher ist es wie bei den Entities nötig, bei jedem Produkt zu prüfen, ob die verwendeten Zeichen mit dem verfügbaren Zeichensatz dargestellt werden können.

Gerade für die typographisch anspruchsvolle Gestaltung ist die Zahl der verfügbaren Unicode-Zeichensätze derzeit noch gering. Das ist freilich kein Nachteil des Standards an sich, sondern nur aktueller Stand der Umsetzung. Bevor Unicode auch in dieser Hinsicht alle professionellen Erwartungen erfüllt, müssen die Font-Hersteller noch deutlich nachbessern.

Unicode ist also nicht gleich Unicode – zumindest noch nicht in dem Maße, dass jede Unicode-Datei in jeder Unicode-fähigen Software richtig dargestellt wird. Problematisch ist hier vor allem, dass die Softwarehersteller es einem schwer machen zu erfahren, welche Unicode-Implementation sich hinter dem Label »Unicode-fähig« versteckt. Dazu kommt das Problem der fehlenden kompletten Unicode-Schriften. Will man also in Unicode arbeiten, muss derzeit noch für jedes Projekt klargestellt werden, welche Version gemeint ist, welches Speicherformat vorliegt und welche Zeichen benötigt werden.

Solange man sich als Minimallösung auf die Version Unicode 2.0 (= ISO 10646-1) beschränkt, als Speicherformat das weit verbreitete UTF-8 verwendet und nur europäische Schriften benötigt, werden kaum Probleme auftauchen. Allerdings gibt es dann nur wenige Vorteile gegenüber der Verwendung von ISO-Entities. Der wesentlichste Vorteil besteht darin, dass die Unicode-Datei auch von Texteditoren und -verarbeitungen korrekt dargestellt wird, während ISO-Entities in solchen Programmen nicht als Sonderzeichen, sondern nur in der Form »&entityname;« dargestellt werden können.

In konzeptioneller Hinsicht erfüllt Unicode die Bedingungen für medienneutrale Datenhaltung zwar weitaus besser und eleganter als alle anderen Kodierungsschemata. Konkrete Umsetzung und Abwärtskompatibilität lassen aber momentan noch zu wünschen übrig. Es ist daher nicht verwunderlich, wenn viele professionelle Anwender derzeit noch auf die bewährten ISO-Entities zurückgreifen, die fast alle Probleme der medienneutralen Zeichenverwaltung für Anwender in der westlichen Welt in zuverlässiger Weise lösen.

Dennoch ist Unicode der erste Standard für die Zeichenkodierung, der auch nichteuropäische Schriftsysteme berücksichtigt. Diese Universalität hat zu einer enormen Verbreitung von Unicode beigetragen. Kaum ein Software-Hersteller kann es sich leisten, diesen Standard zu ignorieren.

Es steht daher zu hoffen, dass sich die momentanen Probleme in der Unicode-Umsetzung als Kinderkrankheiten erweisen. Wenn dem so ist, wird Unicode in wenigen Jahren die ISO-Entities tatsächlich überflüssig gemacht haben.

Im Kompendium werden wir uns auch weiterhin mit dem zentralen Thema der Zeichenkodierung befassen. In den nächsten Ergänzungslieferungen werden Sie praxisorientierte Beiträge zur Verwendung von ISO-Entities und Unicode finden. Auch wollen wir Ihnen Übersichten aller ISO-Entities und der dazugehörigen Unicode-Adressen als Referenzlisten zur Verfügung stellen.