Shellskripte aus der Stümper-Liga – Folge 16: Decoding

Kurz vor dem Millenniumswechsel fürchtete sich die kollektive IT-Welt vor dem Y2K-Problem: Die erste Stelle der vierstelligen Darstellung der Jahreszahl würde sich ändern, aber viele Programme hatten sie nur zweistellig oder als Differenz zu einem festen Datum kodiert. Es galt also, eine Menge Software anzupassen. Als dann der Wechsel kam, blieb der befürchtete Untergang der Zivilisation bekanntlich aus, kaum jemand hatte den Wechsel nennenswert bemerkt.

Aus dieser Erfahrung heraus zu folgern, dass jeder ähnlich gelagerte Paradigmenwechsel genauso schnell und problemarm über die Bühne geht, ist allerdings nicht zulässig. Ein langwieriges und hartnäckiges Ärgernis stellt beispielsweise die Kodierung von Daten und Dateien dar. Buchstaben, Ziffern und sonstige Zeichen zu speichern, also intern zu repräsentieren, erfordert, sie in Zahlen abzubilden. Diese Zuordnung ist zwangsläufig immer willkürlich, bedarf aber guter Abstimmung zwischen allen, die Daten erzeugen und nutzen wollen.

In der Anfangszeit der Computer gab es pro Plattform oft eine eigene Kodierung, etwa den BCD-Code auf IBMs Großrechnern, die zunächst jede Dezimalziffer von 0 bis 9 auf 4 Bit abbildeten. Darauf setzte dann der Ebcdic-Code (Extended Binary Coded Decimals Interchange Code) auf, der auch Zeichen beherrscht.

Glücklicherweise setzte sich in weiten Teilen der Industrie für lange Zeit Ascii durch, der American Standard Code for Information Interchange. 1968 definiert, gibt er auch heute noch die Reihenfolge vieler Zeichen in der internen Repräsentation vor. Obwohl viele Anwender von Ascii-Dateien sprechen, stimmt das seit gut 30 Jahren gar nicht: Der Code kennt nämlich nur 7 Bit und kann damit nur 128 unterschiedliche Zeichen darstellen. Spätestens seit dem Zeitalter des PC Anfang der 1980er Jahre organisieren aber fast alle Rechnerplattformen ihre Speicher in Bytes (oder Mehrfachen davon), die bekanntlich 8 Bit groß sind.

Kodierungs-Babel

Das achte Bit verdoppelte den Zeichenvorrat und bot nun auch Platz für Umlaute oder andere Sonderzeichen. Heute noch verbreitet sind die Kodierungsvarianten der Normenfamilie ISO-8859. Die Unterversion 1 enthält viele westeuropäische Sonderzeichen, ISO-8859-5 etwa kyrillische Zeichen. Auf vielen Rechnern kommt die Unternorm 15 vor, die ISO-8859-1 entspricht, aber zusätzlich das Eurozeichen enthält. Viele Tools nennen sie auch "Latin-9" oder "westeuropäisch". Wer heute also von Ascii-Dateien spricht, mein oft diese Kodierung. Korrekter wäre die Bezeichnung "Textdatei", wenn man sich nicht auf eine dieser Subvarianten festlegen möchte.

Von ISO-8859 zu UTF-8

Da auch die diversen ISO-8859-Normen nicht alle Schriftsprachen umsetzen, kam Ende der 1980er Jahre die Idee von Unicode auf, einer Kodierung, die alle gebräuchlichen und künftigen Sprachen abdecken sollte. Unicode ist nur eine Art Meta-Standard, denn er erlaubt mehrere Arten, um Zeichen auf Bytes abzubilden. Fast alle Betriebssysteme setzen heute im Auslieferungsstandard die Form UTF-8 ein. Dabei können einzelne Zeichen verschieden lange Repräsentationen erhalten: Die echten Ascii-Zeichen stehen an gleicher Stelle auch im UTF-8-Standard, womit jede Ascii-Datei zugleich eine korrekte und gleichbedeutende UTF-8-Datei ist. Das gilt allerdings nicht für Dateien, die nach ISO-8859 kodiert sind. Den Umlaut Ä repräsentiert die hexadezimale Bytefolge 0xC3, 0x84, wie

$ echo ${LANG}
de_DE.UTF-8
$ echo -n "Ä" | od -t x1
0000000 c3 84
0000002

leicht demonstriert [1]. Die meisten Programme sollten heute prinzipiell in der Lage sein, sowohl mit ISO- als auch mit UTF-Dateien umzugehen. Das Locale-System und die Umgebungsvariablen »LANG« sowie jene, die mit »LC_« beginnen, regeln die Zuordnung. Der Befehl »locale« zeigt die aktuelle Einstellung.