Grundlagen der Zeichenkodierung

16.12.2008 in: Sprache, Typographie, Webdesign und Zeichen • 7 Kommentare
Letzte Änderung: 03.02.2010, 14:08 Uhr.

Diese Einführung übergeht historische Zusammenhänge zu Gunsten der Verständlichkeit. Der gut informierte Leser möge mir dies verzeihen.

Null und Eins

Der Computer ist dumm: Er kennt nur Nullen und Einsen. Software, Texteingaben oder Webseiten – alles besteht aus solchen Nullen und Einsen, dem Binärcode. Nun muß der Computer aber diese beiden Zahlen in eine Menge unterschiedlicher Zeichen wandeln, weil Menschen nicht gut mit Binärcode umgehen können.

Es gibt also irgendein Muster in diesen Zahlenreihen, das dem Computer verrät, welche Abschnitte beispielsweise für ein A stehen, welche für ein B und so weiter. Dieses Verstecken »komplexer« Zeichen in Binärcode heißt Zeichenkodierung.
Damit man nicht immer sagen muß, welche Zeichen man in welchen Teilen des Binärcodes versteckt hat, wurde dieses Verfahren standardisiert und mit Namen versehen: ISO-8859-1 ist so eine Zeichenkodierung, ebenso UTF-8 oder US-ASCII.

Jede Null und jede Eins nennt man ein Bit, acht davon hintereinander ein Byte oder Oktett. In US-ASCII und ISO-8859-1 steckt in jedem Byte genau ein Zeichen. 00101001 steht da beispielsweise für ein A.

US-ASCII

In US-ASCII ist das erste Bit eines Bytes immer eine Null. Das ist sehr praktisch: Wenn mal ein Fehler in der Übertragung auftritt, weiß der Computer recht genau, wo es weitergeht, denn er muß nur das Muster wiederfinden, in dem alle acht Bits eine Null auftaucht.
Leider kann man aber mit den übrigen 7 Stellen (2 hoch 7 oder 2 × 2 × 2 × 2 × 2 × 2 × 2) nur 128 unterschiedliche Zeichen kodieren. Klingt nach viel, ist aber wenig, wie wir gleich sehen werden.

Die ISO-8859-Gruppe

In ISO-8859-1 hat man einfach gesagt: Pfeif auf Unterbrechungen im Transfer; wir benutzen einfach die erste Stelle auch noch. Jetzt hat man also 2 hoch 8 oder 256 unterschiedliche Zeichen. Meine Güte!

Leider sind 256 Zeichen immer noch zu wenig, weil viele dieser Positionen traditionell (sprich: aus dummer Bequemlichkeit) frei bleiben müssen und einige »nur« unsichtbare Steuerzeichen sind: der Zeilenumbruch zum Beispiel oder BELL, das dem Computer einen Pieps entlockt (irre wichtig). Das russische und das deutsche Alphabet und Satzzeichen und die ganz wichtigen unbesetzten Stellen passen da nicht alle zusammen rein.

Lösung 1 war horizontale Diversifikation (vulgo: Ausdehnung in die Breite): Neben ISO-8859-1 wurde ISO-8859-2 standardisiert, dann ISO-8859-3 … heute haben wir ISO-8859-16 (ausführlich dazu: ISO 8859 material). Jede dieser Versionen erlaubt eine andere Kombination von Zeichen, damit jeder seine Dokumente in seiner Sprache nach einer Norm kodieren kann.

Reichte aber trotzdem nicht. Es gibt ja Leute, die chinesischen, arabischen und deutschen Text in ein und demselben Dokument schreiben wollen. Na klar.

Unicode

So wie die HTML-Spezifikation die Bedeutung der Elemente und Attribute regelt, so standardisiert Unicode die Bedeutung der Zeichen. Jedes Zeichen hat einen Eintrag (code point) mit einer fortlaufen Nummer und einem Namen. Das lateinische Alphabet, Musiknoten oder mathematische Operatoren: Sie alle finden Platz im Unicode-Standard.

U+0021 beispielsweise: Es trägt den Namen Exclamation mark, die Bedeutung des Ausrufungszeichens oder der mathematischen Fakultät, und es sieht meistens so aus: !.
U+01C3 hingegen heißt Latin letter retroflex click, bedeutet einen afrikanischen Klicklaut und sieht normalerweise genau so aus wie U+0021: ǃ.
Wenn wir nach dem richtigen Zeichen suchen, orientieren wir uns also nicht am Aussehen, sondern an der Bedeutung. Denn die Gestalt eines Zeichens hängt von der verwendeten Schrift ab, sein Klang von den Spracheinstellungen des Voice-Browsers und so fort. Die Bedeutung bleibt gleich. Sie zählt.

Es existiert kein anderer Standard mit einem vergleichbaren Zeichenumfang. Wer Zeichen aus unterschiedlichen Bedeutungskontexten zusammen benutzen will, wird sich immer an Unicode orientieren.
Praktischerweise entspricht die Reihenfolge der ersten 255 Zeichen in Unicode dem Standard ISO-8859-1 (auch Latin-1 genannt). Wer sich also die Mühe macht, Latin-1 auswendig zu lernen, der hat automatisch gleich den Anfang des Unicode-Standards drauf. Und ganz klar zuviel Zeit …

Jedenfalls bot sich mit Unicode eine andere Lösung des Problems der vielen Zeichen an: vertikale Diversifikation (Ausdehnung nach oben).

UTF-16

Man hat den kompletten Unicode-Standard genommen und eine Zeichenkodierung standardisiert, die ihn aufnehmen konnte: UTF-16 (UTF steht für Unicode Transformation Format). Da hat jedes Zeichen 16 Bit oder 2 Byte Platz. Das sind 2 hoch 16 Stellen also insgesamt 65 536. Das reicht nun wirklich dicke für fast alles.

Die meisten aktuellen Webbrowser kodieren Textformate intern nach UTF-16 um, weil das wirklich eine sehr brauchbare Zeichenkodierung ist.

Da Unicode inzwischen noch mehr Zeichen kennt, gibt es auch UTF-32. Doch dieses Thema fassen wir vorerst nicht an, denn ein Autor oder Webtechniker wird damit kaum in Berührung kommen.
Immerhin verstehen alle aktuellen Webbrowser diese Kodierung, nur der Internet Explorer bis mindestens Version 7 nicht. Und Opera hat die Unterstützung in Version 10 sogar wieder abgeschafft, weil sie nicht gebraucht wird.

Ist UTF-16 also die endgültige Lösung? Nein. Denn es gab schon wieder Leute, die ein Haar in der Suppe fanden (logisch!): Die meisten Zeichen der westlichen Welt wurden recht früh in den Unicode-Standard aufgenommen, haben also niedrige Mitglie- … äh … Positionen. Von den 2 Bytes bestünde eines fast immer aus Nullen. Viele, wirklich sehr viele Dokumente wären in UTF-16 doppelt so groß wie vorher. Das kostet erheblich Speicherplatz, und es verbraucht auch unnötig viel Traffic, wenn man den Text verschicken möchte.

UTF-8

Also hat man 1992 UTF-8 erfunden, einen praktischen Hybriden aus Lösung 1 und 2: Man kodiert die ersten 128 Zeichen aus Unicode mit einem Byte. Damit bleiben die Dokumente der »einflußreichen« Autoren der westlichen Welt hübsch schlank. Und danach nimmt man einfach zwei Bytes. Und wenn zwei nicht ausreichen, nimmt man drei. Und wenn drei nicht ausreichen vier.
Die Chinesen und Araber hat das nicht gefreut, denn deren Zeichen sind ganz weit hinten im Unicode-Standard und somit in UTF-8 manchmal sogar länger als in UTF-16. Aber die waren damals offenbar nicht so wichtig …

Außerdem hat man Regeln eingebaut, nach denen man UTF-8 validieren kann. Wenn eine Reihe von Bits nicht zu UTF-8 gehören können, kann man das mit einem regulären Ausdruck feststellen.

UTF-8 ist für Webtexte immer die erste Wahl. Denn so können unsere Besucher in Formularen jedes beliebige Zeichen eingeben, und wir müssen keine Zeichen maskieren außer &, <, >; ' und ". UTF-8 ist bei Zeichenmengen sehr kompakt, die größtenteils auf dem lateinischen Alphabet beruhen.
Jede XML-fähige Software kann übrigens UTF-8 und UTF-16 verarbeiten; manche können kaum etwas anderes.

Schreiben

Wenn wir ein Dokument in UTF-8 kodieren wollen, dann müssen wir das dem Editor oft extra sagen. Sonst nimmt der irgendwas anderes, hierzulande meistens Windows-1252, eine Obermenge von ISO-8859-1, nur mit weniger Leerstellen und mehr Zeichen (€ beispielsweise).

Heute beherrschen fast alle Editoren UTF-8 (ich verwende meistens Eclipse und auf dem USB-Stick PSPad. Leider können sie meistens nur die Zeichen darstellen, die in der aktuell verwendeten Schrift enthalten sind. Wenn wir also einen sehr breiten Zeichenumfang benutzen, dann brauchen wir auch eine Schrift, die all diese Zeichen enthält, Lucida Sans Unicode beispielsweise.

Weiter geht es mit Zeichenkodierung: Be- und Mißgriffe und Zeichenkodierung angeben.

7 Kommentare

1. Buehler am 29.01.2009 · 09:37

   Danke für die gute und verständliche Anleitung!

   Trotzdem Frage (eines Hobby Webmasters mit wenig Ahnung): Für einen Bekannten mache ich nebenher eine Website (iso 8859-1), einfaches statisches HTML. Er schickt mir Texte per word.doc, die ich per copy und paste eben reinsetze. Problem seit neuestem: Sobald ich copy und paste mache, will mein editor nur noch abspeichern unter UTF - 16. Wieso das????

   Danach habe ich ein BOM im editor quelltext (glaube ich zumindest???). Dh. ganz vorne an allererster stelle, noch vor dem doctype, steht ein kryptisches Zeichen. Und die Website selbst ist dann total zerschossen. Auch wenn ich das BOM von Hand lösche im Editor.

   Wie gehen wir vor? Ich mag nicht den ganzen Webauftritt (kleine Hobbywebsite) auf UTF 8 oder 16 umstellen, soll ja doch etwas schwierig sein. Lösung? Wie soll er mir die Texte zukommen lassen, was muss ich tun?

   THX schonmal

2. Thomas Scholz am 29.01.2009 · 12:46

   Dafür kann es mehrere Ursachen geben. Vermutlich enthalten die Texte Zeichen, die sich in ISO-8859-1 nicht ausdrücken lassen: € beispielsweise oder einige Anführungszeichen.
   Auf der entsprechenden Wikipedia-Seite gibt es eine Übersicht aller erlaubten Zeichen für diese Zeichenkodierung. Daß der Editor (welcher?) freilich erst UTF-16 anbietet, finde ich schon ein wenig schräg. Welcher ist das?

   Wenn die zusätzlichen Zeichen alle innerhalb des Umfanges von Windows-1252 liegen, das eine Obermenge von ISO-8859-1 bildet, dann empfehle ich, die Webseiten auf diese Kodierung umzustellen. Praktisch alle Webbrowser benutzen bei der Angabe ISO-8859-1 intern ohnehin Windows-1252.

   Wenn das nicht hilft, enthält der Text Zeichen, die auch in Windows-1252 nicht ausdrückbar sind. Da kann man nur noch einen Filter darüber laufen lassen und alles maskieren. Diese Funktion bringt eigentlich jeder Editor mit.

   Eine zuverlässige Methode, die den Autor dazu zwingt, nur ISO-8859-1 zu benutzen, gibt es nicht. Ein Webformular wäre möglich; das ist aber sicher unbequem für den Schreiber, und es erfordert eine Menge Programmierung und Sicherheitsprüfungen im Vorhinein.

   Du kannst ihn vielleicht bitten, alle Texte als reine Text-E-Mails zu schicken und dabei darauf zu achten, daß im Feld für die Zeichenkodierung des Mailprogramms ISO-8859-1 steht:

   

   Dann kümmert sich das Programm darum.

3. Buehler am 29.01.2009 · 13:47

   Danke für die prompte Antwort! Info der Vollständigkeit halber:
   Der Editor ist einfaches TextEdit auf MacOs 10.4...... Ich entwickle damit auch nichts, sondern eben nur einfaches copy und paste...
   In der Tat wär mir die liebste Lösung, wenn er mir Texte schickt, die nur Zeichen in Rahmen von ISO-8859-1 enthalten. Sollte doch eigentlich machbar sein..... dieses ISO ist doch immer noch sehr verbreitet. Dass das solche Probleme machen kann, war mir neu.

4. Thomas Scholz am 29.01.2009 · 14:03

   Ich habe mit TextEdit keine Erfahrung, aber es sieht so aus, als sei das eher ein Wordprozessor als ein reiner Texteditor. Versuch doch mal BBEdit.

5. Buehler am 29.01.2009 · 15:41

   TextEdit ist, soweit ich weiss, das was Notepad auf Windows ist. Jedenfalls das einfache Standard Text Programm für Mac. However, der Tip mit der Mail hat funktioniert!! Haben wir also einen Work-Around gefunden.......Dank dafür!

6. h. am 03.02.2010 · 13:55

   echt gut, bin fleißig am lesen, dinge die mir nie klar waren..
   ..in ganz normalem deutsch.

   danke sehr..

   mfg, h.

7. Oliver Stephan am 29.09.2010 · 10:09

   Sehr schöne Darstellung und witzig geschrieben. Danke!