Wie sieht die Zuordnung in ASCII, jetzt genau aus? Die Codes 0-31 sind sogenannte Steuer- bzw. Controlcodes, die für nicht-druckbare Zeichen verwendet werden, beispielsweise Zeilenumbruch oder Tabulator. Das Leerzeichen hat die Nummer 32, die Ziffern 0-9 haben die Codes 30-39, die Großbuchstaben A-Z die Codes 65-90, und die Kleinbuchstaben a-z sind mit 97-122 codiert. Die Zwischenbereiche werden für Interpunktionszeichen und Computerspezifisches wie den Klammeraffen „@“ verwendet.

Was genau ist denn eigentlich ein Byte? Nun, Computer können eigentlich noch nicht einmal (Dezimal-)Zahlen speichern. Vielmehr besteht der Speicher des Computers aus Milliarden oder sogar Billionen winziger Schalter, die entweder ein- oder ausgeschaltet sind. Mit einem solchen System lassen sich daher keine normalen, also Dezimalzahlen, sondern nur Binärzahlen, Zahlen, die lediglich mit Nullen und Einsen dargestellt werden, repräsentieren. Diese einzelnen Kippschalter heißen Bits, und damit die Rechnerei nicht ganz so wüst wird, werden 8 Bits normalerweise zu einem Byte zusammengefasst. Steht an einer Speicherzelle im Computer also die Zahl 65, sieht das in Wirklichkeit so aus:

Die Zahl 65 in Binärdarstellung

Irgendwo im Speicher unseres Computers liegen 8 Birnchen, einige an, einige aus, und die Kombination von An und Aus steht für die Zahl 65. Aber es sind nur 8 Birnchen, und uns beschleicht der Verdacht, dass man mit diesen 8 Birnchen nicht allzuviele verschiedene Zahlen darstellen kann. Wieviele Kombinationen sind denn wirklich mit diesen acht Birnchen möglich? Mathematik leider nur ausreichend minus, also raten wir: Acht! Nein, Moment, kann nicht sein, die Kombination oben steht ja schon für 65. Also schauen wir im Lexikon nach. Aha, es sind 2⁸ = 256. Hab' ich doch gleich gesagt.

Wir müssen aber auch noch die Zahl Null darstellen können. Also kommen wir mit unseren 8 Birnchen/Bits pro Byte nur von 0-255, weil wir die 256 noch der Null opfern. Weit ist das ja nicht. Wenn man allerdings zwei Bytes (16 Bit) nebeneinander betrachtet, sieht die Sache schon anders aus, denn jetzt haben wir für jede der 256 Kombinationen beim rechten Byte noch 256 Kombinationen beim linken Byte, insgesamt also 256 x 256 = 256² = 65536. Bei vier Bytes (32 Bit) auf einmal sind es schon 4.294.967.296, bei den heute schon gebräuchlichen acht Bytes (64 Bit) sogar 18.446.744.073.709.551.616. Es kommt Hoffnung auf.

Speichern wir eine Text-Datei als blanken Text ab (also nicht mit einem Textverarbeitungsprogramm, sondern z. B. mit dem Notepad unter Windows oder vi unter Unix) stellen wir an der Dateigröße fest, dass pro Zeichen (Leerzeichen nicht vergessen!) ungefähr ein Byte an Speicherplatz verbraucht wird. Wenn wir beim Zählen auch Zeilenumbrüche und Tabulatoren nicht vergessen, stellen wir fest, dass es sogar genau ein Byte ist (unter DOS/Windows wird ein Zeilenumbruch allerdings aus Gründen, die das Geheimnis des Erfinders bleiben werden, als zwei Bytes abgespeichert, pro Zeile muss daher noch ein überflüssiges Byte dazugerechnet werden).

Also könn(t)en in einer Textdatei nur 256 verschiedene Zeichen verwendet werden. Ist das wirklich so? Nein, bei ASCII ist es tatsächlich nur die Hälfte, und davon gehen noch einmal die 32 Steuerzeichen (und genaugenommen auch noch die Nummer 127, das Zeichen für die Taste Entf bzw. Del) ab. Bei ASCII werden nämlich nur 7 von 8 möglichen Bits verwendet, hauptsächlich wohl, weil zur Zeit der Definintion von ASCII die meisten Computer-Anwendungen das achte Bit für interne Zwecke verwendeten. Das gilt mit Einschränkungen sogar noch heute. SMTP (Simple Mail Transfer Protocol, siehe [RFC821], inzwischen ersetzt durch [RFC2821] oder auch [RFC822], inzwischen ersetzt durch [RFC2822]), das Netzwerkprotokoll, mit dem E-Mail verschickt wird, kann erst mit einer Erweiterung 8-Bit-Zeichen übertragen. Weil aber noch genügend Mail-Server ohne diese Erweiterung existieren, ist es noch heute üblich, 8-Bit-Mails vor der Übertragung in eine 7-Bit-Darstellung zu konvertieren.

Mit ASCII lassen sich also tatsächlich weniger als 100 Zeichen darstellen. Wir schauen noch einmal im Abschnitt 2.1, „ASCII-Codeset“ nach, welche Zeichen das etwa sind. Wie sieht es beispielsweise mit deutschen Umlauten, französischen akzentuierten Buchstaben, skandinavischen Zeichen aus? Oder griechischen, hebräischen, arabischen, kyrillischen, chinesischen Zeichen. Die sind allesamt nicht definiert, wohlgemerkt, auch die deutschen Umlaute nicht! Wer einen deutschen Text mit Umlauten also als ASCII-Text bezeichnet, weiß nicht, was ASCII ist.

Die International Standardization Organization ISO versuchte mit der Norm ISO 8859 eine gewisse Ordnung in das Chaos zu bringen. In der Norm sind heute 14 Standard-Codesets definiert.

Alle Codesets der Norm ISO 8559 weisen mehr oder weniger große Überschneidungen auf. Im Bereich 128-159 liegen zusätzliche (nicht druckbare) Steuerzeichen, das Zeichen mit der Nummer 160 ist stets das no-break space, das wir in HTML als   kennen, Nummer 173 ist ein Soft Hyphen - ­ (Ausnahme, das noch nicht offiziell standardisierte, auf TIS-620 basierende ISO-8859-11). Auch andere Latin-1-Sonderzeichen, die in ASCII nicht enthalten sind, wie §, ©, ° liegen oft (aber nicht immer) an der gleichen Stelle.

Nicht alle Codesets sind in der Praxis wirklich relevant. Einige haben sich nur teilweise, einige gar nicht durchgesetzt.

3.1.6. ISO-8859-6

Das Codeset ISO-8859-6 ist für Arabisch stark verbreitet, was allerdings nicht zu der Illusion verleiten sollte, dass sich damit arabischer Text adäquat darstellen ließe. Das arabische Alphabet kennt 28 Buchstaben mit jeweils vier, meist unterschiedlichen Schreibweisen. Hierfür braucht man schon 112 unterschiedliche Codes (die ISO-Codesets haben nur 96 Stellen frei, weil die ersten 32 für Steuerzeichen verwendet werden). Hinzu kommen noch die zehn Ziffern, denn die wirklichen arabischen Ziffern unterscheiden sich in der Darstellung erheblich von unseren „arabischen“ Ziffern:

Die arabischen Ziffern 0-9

Die Ziffern sind natürlich von rechts nach links zu lesen (die Null ist also der Punkt, und die Neun ist das Zeichen, das unserer Neun sehr ähnlich sieht) und sind durch (arabische) Kommata getrennt. Die Satzzeichen wie Punkt, Komma, Semikolon weichen ebenfalls mehr oder weniger stark von der uns geläufigen Darstellung ab.

Hinzu kommt eine Unzahl von Ligaturen, Buchstabengruppen also, die über- und untereinander und ineinander verwoben dargestellt werden. Diese Ligaturen werden keineswegs nur in kalligraphischen Schriften, sondern durchaus auch im Alltagsgebrauch verwendet. Prominentestes Beispiel ist die Darstellung für Gott („Allah“), die praktisch durchweg in dieser Form geschrieben wird. Die arabische Sprache und Schrift hat für gläubige Muslime eine spirituelle Bedeutung, und somit sind solche Eigenheiten besonders ernst zu nehmen. ISO-8859-6 wird diesen Anforderungen nur begrenzt gerecht.

Parallel zur Standardisierung im Westen, insbesondere mit ASCII, gab es ähnliche Bemühungen in Osteuropa, insbesondere in der ehemaligen Sowjetunion. Ungefähr zur gleichen Zeit wie die ersten Versionen von ASCII enstanden auch die ersten sowjetischen Codeset-Standards des GOST, des sowjetischen Normungsinstituts. GOST 10859 definierte die 10 Ziffern, 22 Interpunktions- und Sonderzeichen, gefolgt vom russischen Alphabet (nur Großbuchstaben), wiederum gefolgt von den 14 lateinischen Buchstaben ohne (graphische) kyrillische Entsprechung, wiederum gefolgt von weiteren Sonderzeichen und dem Härtezeichen Twjordyj Znak.

Mit GOST 13052 folgte ein volles 7-Bit Codeset, in der unteren Hälfte entsprach es exakt dem ASCII-Codeset (das Dollarzeichen $ war natürlich durch das allgemeine Währungssymbol ¤ ersetzt), in der oberen Hälfte waren für die lateinischen Buchstaben jeweils die kyrillischen Zeichen angeordnet, die lautlich dem lateinischen Pendant am nächsten kamen, wobei allerdings Groß- und Kleinbuchstaben vertauscht waren. Wir erinnern uns kurz zurück an die Zeiten, als die ewigen Weltmeister aus der UdSSR noch die Aufschrift CCCP^[1] auf ihren Eishockey-Leibchen trugen. Und kein Reporter verpasste während der Endspielübertragung die Gelegenheit, darauf hinzuweisen, dass diese Buchstabenfolge tatsächlich „SSSR“ bedeutete. Und der hungrige Moskau-Tourist lernte spätestens am zweiten Tag, dass sich in den Häusern mit dem Schild PECTOPAH ein „RESTORAN“ verbarg.

Dieser Kniff hatte im Alltag enorme Vorteile. Schickte ein Hacker aus Moskau seinem ins Silicon Valley geflüchteten Vetter den letzten Absatz aus Tolstois Anna Karenina, so sah das an seinem GOST-13052-Terminal zuhause so aus:

Die letzten Zeilen aus Anna Karenina (Tolstoi)

Am ASCII-Terminal am anderen Ende der Welt, präsentierte sich dieser Text dann wiederum so:

Er sah eine krude, nach kurzer Übungszeit aber durchaus lesbare Transliteration des russischen Originals. Durch die Vertauschung von Groß- und Kleinbuchstaben war auch sofort erkennbar, welche Text-Teile in der jeweils anderen Sprache geschrieben waren. Antwortete der Vetter mit den neuesten sozialpsychologischen Erkenntnissen aus dem Land der unbegrenzten Möglichkeiten, kamen auch diese Weisheiten wieder lesbar am GOST-Terminal in Moskau an:

Left as an exercise to the reader...

Dieses Konzept hatte sich bewährt, und wurde auch im später auf 8 Bit (also 256 Zeichen) erweiterten Standard KOI8-R ([RFC1489]) beibehalten. Die untere Hälfte entsprach jetzt exakt ASCII, in der oberen Hälfte wurden parallel zu den lateinischen Buchstaben die phonetischen Pendants der kyrillischen Schrift gelegt. Der Trick hatte weiter seine Daseinsberechtigung: Viele Mail-Applikationen waren noch immer nicht in der Lage 8-Bit zu übertragen, und setzten das achte Bit einfach auf Null zurück. Technisch gesehen hieß das, dass alle 8-Bit-Zeichen um 128 Plätze nach vorne geschoben wurden. Konnte ein kyrillischer Text also nicht korrekt übertragen werden, wurde er also tatsächlich mit lateinischen Buchstaben transliteriert, und kam noch immer lesbar am Bestimmungsort an.

Leider wurde dieser intelligente Trick von KOI8-R nicht in ISO-8859-5, dem offiziellen Codeset für kyrillische Schrift, übernommen, was dazu führte, dass KOI8-R im russischen Sprachraum noch immer wesentlich verbreiteter ist, als ISO-8859-5. Es gibt auch noch weitere Varianten des KOI-Codesets, insbesondere KOI8-U für Ukrainisch und KOI8-T für Tadschikisch.

Die Firma Microsoft zeichnet sich traditionell durch eine originelle Auslegung von Normen aus. Die Interpretation von Codesets macht hier keine Ausnahme. Innerhalb der graphischen Oberfläche Windows™ ihres Betriebssystems MS-DOS™ schwenkte sie für den europäischen und amerikanischen Markt scheinbar von den in MS-DOS™ verwendeten IBM-Codesets auf das in der Unix-Welt etablierte ISO-8859-1 um.

Allerdings enthält ISO-8859-1, wie alle Codesets der Familie ISO 8859, eine Lücke, die von Microsoft ausgenutzt wurde. Die Zeichen 128-159 werden in ISO 8859 nicht verwendet. Hintergrund: Geht während der Datenübertragung das achte Bit verloren (in Wirklichkeit gibt es Applikationen, die das absichtlich machen, insbesondere Mail-Server und Mail-Reader), werden die 8-Bit-Zeichen faktisch um 128 Plätze nach vorne geschoben. Aus den Zeichen 128-159 würden dann die Steuerzeichen 0-31, was evtl. zu Problemen führen kann: Wird beispielsweise das 8-Bit-Zeichen mit der Nummer 138 nicht komplett übertragen, käme es beim Empfänger als Zeilenumbruch an, was die Lesbarkeit eines Textes nicht fördert. In pathologischen Fällen könnten auch die Vorder- und Hintergrundfarbe verstellt werden, Fenster auf dem Bildschirm verschoben werden, Pieptöne aus dem Lautsprecher kommen, und so weiter.

Auf Windows-Systemen war dieses Problem wenig relevant, auf Unix-Systemen eigentlich auch, die Problemzone wurde von ISO dennoch freigehalten. Um der Wahrheit die Ehre zu geben: Man muss schon ein ziemlich lausiger Programmierer sein, um eine Anwendung, die Texte verarbeitet, durch solche Control-Codes (also die Zeichen mit der Nummer 0-31) aus der Fassung zu bringen, denn immerhin könnte ein böswilliger Anwender diese bösartigen Steuerzeichen ja auch absichtlich z. B. als Mail verschicken. Die ISO nahm dennoch Rücksicht auf diese fehlerhaften Programme, und einige selbsternannte Gralshüter in der Unix-Welt verteidigen diese Einschränkung noch immer vehement, und verweisen bei den praktischen Erwägungen (es fehlten schlicht und ergreifend wichtige Zeichen in ISO-8859-1) auf das Allheilmittel Unicode. Sie übersehen dabei meist, dass praktisch alle Unicode-Anwendungen (sofern sie UTF-8 verwenden) hemmungslos, sogar in viel höherem Maße, genau diese Problemzone für textuelle Daten verwenden.

3.3.1. CP1252 (Windows-1252)

Was hat Microsoft jetzt genau gemacht? Microsoft benutzt ein gegenüber ISO-8859-1 leicht modifiziertes Codeset namens CP1252 (CP wie CodePage) zur Darstellung westeuropäischer Texte:

CP1252 (Windows-1252)

Erläuterung: Die Kästchen in den ersten beiden Reihen (0-31 oder hexadezimal 00-1F) sind die eigentlichen Control-Chars, die zum größten Teil nicht darstellbar sind. Die Control-Chars, die zur Formatierung von Text verwendet werden (Zeilenumbruch, Tabulatoren, Seitenvorschub, ...) sind einfach leer. Die „Problemzone“ erstreckt sich von der 9.-10. Zeile (128-159 bzw. hexadezimal 80-9F). Wie man sieht, wurde sie durchaus sinnvoll gefüllt: Das Euro-Zeichen ist relativ spät dazugekommen, ansonsten finden wir noch die französischen OE-Ligaturen, und Konsonanten mit Caret. „Gänsefüßchen“ in doppelter und einfacher Ausfertigung, Trademark-Zeichen, und das Y mit Trema.

ISO-8859-1 ist absolut identisch mit Windows-1252 (das ist der gängige Alias für CP1252), nur sind eben die Zeichen 128-159 nicht definiert. Davor und dahinter sieht es jedoch völlig gleich aus.

3.3.2. ISO-8859-15 Revisited

Lange Zeit waren die Unterschiede zwischen ISO-8859-1 und Windows-1252 praktisch wenig relevant, schlicht und ergreifend, weil nicht ein Zeichen dabei war, das ohne größere Mausaktionen und Fingerverknotungen überhaupt in einen Text eingegeben werden konnte. Dann kamen die „intelligenten“ Textverarbeitungsprogramme, die z. B. in deutschen Umgebungen mit Heuristiken dafür sorgten, dass die Eingabe "Wörtliche Rede" vom Textverarbeitungsprogramm in „Wörtliche Rede“ gewandelt wurde (man vergleiche die "doppelten Anführungszeichen" mit den „deutschen Gänsefüßchen oben und unten“).

Die von Microsoft zusätzlich definierten Zeichen waren fast alle notwendig, das sah man auch im Unix-Lager ein, und spätestens mit dem Euro bestand akuter Handlungsbedarf, was die fehlenden Zeichen in ISO-8859-1 betraf. Statt aber einfach die Änderungen von Microsoft zu übernehmen (in den meisten Anwendungen hätte nicht eine Zeile Code geändert werden müssen; es hätte lediglich eines systemweiten Updates der Zeichensätze bedurft), entschied man sich aus Halsstarrigkeit, Prinzipienreiterei, Besserwisserei, Trotz oder einem guten Grund, der mir persönlich nicht bekannt ist, dafür stattdessen ein neues Codeset ISO-8859-15 zu definieren:

ISO-8859-15

Na, endlich, der Euro war da (Nummer 164 bzw. Hex A4), auch die meisten anderen zusätzlichen Zeichen aus CP1252 wurden übernommen, aber der Bereich 128-159 wurde weiterhin freigehalten, und stattdessen wurden Zeichen aus ISO-8859-1 ersetzt. In der Theorie hatte das Unix-Lager also z. B. ein Euro-Zeichen, in der Praxis funktioniert es noch heute in den meisten (Unix-)Programmen nicht.

Der Grund dafür ist ganz einfach: ISO-8859-15 ist inkompatibel zu ISO-8859-1, und hat sich deshalb in der Praxis (noch) nicht durchgesetzt. Das wird wohl auch nie passieren, weil ISO-8859-15 auch inkompatibel zu CP1252 ist, und somit der vorher (eigentlich reibungslos funktionierende) Datenaustausch mit der Windows-Welt nicht mehr funktioniert: Vorher sahen Unix-Nutzer da, wo der Windows-Nutzer das Euro-Zeichen eingegeben hatte nur ein Fragezeichen, in die andere Richtung aber - von Unix zu Windows - wurde jedes Zeichen getreu der Intention des Schreibers wiedergegeben. Mit ISO-8859-15 wurde das Problem auf beide Richtungen ausgedehnt: Wo der Unix-Nutzer das neue Y mit Trema eingibt (Nummer 190, Hex BE) sieht der Windows-Nutzer „3/4“, die OE-Ligaturen kommen als „1/4“ bzw. „1/2“ an. Das Euro-Zeichen aus der Unix-Welt mutiert doch wieder zum Currency-Symbol, die Windows-Gänsefüßchen bleiben Unix-Fragezeichen. Und innerhalb der Unix-Welt bestehen prinzipiell die gleichen Probleme, weil sich die Programme lange Zeit uneins bleiben werden, ob sie Zeichen Nummer 164/A4 als Euro- oder Currency-Symbol interpretieren sollen.

Hätte man stattdessen die Microsoft-Erweiterungen zu ISO-8859-1 übernommen, wäre es möglich gewesen, Programme schrittweise auf die neuen Codes umzustellen (sofern das überhaupt notwendig gewesen wäre). Wie reibungslos das gehen könnte, sieht man an der Windows-Welt, in der die Euro-Einführung ohne größere Probleme vonstatten ging. Dass viele Drucker das Euro-Zeichen nicht kannten, führte nicht zu nennenswerten Irritationen, und unter Unix wird das selbst mit ISO-8859-15 noch lange Zeit üblich bleiben, weil es nicht ganz unwahrscheinlich ist, dass Dokumente, die das Euro-Zeichen verwenden, auf einem Windows-System erstellt wurden.

Fazit: Meiner Meinung nach ist ISO-8859-15 kompletter Unfug und landet hoffentlich bald auf dem Schrotthaufen der Computergeschichte.

Nicht nur Microsoft benutzt proprietäre Codesets. Hewlett-Packard verwendet für sein Unix noch immer das - zu ISO-8859-1 völlig inkompatible - Codeset HP-Roman8. Der Macintosh scheint mit Max OS X standardmäßig auf ISO-8859-1/CP1252 umgeschwenkt zu sein (erlaubt aber auch noch die alten, proprietären Mac-Codesets), NextStep verwendet eigene Codesets, selbst IBM-Mainframes mit EBCDIC (das noch nicht einmal zu ASCII kompatibel ist) sind noch in Gebrauch. Alle diese Systeme sind allerdings nicht genügend verbreitet, um das Chaos noch nennenswert zu verschlimmern, und alle haben mittlerweile Methoden entwickelt, um den Datentransfer mit dem Rest der Welt über Standard-Codesets zu gewährleisten.

Es gibt natürlich noch eine Reihe weiterer Sprachen, die eine überschaubare Anzahl von Schriftzeichen haben, und für die somit eigene ASCII-kompatible 8-Bit-Codesets definiert werden können. Um nicht mit ASCII in Konflikt zu kommen, ist eine Maximalzahl von 128 Zeichen möglich (die ersten 128 sind ja eben von ASCII belegt), aus ISO-8859-Sicht, maximal 96 (32 zusätzliche Control-Codes von 128-159).

Abgesehen von den diversen proprietären Codesets der Firmen Microsoft und Apple für Sprachen, die bereits behandelt wurden, sind noch einige weitere, teilweise durch Wildwuchs entstandene Codesets von Bedeutung.

Angesichts der Vielzahl der darzustellenden Schriftzeichen erscheint die Idee, die ideographischen CJK-Schriften im 8-Bit-Raum darzustellen, natürlich völlig absurd. Scheinbar reicht ein Byte mit acht Bit also spätestens in Ostasien nicht mehr zur Darstellung eines Schriftzeichens aus. Man könnte natürlich einfach mehr Bits in ein Byte packen, um einen größeren Zahlenraum zu schaffen, oder die Eins-Zu-Eins-Beziehung zwischen Bytes und Schriftzeichen aufgeben. Allerdings ist genau diese Eins-Zu-Eins-Beziehung so stark in allen Computer-Betriebssystemen verwurzelt, dass eine generelle Änderung zu enormen Schwierigkeiten führen würde.

Im Abschnitt 2.2, „Von Bits und Bytes“ wurde ja schon beschrieben, wie man es trotz 8-Bit-Bytes hinbekommt, einen Computer mit Zahlen, die weitaus größer als 256 sind, rechnen zu lassen. Man muss lediglich mehrere Bytes (2, 4, 8, ...) zu logischen Einheiten zusammenfassen. Aber auch dieser Ansatz führt zu Schwierigkeiten: Wird ASCII-Text (oder auch Text mit beliebigen 8-Bit-Zeichen) von einem „neuen“ auf ein „altes“ System übertragen, kommt auf dem alten System ein Datenstrom an, der jeweils abwechselnd aus dem Zeichen mit der Nummer Null und dem eigentlichen Zeichen aufgebaut ist. Das Zeichen mit der Nummer Null hat allerdings auf praktisch allen Betriebssystemen, eine Sonderbedeutung, die der Programmiersprache C entstammt: Das sogenannte Null-Byte kennzeichnet das Ende einer Zeichenkette. Programme hören beim ersten Null-Byte also einfach auf, einen Text zu lesen.

Wir werden später sehen, dass dieser Ansatz trotzdem verfolgt wird, er hat aber seine spezifischen Schwierigkeiten. Es gibt aber eine weitere Möglichkeit, die 256-Zeichen-Grenze auch mit 8-Bit-Zeichen zu durchbrechen, das Escaping.

Nehmen wir an, wir hätten die Aufgabe nur mit den Buchstaben des lateinischen Alphabets die deutschen Umlaute Ä, Ö, Ü, ä, ö und ü sowie das ß darzustellen. Jeder kennt den Trick, man schreibt ae, oe, ue und ss, in Computer-Lingo: Wir kodieren bestimmte deutsche Schriftzeichen mit 2 Bytes. Nicht nur für Computer ist diese Codierung aber eigentlich unbrauchbar, denn wir können jetzt nicht mehr zwischen der zuweilen vorkommenden Buchstabenkombination ae und einem ä unterscheiden. Das Wort „Masse“ wäre nur noch aus dem Zusammenhang deutbar, denn es kann sowohl für die echte Masse, als auch für Maße stehen.

Es ist aber auch eine eindeutige Codierung möglich: In der deutschen Sprache taucht der Buchstabe q nur in der Kombination qu auf. Jedes andere Vorkommen eines q ist „illegal“. Eine „kugelsichere“ Codierung könnte also so aussehen: Ein ä wird als „qa“ codiert, ein Ä als „QA“, ö entsprechend als „qo“ und ü/Ü als „qy/QY“ (um die legale Kombination qu zu vermeiden). Aus dem Eszet könnte schließlich ein „qs“ werden, nicht sehr gut lesbar, aber eindeutig.

Nachteil dieser Methode wäre, dass wir keine Wörter aus anderen Sprachen darstellen können, die unsere Restriktion für die Verwendung des q nicht kennen. Das lässt sich aber leicht ausbügeln, indem man die Konvention erweitert: Ein „echtes“ q wird als „qq“ bzw. „QQ“ dargestellt.

Wenden wir die vollständige Regel auf den letzten Absatz an, würden wir folgendes sehen:

Lediglich die Darstellung der längeren „Q-Folgen“ erscheint etwas holprig. Ansonsten bleibt der Text aber durchaus lesbar, und selbst jemand, der unsere Konvention nicht kennt, wird das System spätestens beim zweiten Lesen verstanden haben.

Verallgemeinert lässt sich die Methode also so beschreiben: Man wählt ein (oder auch zwei) Escape-Zeichen aus, vorzugsweise eines, das in normalen Daten selten anzutreffen ist, legt eine Regel fest, dass die auf das Escape-Zeichen folgenden Zeichen eine Sonderbedeutung haben, und sorgt dafür, dass man das Escape-Zeichen noch immer darstellen kann, indem man es z. B. durch sich selber escapen lässt.

Der Trick ist ziemlich alt. In alten Drucker-Handbüchern findet man seitenweise solche Escape-Sequenzen. Wenn formatierte Textdateien ausgedruckt werden, müssen die Format-Informationen (Zeichensatz, fett, kursiv, unterstrichen, ...) ja irgendwie an den Drucker übermittelt werden. Traditionell schickte man dafür das Zeichen mit der Nummer 27 (im Bereich 0-31 für Control-Chars), gefolgt von Zeichenkombinationen, die eben im Druckerhandbuch dokumentiert waren. Dort konnte z. B. stehen, dass mit der Zeichenkombination „Zeichen Nummer 27 gefolgt von [31m“ die Schriftfarbe auf Rot gesetzt wird (bei Terminals ist das meistens sogar so: echo -e "\033[31m").

Weil das Zeichen mit der Nummer 27 so gerne für diesen Zweck eingesetzt wird, heißt es auch Escape und liegt auf der Taste Esc. Man kann die Idee aber auch noch weiterführen, und neben dem Escape-Zeichen auch noch ein Zeichen definieren, das eindeutig das Ende der Escape-Sequenz kennzeichnet. Nimmt man als Escape-Zeichen das kaufmännische Und und als Ende-Markierung das Semikolon, hat man die HTML-Autoren geläufige XML-Entity-Darstellung, bei der ein ä zu &auml; wird, und (weil das Escape-Zeichen selber immer auch in das Escaping einbezogen werden muss) zwingendermaßen die Folge &amp; für das eigentliche Kaufmanns-Und. Verwendet man als Escape-Zeichen „Kleiner-Als <“ und als Ende-Markierung „Größer-Als >“ hat man einen weiteren Weg gefunden, wie man beliebige Zusatzinformationen in einem Text unterbringen kann. Letztere Technik wird in SGML und daraus abgeleiteten Markup-Sprache wie HTML oder XML angewandt.

Praktisch alle Kodierungen für Zeichen außerhalb des 7-Bit-Raums von ASCII bzw. des 8-Bit-Raums von Single-Byte-Codesets beruhen auf diesem Trick. Immer werden bestimmte Zeichenfolgen für die Erweiterung „missbraucht“, und die darauffolgenden Zeichen werden in einem anderen Kontext interpretiert. Der Standard ISO 8859 sieht z. B. einen Mechanismus vor, wie man durch Escape-Sequenzen aus dem 7-Bit-ASCII-Raum auf die obere Hälfte des Codesets (das die Sonderzeichen enthält) um- und wieder zurückschalten kann. Dieser Vorgang wird auch Shiften genannt.

Die meisten Kodierungen für ideographische Schriften mit mehr als 255 Zeichen gehen ähnlich vor. Gängig ist eine Definition, in der alle ASCII-Zeichen für sich selber stehen, und alle 8-Bit-Zeichen (also in ISO-8859-1 die obere Hälfte) eine Multi-Byte-Sequenz einleiten. Eine fiktive Codierung sähe so aus: Die Zeichen 0-127 entsprechen exakt ASCII und werden as is transparent durchgereicht. Hat ein Byte einen Wert im Bereich 128 bis 255 wird ein weiteres Byte gelesen und der Zahlenwert beider Bytes multipliziert.

Wieviele Zeichen könnten wir damit darstellen. 128 Zeichen (0-128) sind schon in ASCII definiert. Das erste Multi-Byte-Zeichen ist Nummer 128. Wenn es von einem Null-Byte gefolgt ist, ergäbe sich nach der obigen Regel 128 x 0 = 0, also exakt ein Null-Byte. Folgt auf ein Byte mit dem Wert 128 eins mit dem Wert 25, wird damit Zeichen Nummer 3200 erzeugt. Maximal könnten zwei Bytes mit dem Wert 256 aufeinanderfolgen. Hier würde sich der Code aus (256 - 128) x 256 = 128,

Das Verfahren wäre einfach, hätte aber etliche Nachteile (in der Praxis geht man schlauer vor). Zunächst einmal ist die Codierung nicht eindeutig, ein und dasselbe Zeichen ließe sich auf mehrfache Art und Weise darstellen. Das erscheint auf den ersten Blick harmlos, wenn es aber darum geht, einen Text nach einer bestimmten Zeichenfolge zu durchsuchen, müsste nach sämtliche Bytefolgen gesucht werden, die für diese Zeichenfolge möglich sind. Das ist ein ziemlicher Nachteil.

Ein weiteres Problem ist die fehlende Segregation der Codierung. Stoßen wir in einem Datenstrom beispielsweise auf ein Byte mit dem Wert 65, lässt sich nicht festellen, ob es dem (ASCII-)Zeichen A entspricht, oder Teil einer Multi-Byte-Sequenz ist. Dieser Mangel ließe sich beheben, indem man fordert, dass auch das zweite Byte im Bereich 128-255 liegen muss. Dann könnte man bei jedem Byte an seinem Wert erkennen, ob es Teil einer Mulit-Byte-Sequenz ist, oder aber ein ASCII-Zeichen.

Weiterhin fehlt es an einer Synchronisation. Gesetzt den Fall, wir hätten die fehlende Segregation wie beschrieben behoben, lägen alle in Multi-Byte-Sequenzen erlaubten Bytes im Bereich 128-255. Wollen wir allerdings bei einem solchen Byte feststellen, wo der Anfang, und das Ende des Multi-Byte-Zeichens ist, stehen wir auf dem Schlauch. Wir müssen von Anfang an nachzählen. Beispiel:

Was ist jetzt ein Zwei-Byte-Zeichen? Die Kombination aus Grad und My, oder My und ä? In der Praxis ist das wichtig, denn dort kommen solche Situationen, in denen man einen Bytestrom verarbeiten muss (und nicht an den Anfang zurückkehren kann, um nachzuzählen) häufig vor.

Die Codierung hat aber auch einen Vorteil: ASCII-Zeichen werden transparent durchgereicht. Das ist einerseits für die Lesbarkeit wichtig, wenn ein Text vergleichsweise wenig Sonderzeichen (im Verhältnis zu ASCII) enthält. Liest man auf einer schlecht konfigurierten Web-Site das Wort „Märchen“ (das Beispiel ist UTF-8, das fälschlicherweise als ISO-8859-1 interpretiert wird), kann man trotzdem noch erkennen, dass von einem Märchen und nicht einem Mädchen die Rede ist. Noch wichtiger wird die ASCII-Transparenz, wenn Texte von Maschinen und nicht von Menschen interpretiert wird. Maschinen/Programme springen meist auf bestimmte Schlüsselwörter an, und sehr häufig sind diese Schlüsselwörter auf die Verwendung von ASCII-Zeichen beschränkt. Werden ASCII-Zeichen von der Codierung nicht angetastet, funktionieren diese Programme weiterhin. Weitergedacht ist dies auch ein starkes Argument für die Forderung, dass Multi-Byte-Codes grundsätzlich keine ASCII-Zeichen enthalten sollten, um eine zufällige Fehlinterpretation auszuschließen.

Beherzigen wir diesen Ratschlag bei unserer Codierung, fordern wir also, dass das zweite Byte unserer Multi-Byte-Sequenzen ebenfalls immer aus dem Bereich 128-255 stammen muss (damit „opfern“ wir natürlich die Hälfte des theoretisch möglichen Wertebereichs), ist unsere Codierung auch file-system-safe. Was verbirgt sich dahinter? Hätten wir definiert, dass beispielsweise die Kombination „ä/“ für ein japanisches Hiragana stehen soll, könnten wir die Codierung nicht für die Benennung von Dateien verwenden, denn unser Dateisystem kennt unsere Codierung höchstwahrscheinlich nicht, und wird sich am Slash (/) im Dateinamen stören.

Gerade für den asiatischen Raum werden bereits seit langem Multi-Byte-Encodings verwendet. Diese Codierungen sind meist erheblich intelligenter als die oben beschriebene Ad-Hoc-Idee, und sind auch in Unicode-Zeiten noch sehr verbreitet. Die perfekte Codierung gibt es nicht, und so wundert es nicht, dass etliche zueinander inkompatible Kodierungen in Gebrauch sind.

Noch nicht einmal offiziell standardisiert, trotzdem weit verbreitet ist beispielsweise Big5, meist als traditionelles Chinesisch bezeichnet. Vereinfachtes (simplified) Chinesisch ist unter dem Namen GB2312 bekannt. Für Koreanisch ist eine Codierung unter dem Namen JOHAB verbreitet, für Japanisch wird oft das von Microsoft entworfene Shift-JIS verwendet.

Die sehr alten EUC-Codierungen existieren in Variationen für verschiedene Länder/Sprachen unter den Namen EUC-JP, EUC-CN, EUC-TW, EUC-KR.

Perfekt wird das Chaos dadurch gemacht, dass für fast alle Codierungen noch etliche Alias-Namen definiert sind, EUC-CN, CN-GB, csGB2312, EUCCN, EUC_CN, GB2312 bezeichnen alle ein und das selbe Codeset.

Und noch eine schlechte Nachricht: Imperia ist unicode-fähig, die oben beschriebenen Multi-Byte-Codesets sind aber eben nicht Unicode. Zur Zeit (April 2003) ist Imperia nicht in der Lage, diese Codesets korrekt zu verarbeiten (genauer gesagt: Imperia ist nicht in der Lage, zwischen solchen Codesest zu konvertieren). Um alle Imperia-Features für ostasiatische Sprachen auszunutzen, muss zur Zeit Unicode verwendet werden. Allerdings existieren etliche Tools, die Unicode in jedes noch so exotische Codeset konvertieren, so dass diese Einschränkung in der Praxis wenig Relevanz besitzt.

Unicode-Zeichen sind 16 Bits groß, die natürliche Repräsentation eines Unicode-Zeichens hat demnach auch 16 Bits oder 2 Bytes, und die meisten Systeme definieren heute deshalb einen Datentyp wide character, im Gegensatz zum normalen character (oft auch zum char verkürzt), der mindestens 16 Bit groß ist. Wohlgemerkt, mindestens 16 Bits, nach oben hin sind vom Standard für die Repräsentation keine Grenzen gesetzt, und deshalb sind system- oder codierungsabhängig auch 32-Bit (4 Byte-)Typen gebräuchlich.

4.1.1. Probleme mit Wide Characters

Ein Schriftzeichen wird nicht mehr durch ein Byte, sondern durch zwei Bytes dargestellt, und alle Probleme sind gelöst. Oder doch nicht? In der Praxis wirft diese Umstellung erhebliche Probleme auf, neben denen die Euro-Einführung oder die Y2K-Problematik winzig anmuten.

4.1.1.1. Auf- und Abwärtskompatibilität

Nehmen wir als Beispiel einen aus dem Zusammenhang gerissenen winzigen Textausschnitt, die Zeichenkette „schreibt über“, die von einem Programm verarbeitet werden soll. Der (Klein-)Buchstabe „s“ hat den ASCII-Code 115, das kleine „c“ hat die Nummer 99, der erste Stolperstein erwartet uns beim kleinen „ü“, von dem wir der Einfachheit halber annehmen, es sei in ISO-8859-1 codiert, habe also die Nummer 252. Insgesamt speichert der Computer die Zeichenkette als Nummernfolge 115, 99, 104, 114, 101, 105, 98, 116, 32, 252, 98, 101, 114. Ist das Programm in C geschrieben, können wir sogar noch davon ausgehen, dass das Ende der Zeichenkette durch ein Pseudo-Zeichen mit der Nummer 0 gekennzeichnet ist.

Die nächsten Überlegungen sind einfacher anzustellen, wenn wir die Nummernfolge nicht mit Dezimalzahlen (also Ziffern von 0-9), sondern mit Hexadezimalzahlen (Ziffern von 0-9 und a-f) darstellen. Es ist nicht notwendig zu verstehen, wie Hexadezimalzahlen interpretiert werden, es reicht völlig aus, zu wissen, dass sie eine andere Darstellung für exakt die gleichen Zahlen sind. In Hex sieht unsere Zeichenfolge so aus:

     s  c  h  r  e  i  b  t     ü  b  e  r
    73 63 68 72 65 69 62 74 20 fc 62 65 72
	    

Jede Zweiergruppe von (Hex-)Ziffern entspricht einem Buchstaben (das Leerzeichen Space hat den Code 30, bzw. 20 als Hexzahl).

Jetzt stellen wir unser System auf Unicode-Wide-Characters um, verbraten pro Zeichen also 2 Bytes. Wenn wir annehmen, dass unser Text in einer Datei auf der Festplatte gespeichert ist, wird diese Datei doppelt so groß, denn pro Zeichen werden jetzt doppelt so viele Bits bzw. Bytes verwendet. Leider weiß unser Programm nichts von dieser Umstellung (es muss noch umprogrammiert werden), und wird beim nächsten Leseversuch folgendes sehen:

        s     c     h     r     e     i     b     t           ü     b     e     r
    00 73 00 63 00 68 00 72 00 65 00 69 00 62 00 74 00 20 00 fc 00 62 00 65 00 72
	    

Die Zeichen wurden doppelt so groß, aus Sicht unseres noch an Bytes gewöhnten Programms wurden sie also mit Nullen aufgefüllt, obwohl noch immer der gleiche Text gemeint ist. Computerprogramme sind dumm, unser Programm macht da keine Ausnahme und wird diese Änderung einfach hinnehmen. Aber was sehen wir, wenn das Programm den Text ausgeben soll? Das hängt von Programminterna ab. Eine Möglichkeit lautet: Nichts! Weshalb? Ein Null-Byte ist in der am weitesten verbreiteten Programmiersprache, der Spache C mit der speziellen Bedeutung End Of String, also Ende der Zeichenkette belegt. Unglücklicherweise fängt unsere Unicode-Zeichenkette fast zwangsläufig schon mit genau diesem Zeichen an, und konsequenterweise gibt unser Programm jetzt eine leere Zeichenkette aus. Dieser Fall (wir sehen nichts) dürfte der häufigste sein, wenn zwei nicht-unicodefähige Programme wide characters austauschen.

Weitaus weniger wahrscheinlich ist, dass das Programm einfach über die nicht darstellbaren Null-Bytes hinweggeht, und alles andere ausgibt. Damit hätten wir erstmal keine Probleme, aber welche Länge wird unser Programm wohl für die Zeichenkette annehmen? 13 oder 26 Zeichen? Und wer weiß, an welchen anderen Stellen die Null-Bytes doch noch für Verwirrung sorgen, und Schaden anrichten?

Der häufigste Fall, wenn die Daten von einem Datenträger gelesen werden (dann gilt die Konvention mit dem Null-Byte nämlich nicht), dürfte der sein, dass das Programm die nicht-darstellbaren Null-Bytes Ersatzzeichen einfügt, wir sehen etwas wie „?s?c?h?r?e?i?b?t? ?ü?b?e?r“.

Wem das noch nicht erschreckend genug erscheint, möge sich vorstellen, dass wir Unicode jetzt richtig ausreizen wollen, und unseren Text endlich etwas weiterschreiben können: „schreibt über Anna Karenina“, wobei wir allerdings den Titel Tolstois Roman im russischen Original darstellen wollen:

Schön wär's. Wahrscheinlicher wird uns unser Programm aber Zeichenmüll in der Art von „?s?c?h?r?e?i?b?t? ?ü?b?e?r^D?^D=^D=^D0^D ^D?^D0^D@^D5^D=^D8^D=^D0“ präsentieren. Der deutsche Part ist noch einigermaßen zu entziffern, der kyrillische Part ist ein Zeichensalat aus willkürlich anmutenden Schriftzeichen, die sich mit Steuerzeichen (meistens das ASCII-Zeichen mit der Nummer 4 End of Transmission - EOT, der Einfachheit halber durch die Zeichenfolge „^D“ ersetzt) abwechseln.

Alles nicht wünschenswert. Also werden wir zusehen, dass wir unsere Programme möglichst schnell auf Unicode umstellen, dass sie also intern alle Textdaten als wide characters erwarten. Versäumen wir es jedoch, den Rest der Welt von der Löblichkeit unseres Vorhabens zu überzeugen, wird eines Tages dennoch eine alte Datei mit 8-Bit-Zeichen den Weg in unser kleines Refugium finden. Bleiben wir bei unserem Beispiel, wir lesen die ursprüngliche, noch nicht nach Unicode konvertierte Datei:

     s  c  h  r  e  i  b  t     ü  b  e  r
    73 63 68 72 65 69 62 74 20 fc 62 65 72
	    

So war es jedenfalls einmal gemeint. Tatsächlich erwartet unser Programm aber, dass jedes Zeichen in zwei Bytes kodiert ist. Der erste Stein rollt uns jetzt in den Weg, weil wir eine ungerade Anzahl von Bytes einlesen, was nie passieren könnte, wenn wir zwei Bytes pro Zeichen verwenden. Wenn wir Pech haben (das hängt vom Talent des Programmiers ab) fliegt uns unser Programm mit Karacho um die Ohren, wenn wir Glück haben, ignoriert das Programm das überflüssige Byte am Ende oder wird wieder stillschweigend ein Ersatzzeichen darstellen, und die (einzelnen) Bytes werden jeweils zu wide characters (doppelten Bytes) zusammengefasst. Das Programm liest:

     s c  h r  e i  b t    ü  b e
    7363 6872 6569 6274 20fc 6265
	    

Hex-Zahlen haben die angenehme Eigenschaft, dass für ein Byte nie mehr als zwei „Ziffern“ gebraucht werden, und man die Bytes einfach nur zusammenschieben muss, um zu Multi-Byte-Darstellungen zu gelangen. Treudoof als Unicode interpretiert sähe unser (deutscher!) Text jetzt aber so aus:

Die Bytefolge „schreibt übe“ naiv als Unicode interpretiert

Nein, das ist nicht unser deutscher Text in japanischer Lautschrift. Noch weniger handelt es sich um eine computergestützte Übersetzung von deutsch auf japanisch. Dass hier ostasiatische Zeichen dargestellt werden, ist reiner Zufall, weil sie gerade im Bereich der falsch interpretierten Daten liegen. Tatsächlich steht hier Nonsens (hoffe ich doch jedenfalls).

All dies könnte man jedoch als Übergangsschwierigkeiten betrachten. Nach einer gewissen Zeit könnten sämtliche Softwareprogramme an die neue 16-Bit-Konvention angepasst werden, und wir wären da, wo wir hinwollen. Selbst dann wäre diese Konvention aber noch mit erheblichen Nachteilen belastet.

4.1.1.2. Speicherverbrauch

Auch jenseits allen westeuropäisch-amerikanischem Chauvinismus', ist die Tatsache nicht zu verleugnen, dass ein ganz großer Teil der (Text-)Dateien, die von Computern verarbeitet und zwischen ihnen ausgetauscht werden, mit dem 8-Bit-Codeset ISO-8859-1 (bzw. Windows-1252) kodiert ist, und diese Codierung auch für eine adäquate Darstellung geeignet ist. Viele weitere Sprachen kommen ebenfalls prinzipiell mit einem 8-Bit-Zeichensatz aus. In einer reinen Unicode-Welt, würden diese Daten plötzlich alle auf die doppelte Größe aufgebläht, würden doppelt so viel Platz auf Festplatten und im Speicher verbrauchen, würden bei der Übertragung im Netzwerk die doppelte Bandbreite verschlingen und würden auch (mindestens!) die doppelte Zeit für ihre Verarbeitung benötigen. Neben den Kompatibilitätsschwierigkeiten ist dieser Aspekt sicher der wichtigste Grund, der einer Migration von 8 nach 16 Bit für Textdaten entgegensteht.

4.1.1.3. Synchronisation

Theoretisch ließen Computer sich vollständig auf die neue 16-Bit-Konvention umstellen. Praktisch wird dies unmöglich sein. Bei Netzwerkprotokollen interessiert es beispielsweise nicht wirklich, ob es sich bei den übertragenen Daten um Text oder Bilder, Sound, Video, Programmdateien oder was auch immer handelt. Die Daten werden weiterhin als Byteströme interpretiert werden. Das gleiche gilt, wenn Daten aus Gerätedateien (Festplatten, Sound-/Grafikkarten, etc.) gelesen werden. Auch hier wird sich in absehbarer Zeit nichts ändern, und diese Vorgänge werden weiterhin byteorientiert stattfinden.

Bei Datenströmen kommt es jedoch nicht selten vor, dass der Lesevorgang irgendwo, mitten im Datenstrom beginnt oder endet. Entsprechen die Bytegrenzen gleichzeitig Zeichengrenzen ist dies kein Problem. Bei wide characters, also 2-Byte-Zeichen wird das Lesen solcher Datenströme zur Herausforderung, denn die lesende Applikation kann immer nur Paare von Bytes sinnvoll interpretieren. Kann nicht ermittelt werden, ob das erste Byte eine gerade oder ungerade Hausnummer hat, können die Daten auf zwei unterschiedliche Arten interpretiert werden, mit anderen Worten: Es kann nicht ermittelt werden, ob das erste Byte im Datenstrom das vordere oder hintere Byte eines wide characters ist.

4.1.1.4. File-System-Safety

Diesem CJK-Silbenzeichen wurde im Unicode-Standard die Nummer 17.210 (hexadezimal 0x433a) zugewiesen. Darüber werden wir uns nicht wenig freuen, bis wir auf die Idee kommen, einer Datei auf einem Windows-Rechner einen Namen zu geben, der mit diesem Zeichen beginnt. Zerlegen wir die Zahl 17.210 nämlich in zwei einzelne Bytes, erhalten wir 67 und 58, und das sind die ASCII-Codes für die Zeichen „C“ und „:“. Es bleibt eine Übungsaufgabe für die Leserin, die Unicode-Zeichenfolge zu bestimme, die (fälschlicherweise) als ASCII interpretiert C:\WINNT\system\very_important.dll ergibt.

Dies ist natürlich kein Windows-Problem. Alle Dateisysteme haben „verbotene“ Zeichen in Datei- und Verzeichnisnamen. Solange die Dateisysteme aber nicht unicodefähig sind, kann es zu bösen Überraschungen kommen, wenn eine Unicode-Byte-Folge zufällig solche verbotenen Zeichen enthält.

4.1.1.5. Was haben Eier mit Bytes zu tun?

Lemuel Gulliver, zunächst Schiffsarzt dann Kapitän auf einigen Schiffen, wurde folgendes auf seiner Reise in das Land Lilliput kolportiert (Quelle [Gulliver's Travels]):

It began upon the following Occasion. It is allowed on all Hands, that the primitive way of breaking Eggs, before we eat them, was upon the larger End: But his present Majesty's Grand-father, while he was a Boy, going to eat an Egg, and breaking it according to the ancient Practice, happened to cut one of his Fingers. Whereupon the Emperor his Father published an Edict, commanding all his Subjects, upon great Penaltys, to break the smaller End of their Eggs. The People so highly resented this Law, that our Histories tell us there have been six Rebellions raised on that account; wherein one Emperor lost his Life, and another his Crown. These civil Commotions were constantly fomented by the Monarchs of Blefuscu; and when they were quelled, the Exiles always fled for Refuge to that Empire. It is computed, that eleven thousand Persons have, at several times, suffered Death, rather than submit to break their Eggs at the smaller End. Many hundred large Volumes have been published upon this Controversy: But the books of the Big-Endians have been long forbidden, and the whole Party rendered incapable by Law of holding Employments. During the Course of these Troubles, the Emperors of Blefuscu did frequently expostulate by their Ambassadors, accusing us of making a Schism in Religion, by offending against a fundamental Doctrine of our great Prophet Lustrog, in the fifty-fourth Chapter of the Brundrecal (which is their Alcoran.) This, however, is thought to be a meer Strain upon the Text: For the Words are these: That all true Believers shall break their Eggs at the convenient End: and which is the convenient End, seems, in my humble Opinion, to be left to every Man's Conscience, or at least in the power of the Chief Magistrate to determine. Now the Big-Endian Exiles have found so much Credit in the Emperor of Blefuscu's Court, and so much private Assistance and Encouragement from their Party here at home, that a bloody War has been carried on between the two Empires for six and thirty Moons with various Success; during which time we have lost forty Capital Ships, and a much greater number of smaller Vessels, together with thirty thousand of our best Seamen and Soldiers; and the Damage received by the Enemy is reckon'd to be somewhat greater than Ours.

Gut zwei Jahrhunderte später brach ein ähnlich heftiger Glaubenskrieg um die Frage aus, wie Zahlen größer als 255 (also Zahlen, zu deren Darstellung man mehr als ein Byte braucht) intern darzustellen seien. Aus Abschnitt 2.2, „Von Bits und Bytes“ erinnern wir uns, dass der Trick prinzipiell darin besteht, diese großen Zahlen in Kombinationen von zwei, vier oder sogar acht Bytes darzustellen. So wie es nur die Ziffern 0-9 gibt, können wir dennoch Zahlen beliebiger Größe mit diesen Ziffern darstellen, wenn wir nur einfach genügend Ziffern aneinanderreihen. Die Zahl zwölf wird als Kombination aus eins und zwei dargestellt, wobei wir die erste Ziffer einfach mit zehn multiplizieren (12 = 1 x 10 + 2). Bei den Bits und Bytes gilt das gleiche, nur dass wir hier jeweils mit 256 multiplizieren müssen. Wenn wir die beiden Bytes 67 (binär 01000011) und 58 (binär 00111010) aneinanderreihen, erhalten wir also die Zahl 17.210 = 67 x 256 + 58. Oder - um bei den uns vertrauten Glühbirnen zu bleiben:

Die Zahl 17.210 in Binärdarstellung

Das scheint doch sehr klar. Oder doch nicht? Wie wäre es, wenn wir die beiden Bytes nicht von links nach rechts, sondern von rechts nach links anordnen?

17.210 binär, aber verkehrt herum?

Das erscheint zunächst ziemlich abwegig, aber es gab Hardwarehersteller, die genau diesen Weg gingen, bei Byte-Folgen also das weniger signifikante Byte (Least Significant Byte - LSB) vor das Most Significant Byte (MSB) setzten. Nein, diese Hardwarehersteller kamen nicht aus der arabischen Welt, sondern aus dem Silicon Valley in Kalifornien. Und, nein, LSB-Prozessoren sind keine exotische Ausnahme; die Intel- (oder Intel-kompatiblen) Chips, die sich in gängigen PCs finden, gehören allesamt zur LSB-Fraktion, würden die Zahl zwölf - um bei der Analogie zu bleiben - also als „21“ darstellen.

Die prominentesten Vertreter des anderen, des MSB-Lagers, sind die Prozessoren der Firmen Sun Microsystems und Motorola, sowie die meisten Prozessoren der Risc-Architecktur, und weil die Standpunkte der Verfechter der einen und der anderen Fraktion ähnlich unvereinbar, und ihre Auseinandersetzungen ähnlich unversöhnlich wie die der Big- und Little-Endians in Lilliput waren, bürgerte es sich ein, die beiden Byte-Sex- (sic! Auch dies ist ein Terminus Technicus!) Varianten als big-endian (MSB) und little-endian (LSB) zu bezeichnen. In der Praxis muss also bei jeder Zahl über 255 dazugesagt werden, welcher Konvention folgend sie denn abgespeichert ist, was einigen Rechenaufwand verursachen kann. In praktisch allen Netzwerk-Protokollen wird eine Big-Endian-Darstellung postuliert, was dazu führt, dass Little-Endian-Intel-Boxen alle Zahlen intern an den Schnittstellen zum Netzwerk drehen müssen, selbst, wenn sie unter sich bleiben.

Einigermaßen unangenehm ist es, wenn der Byte-Sex (weniger zweideutig auch als Endianness bezeichnet) von Daten nicht bekannt ist, weil dies natürlich, zu einer Ambivalenz bei der Interpretation der Daten führt. Speichern wir einen Text mit Wide Characters auf einem Intel-PC ab, und übertragen ihn auf einen Sparc-Server der Firma Sun, haben wir ein handfestes Problem, weil die beiden Rechner unterschiedliche Vorstellungen über die Interpretation der Daten haben.