Tips für Web-Profis (Designer & HTML-Autoren)
◀Zurück zur Übersicht aller Themen
Zeichenkodierung in UTF-8
Voraussetzungen
Wer schon mal ein Problem mit der Text-Darstellung in Webseiten hatte, erfüllt schon alle Voraussetzungen, um diese Anleitung zu verstehen. Wer die Thematik der Zeichenkodierung von Grund auf verstehen will, für den gibt es an anderer Stelle dieses Website eine leicht verständliche Herleitung zum Thema Unicode (bzw. UTF‑8 im Speziellen).
Warum UTF-8
Eine Zeichenkodierung übersetzt Zeichen (Buchstaben, Ziffern, Symbole) in Werte, die ein Computer verarbeiten kann, also in Zahlenwerte, die letztendlich als Bitfolgen verarbeitet werden.
Klassische Zeichenkodierungen können nur Zeichensätze mit einer sehr begrenzten Anzahl von Zeichen abbilden. Alles, was über das englischen Text hinausgeht, führt oft zu Problemen. Auf diese soll hier nicht weiter eingegangen werden, weil die Lösung so einfach ist: Einfach die Seiten in UTF‑ kodieren.
Probleme & Lösungen
Der Browser kann Zeichen nicht darstellen
Bei Sonderzeichen und Symbolen aus anderen Sprachen muss, damit die Darstellung funktioniert, auf dem System (PC, Smartphone, ...) ein Font installiert sein, der das jeweilige Zeichen auch darstellen kann. Da UTF-8 sich als Standard etabliert, treten diesbezügliche Probleme kaum noch auf. Die allermeisten PCs und andere Endgeräte können problemlos graphische Symbole und exotische Sprachen wie Arabisch, Japanisch oder Thai darstellen. Ich konnte allerdings zwei Sprachen finden, die mein Browser derzeit (2012) nicht darstellt (New Thai und Old Turkic).
Nichtsdestotrotz ist es wichtig zu wissen, für welches Endgerät man schreibt. Stünde den Lesern meiner Seiten aus irgendwelchen Gründen nur alte VT-100-Terminals zur Verfügung, dann wäre selbst ein scharfes S schon eine Herausforderung und würde zu einer Folge von hieroglyphischen Symbolen auf dem Bildschirm führen.
Wir haben Regel Nummer 1 gelernt:
Füge keine Zeichen in die Seite, die beim Betrachter nicht dargestellt werden können.
Falsche Kodierung
Wenn man UTF-8 benutzen will, muss man die Datei (die Seite also) auch in UTF‑8 kodieren. Das klingt logisch, ist aber manchmal ein Problem: Der Editor ist ein Monster und verheimlicht oft, was er mit unserem mühsam eingetippten oder -geklebten Inhalt macht. Unter Windows ist es z.B. sehr wahrscheinlich, dass ein Editor Dateien grundsätzlich in Windows-1252 oder UTF-16LE kodiert. (Beide Kodierungen sind es meiner Meinung nicht wert, dass man dazu hier irgendetwas erklärt.)
Daher ist es, wie bei aller professionellen Arbeit, sehr wichtig, dass man sein Werkzeug kennt. Jeder gute Editor erlaubt dem Benutzer, die Textkodierung einzustellen. Diese muss „UTF-8 (ohne BOM)”, in Englisch „UTF-8 (without BOM)” lauten. Das ominöse Dings-BOMs wird übrigens weiter unten erklärt.
Wie kann man testen, ob eine Seite denn wirklich in UTF-8 kodiert ist? Nun, dazu muss man sich die Datei in Rohform, also Byte für Byte, ansehen. Dazu sollte man einen möglichst primitiven Hex-Editor in der Werkzeugkiste haben. Je einfacher, desto ungefilterter die Ergebnisse. Unter Windows empfehle ich XVI32. Unter Linux can man einfach vi in den Hex-Modus schalten (an: :%!xxd, aus: :%!xxd -r) or Tweak benutzen. Keine Angst: Hex ist keine Hexerei. Übrigens mag der eigene Luxus-Editor vielleicht auch einen Hex-Modus anbieten, aber diesem sollte man nicht trauen! Hier aber nun, wie man die Kodierung einer Text-Datei oder HTML-Seite überprÜfen kann:
Im normalen Editor fügt man folgende Zeile ans Ende der Datei:
Ä Ç ß
Danach sollte auch kein Zeilenumbruch kommen - die Datei soll einfach mit ß
enden.
Jetzt wird die Datei gespeichert und anschließend mit dem Hex-Editor geöffnet.
Am Ende der Datei sollte jetzt folgende Hex-Sequenz zu sehen sein:
C3 84 20 C3 87 20 C3 9F
Wenn die Datei nicht so endet, ist sie schlicht und einfach nicht in UTF-8 kodiert.
Wir haben Regel Nummer 2 gelernt:
Stelle sicher, dass die Datei(en) auch wirklich in UTF-8 kodiert sind!
Die Angabe der Kodierung fehlt in der Datei
Computersysteme von heute können die Kodierung nur mangelhaft erraten. Wenn die Kodierung nicht angegeben ist, springen viele Programme auf beliebige Kodierungen. In Windows-Umgebungen ist das in der Regel nicht UTF-8.
Um der lesenden Software die Kodierung mitzuteilen, sollte der Webserver einen entsprechenden Header mitsenden. Wenn man einen eigenen Webserver betreibt, kann man das auf diesem konfigurieren. Allerdings ist die zuverlässigere Methode, ein entsprechendes Meta-Tag in den Seitenkopf einzubauen. Dieses funktioniert nämlich auch dann noch, wenn man die Datei zum Beispiel auf einen anderen Webserver lädt oder die Konfiguration des Webservers aus anderen Gründen verändert wird.
Also kommt irgendwo zwischen <head> und
</head> folgende Zeile:
<meta http-equiv="Content-Type"
content="text/html;charset=utf-8" />
Wir haben Regel Nummer 3 gelernt:
In den Head-Abschnitt der Webseite gehört ein Meta-Tag, welches den Typ und die Kodierung spezifiziert.
Byte-Order-Mark (BOM)
Eine Byte-Order-Mark (Zeichenordnungsmarkierung)
ist eine kurze Zeichenfolge am Anfang einer Datei,
die angibt, wie die Datei Kodiert ist. Im Speziellen sagt sie aus, welche
Art von Unicode angewendet wurde - es gibt neben UTF-8 auch noch andere.
Somit wäre so eine BOM ja nichts schlechtes und eigentlich könnte man sich
ja dann den Content-Type-Header sparen. Das stimmt aber so nicht, weil ein
Browser ja auch Texte verarbeiten muss, die nicht in Unicode kodiert sind.
Viele Browser lesen daher die BOM wie ganz normalen Text, und hier entstehen
die Probleme damit. Die BOM wird dann nämlich als lustige Zeichenfolge
am Anfang einer Webseite angezeigt. Das kann etwas so aussehen:

Wenn dieses Problem auftritt, ist der Editor wahrscheinlich so eingestellt, dass er die BOM einfügt. Ob das geschehen ist, sieht man, wenn man die Datei mit einem Hex-Editor öffnet. Mehr zu Hex-Editoren siehe oben unter Regel Nummer 1.
Wenn eine in UTF-8 kodierte Seite eine BOM hat, dann sind folgende Zeichen
am Anfang der Datei zu finden:
EF BB BF
Vielleicht findet sich am Anfang der Datei auch eine andere BOM. Das kann ein
Hinweis darauf sein, dass die Datei gar nicht in UTF-8 sondern z.B. in
UTF-16LE (ein leidiges aber leider von Microsoft bevorzugtes Format) kodiert
ist. Wenn die Seite also nicht mit obiger UTF-8-BOM beginnt, sollte man am
Datei-Anfang auch nach folgenden Sequenzen Ausschau halten:
FE FF
FF FE
00 00 FE FF
00 00 FF FE
Falls der eigene Editor auch nach Umstellung auf UTF-8 ohne BOM die BOM nicht von selber entfernt, kann man die BOM auch im Hex-Editor entfernen.
Wir haben also Regel Nummer 4 gelernt:
Webseiten immer ohne BOM abspeichern.