Standards

Computer speichern keine Buchstaben; sie speichern Zahlen. Eine Zeichenkodierung ist schlicht die Vereinbarung darüber, welche Zahl welches Zeichen bedeutet, sodass das Byte, das ein Programm speichert, von einem anderen als derselbe Buchstabe wieder gelesen wird. Wenn diese Vereinbarung hält, funktioniert Text einfach; wenn sie zerbricht, ist das Ergebnis jenes vertraute Kauderwelsch-Durcheinander, das die Informatik seit ihren frühesten Tagen plagt.

Wenn ein Dokument mit einer Kodierung geschrieben und mit einer anderen gelesen wird, erhalten Sie Mojibake – die verwürfelten Akzente, geheimnisvollen Kästchen und Fragezeichen, die jeder schon einmal gesehen hat. Aus einem „café“ wird „café“, ein typografisches Anführungszeichen verwandelt sich in eine Reihe von Symbolen, und eine ganze Seite in einer anderen Sprache kann sich in Kauderwelsch auflösen. Die zugrunde liegende Ursache ist immer dieselbe: Schreiber und Leser waren sich uneinig darüber, welche Zahl welches Zeichen darstellt.

Von ASCII zu einem Flickwerk von Kodierungen

Die Wurzeln des Problems liegen in den begrenzten Kodierungen der frühen Informatik. ASCII, eines der Gründungsschemata, deckte nur Englisch ab – die lateinischen Grundbuchstaben, Ziffern und eine Handvoll Symbole –, denn es nutzte einen kleinen Zahlenbereich. Das genügte für die frühe amerikanische Informatik, ließ aber keinen Raum für akzentuierte Buchstaben, geschweige denn für die Schriften der meisten Sprachen der Welt.

Was folgte, war ein Flickwerk unvereinbarer 8-Bit-Kodierungen, von denen jede einen anderen Satz zusätzlicher Zeichen in denselben begrenzten Raum quetschte. Eine Kodierung deckte die westeuropäischen Akzente ab, eine andere Kyrillisch, eine andere Griechisch und so fort, wobei dieselbe Zahl in jeder verschiedene Zeichen bedeutete. Ein Dokument ergab nur Sinn, wenn man genau wusste, welche dieser Kodierungen es verwendete, und sich zu irren erzeugte Mojibake – eine fragile, fehleranfällige Lage.

Wie Unicode das Grundproblem löste

Unicode löste das zugrunde liegende Problem an seiner Wurzel. Statt einen kleinen Zahlenraum aufzuteilen, weist es jedem Zeichen jeder Schrift – Latein, Kyrillisch, Arabisch, Chinesisch, Emoji und vielem mehr – seinen eigenen, einzigartigen Codepunkt zu. Unicode ist der universelle Katalog: eine einzige, vereinbarte Identität für jedes Zeichen, das die Menschheit schreibt, und beseitigt die Mehrdeutigkeit, die das alte Flickwerk der Kodierungen zum Scheitern verurteilte.

Es lohnt sich, zwei leicht zu verwechselnde Ideen zu trennen, denn die Unterscheidung ist der Schlüssel zum Verständnis des Themas. Unicode definiert die Codepunkte – die abstrakten Zahlen, die Zeichen zugewiesen sind –, aber es sagt für sich genommen nicht, wie diese Zahlen in Bytes auf der Festplatte oder im Netzwerk verwandelt werden. Diese zweite Aufgabe, Codepunkte auf tatsächliche Bytes abzubilden, ist die Rolle einer Kodierung, und UTF-8 ist die Kodierung, die das tut.

Warum UTF-8 das Web eroberte

UTF-8 setzte sich aus mehreren konkreten Gründen gegen die Alternativen durch. Es ist abwärtskompatibel zu ASCII, sodass jeder einfache englische Text bereits ohne jede Änderung gültiges UTF-8 ist. Es ist platzsparend für gängigen Text und verwendet ein einzelnes Byte für die häufigsten Zeichen und nur dann mehr, wenn es nötig ist. Und es kann jedes Unicode-Zeichen darstellen, sodass eine einzige Kodierung endlich für alle Sprachen zugleich genügt.

Diese Eigenschaften zusammen machten UTF-8 zur überwältigenden Standardeinstellung des modernen Webs, und der HTML-Standard empfiehlt, es explizit zu deklarieren. Die Konvention ist, eine Deklaration <meta charset="utf-8"> nahe dem Anfang jedes Dokuments zu platzieren, was dem Browser eindeutig sagt, wie er die folgenden Bytes zu interpretieren hat. Es zu deklarieren beseitigt jedes Raten und hindert den Browser daran, auf eine fehlerhafte Annahme zurückzufallen.

Wo sich noch immer Fehler einschleichen

Diese Deklaration auszulassen oder die Schichten sich widersprechen zu lassen, ist genau dort, wo sich noch heute Probleme einschleichen. Wenn eine Datei in einer Kodierung gespeichert, aber mit einem Header ausgeliefert wird, der eine andere behauptet, oder ganz ohne Deklaration gerendert wird, kann ein Browser falsch raten und genau das Mojibake wieder einführen, das Unicode beseitigen sollte. Die Fehler sind fast immer eine Diskrepanz zwischen den Schichten und kein Defekt von UTF-8 selbst.

Der praktische Rat ist daher beruhigend einfach: Speichern Sie Ihre Dateien in UTF-8, liefern Sie sie in UTF-8 aus, und deklarieren Sie UTF-8. Bringen Sie diese drei in Einklang, und eine ganze Kategorie frustrierender, schwer aufspürbarer Kodierungsfehler verschwindet einfach. UTF-8 setzte sich gerade deshalb durch, weil es das richtige Verhalten zur einfachen Standardeinstellung macht, und Ihre gesamte Kette dahinter auszurichten ist einer der kostengünstigsten Zuverlässigkeitsgewinne der Webentwicklung.