Angabe der Zeichencodierung in HTML

Wie muss man die Zeichencodierung einer HTML-Datei angeben?

HTTP-Header

Sie sollten auf jeden Fall HTTP-Header-Angaben verwenden, wenn die Wahrscheinlichkeit besteht, dass Ihr Dokument umcodiert wird (d.h. dass die Zeichencodierung von zwischengesschalteten Servern geändert wird), denn HTTP-Angaben haben höhere Priorität als Angaben im Dokument.

Ansonsten sollten Sie HTTP-Header für alle Inhaltstypen verwenden, für die das sinnvoll ist, aber in Verbindung mit einer Angabe im Dokument (siehe unten). Stellen Sie immer sicher, dass die HTTP-Angaben mit den Angaben im Dokument übereinstimmen.

Wenn Ihre Seite in UTF-16 codiert ist, geben Sie als Zeichencodierung nicht "UTF-16BE" oder "UTF-16LE" an, sondern verwenden Sie ausschließlich "UTF-16" und setzen Sie ein BOM (byte-order mark) in ihre Datei.

Deklarationen innerhalb des Dokuments

Setzen Sie in den folgenden Beispielen die jeweilige Zeichencodierung anstelle von "UTF-8" ein, wenn nicht anders angegeben.

Bezeichnungen von Zeichencodierungen

Bezeichnungen für Zeichencodierungen finden Sie im IANA-Register. Verwenden Sie diese Bezeichnungen für alle hier angeführten Methoden zur Angabe der Zeichencodierung. Beachten Sie, dass sich diese, obwohl sie bei der IANA charset genannt werden, in Wirklichkeit auf Zeichencodierungen beziehen, nicht auf Zeichensätze.

Das IANA-Register enthält oft mehrere Bezeichnungen für dieselbe Codierung. In diesen Fällen sollte die als preferred (bevorzugt) gekennzeichnete Bezeichnung verwendet werden.

Es ist möglich, eigene Bezeichner für Zeichencodierungen mit vorangestelltem x- zu entwerfen, aber das ist gewöhnlich keine gute Idee, denn es schränkt die Interoperabilität ein.

Beachten Sie den Bindestrich im Bezeichner UTF-8.

Alternative Ansätze

Es gibt verschiedene Alternativen zu den oben empfohlenen Ansätzen; diese haben Vor- und Nachteile. Folgen Sie diesen Links für weitere Details:

• Verwendung der Pragma-Direktive in HTML5 anstelle des meta-charset-Attributs
• Verwendung des meta-charset-Attributs in HTML4
• Verwendung einer XML-Deklaration in als HTML ausgeliefertem XHTML 1.x

Der HTTP-Header

Die Content-Type-Information im HTTP-Header kann die Information über die Zeichencodierung des Dokuments enthalten.

HTTP/1.1 200 OK
Date: Wed, 05 Nov 2003 10:46:04 GMT
Server: Apache/1.3.28 (Unix) PHP/4.2.3
...
Content-Type: text/html; charset=UTF-8
Content-Language: de

Die Zeichencodierung kann im HTTP-Header nicht nur für HTML-Dateien angegeben werden, sondern auch bspw. für CSS- und JavaScript-Dateien.

Bei dynamisch per Script generierten Dokumenten kann man diese Informationen explizit zum HTTP-Header hinzufügen. In PHP bspw. verwenden Sie die header()-Funktion vor der Erzeugung von Inhalt, z.B.:

Bei statischen Dateien kann der Server diese Informationen mit den Dateitypen assoziieren. Wie der Server einzustellen ist, damit er die Zeichencodierung auf diese Weise angibt, ist von Server zu Server verschieden. Das sollte mit dem Server-Administrator geklärt werden.

Apache-Server bspw. geben üblicherweise die voreingestellte Zeichencodierung an, die durch Nutzereinstellungen überschrieben werden kann. Ein Nutzer könnte bspw. folgende Zeile zu einer .htaccess-Datei hinzufügen, um alle Dateien mit der Endung .html in diesem und allen Unterverzeichnissen als UTF-8 auszuliefern:

Für weitere Informationen zur Änderung der Zeichencodierung im HTTP-Header siehe Einstellung des HTTP-charset-Parameters.

Betrachten wir nun, ob es angebracht ist, die Zeichencodierung im HTTP-Header, innerhalb des Dokuments oder beides anzugeben.

Vorteile

• Die Information im HTTP-Header hat die höchste Priorität, wenn sie sich von Angaben im Dokument unterscheidet. Zwischengeschaltete Server, die die Daten umcodieren (d.h. in eine andere Zeichencodierung konvertieren), nutzen dies aus, um die Zeichencodierung eines Dokuments zu ändern, bevor es an kleine Geräte ausgeliefert wird, die nur einige wenige Codierungen verstehen. Da die Information im HTTP-Header Vorrang gegenüber allen Angaben im Dokument hat, ändern Umcodierer typischerweise nicht die internen Angaben, sondern nur die Zeichencodierung und deren Angabe im HTTP-Header.

• Nutzerprogramme können die Zeichencodierungs­information leicht finden, wenn sie im HTTP-Header gesendet wird.

Nachteile

• Für Inhaltsautoren kann es schwierig sein, die Zeichencodierungs­information für statische Dateien auf dem Server zu ändern – besonders, wenn man es mit einem Provider zu tun hat. Sie benötigen Kenntnisse über und Zugang zu Servereinstellungen.

• Servereinstellungen können aus verschiedenen Gründen aus der Synchronisation mit dem Dokument geraten. Das kann bspw. geschehen, wenn man sich auf die Voreinstellung des Servers verlässt und sich diese ändert. Das ist eine sehr ungünstige Situation, denn die höhere Priorität der HTTP-Information gegenüber Angaben innerhalb des Dokuments kann das Dokument unlesbar machen.

• Es gibt potentielle Probleme bei statischen und dynamischen Dokumenten, wenn diese nicht von einem Webserver gelesen werden, sondern bspw. auf CD oder Harddisk gespeichert sind. In diesen Fällen gibt es gar keine Zeichencodierungs­information aus einem HTTP-Header.

  Wenn die Zeichencodierung ausschließlich im HTTP-Header angegeben ist, steht diese Information auch nicht zur Verfügung, wenn Dateien editiert werden, wenn sie durch XSLT oder Scripte verarbeitet werden oder wenn sie zur Übersetzung geschickt werden usw.

Sollte man diese Methode also verwenden?

Wenn Dateien per HTTP von einem Server ausgeliefert werden, ist es kein Problem, die Information über die Zeichencodierung des Dokuments im HTTP-Header zu senden, solange diese Information korrekt ist.

Wenn Sie denken, dass die Möglichkeit besteht, dass die Zeichencodierung der Datei zwischendurch geändert wird, bevor sie den Nutzer erreicht (z.B. dass sie in eine für Mobiltelefone verständliche Codierung umcodiert wird), dann sollten Sie die HTTP-Angabe verwenden, denn genau dort vollzieht sich die Änderung.

Andererseits empfiehlt sich aufgrund der oben genannten Nachteile, die Zeichencodierungs­information immer auch zusätzlich innerhalb des Dokuments anzugeben.

(Manche vertreten die Auffassung, dass es kaum sinnvoll ist, die Zeichencodierung im HTTP-Header anzugeben, um sie innerhalb des Dokuments zu wiederholen. Sie schlagen daher vor, dass der HTTP-Header gar keine Angabe zur Zeichencodierung des Dokuments macht. Das bedeutet üblicherweise, Maßnahmen zu ergreifen, die Voreinstellungen des Servers zu deaktivieren.)

Das meta-charset-Attribut

Die HTML5-Spezifikation beschreibt eine neue Art, die Zeichencodierung eines Dokuments anzugeben. Dies wird auch schon von den gängigen Browsern unterstützt. Sie können dies für in HTML5 geschriebene Seiten verwenden. Alternativ können Sie auch die Pragma-Direktive verwenden, aber nicht beides zusammen.

Wenn Sie diese Angabe bei HTML4-Seiten verwenden, wird das der HTML4-Validator beanstanden (wenngleich der Browser die Information erkennen wird).

Die Angabe sieht folgendermaßen aus:

Die HTML5-Spezifikation verlangt, dass das gesamte meta-Element in den ersten 512 Bytes des Dokuments Platz findet. Fügen Sie dieses also immer zu Beginn des head-Elements ein.

Bei Verwendung von UTF-8 braucht man eigentlich keine explizite Angabe, es ist aber dennoch besser, eine zu machen, denn dann kann man die Zeichencodierung im Quelltext visuell erkennen. Es könnte auch die Unterstützung von älteren Browsern und Autorenwerkzeugen verbessern.

Für UTF-16-codierte Seiten siehe Verwendung von UTF-16.

Die Pragma-Direktive

Das ist ein meta-Element, das so früh wie möglich zu Beginn des head-Elements stehen sollte und folgendermaßen aussieht:

Die Zeichencodierung des Dokuments ist hinter charset= angegeben. In diesem Fall wurde als Zeichencodierung die Unicode-Codierung UTF-8 angegeben.

Die Pragma-Direktive sollte bei in HTML 4.01 geschriebenen Seiten verwendet werden. Sie sollte auch bei als HTML ausgelieferten XHTML-1.x-Dokumenten verwendet werden, denn ein HTML-Parser holt sich keine Zeichencodierungs­information aus der XML-Deklaration.

Bei HTML5 können Sie die Zeichencodierung entweder auf diese Art angeben oder das neu spezifizierte meta-charset-Attribut verwenden, aber nicht beides zusammen. Die Angabe der Zeichencodierung sollte in den ersten 512 Bytes des Dokuments Platz finden. Setzen Sie diese also gleich hinter das Start-Tag des head-Elements.

Eine solche Angabe innerhalb des Dokuments ermöglicht es, dass das Dokument korrekt gelesen werden kann, wenn es nicht von einem Server kommt. Das betrifft nicht nur statische Dokumente, die von CD oder Harddisk gelesen werden, sondern auch dynamische Dokumente, die vom Nutzer gespeichert wurden.

Eine Angabe innerhalb des Dokuments ist auch hilfreich für Entwickler, Tester oder Übersetzungs-Produktmanager, die die Zeichencodierung eines Dokuments visuell herausfinden möchten.

Für UTF-16-codierte Seiten siehe Verwendung von UTF-16.

Die XML-Deklaration

Die XML-Deklaration ist durch den XML-Standard definiert. Sie tritt am Anfang einer XML-Datei auf und ermöglicht eine encoding-Angabe. Zum Beispiel:

Eine XML-Deklaration ist für als XML verarbeitete Dokumente erforderlich, wenn die Zeichencodierung des Dokuments nicht UTF-8 oder UTF-16 ist und wenn die Zeichencodierung nicht durch ein Protokoll höherer Ebene (HTTP-Header) angegeben worden ist.

Das ist bedeutsam, denn wenn Sie die XML-Deklaration weglassen möchten, müssen Sie entweder UTF-8 oder UTF-16 als Zeichencodierung für die Seite wählen, wenn diese ohne HTTP verwendet werden soll.

Sie sollten eine XML-Deklaration zur Angabe der Zeichencodierung von als XML ausgelieferten XHTML-1.x-Dokumenten verwenden.

Es kann hilfreich sein, eine XML-Deklaration für als XML ausgelieferte Webseiten zu verwenden, selbst wenn die Zeichencodierung UTF-8 oder UTF-16 ist, denn eine solche Angabe innerhalb des Dokuments ist auch hilfreich für Entwickler, Tester oder Übersetzungs-Produktmanager, die die Zeichencodierung eines Dokuments visuell herausfinden möchten.

Andererseits könnte die Datei auch irgendwann als Eingabe für andere Prozesse dienen, die XML-Parser verwenden. Dazu gehören XML-Editoren, XSLT-Transformationen, AJAX usw. Außerdem wird mitunter serverseitige Logik eingesetzt um zu entscheiden, ob die Datei als HTML oder als XML ausgeliefert werden soll. Aus diesen Gründen sollten Sie, wenn Sie nicht UTF-8 oder UTF-16 verwenden, eine XML-Deklaration am Anfang des Markups einfügen, auch wenn die Datei als HTML zum Browser gesendet wird. Der Anfang einer Datei sieht dann folgendermaßen aus:

Wenn Sie UTF-8 oder UTF-16 verwenden, wird keine XML-Deklaration benötigt, zumal das meta-Element die visuelle Erkennung der Zeichencodierung für Menschen ermöglicht.

Rücksicht auf ältere Browser: Wenn irgendetwas vor der DOCTYPE-Angabe steht, wird die Seite im Internet Explorer 6 im Quirksmodus gerendert. Wenn Sie UTF-8 oder UTF-16 verwenden, können Sie die XML-Deklaration weglassen und haben keine Probleme.

Wenn Sie allerdings eine andere Zeichencodierung verwenden und die Nutzer des Internet Explorer 6 noch einen signifikanten Anteil Ihrer Leser ausmachen und wenn Ihr Dokument Konstrukte enthält, auf die sich der Unterschied zwischen Standardmodus und Quirksmodus auswirkt, dann könnten Sie ein Problem haben. Wenn Sie sicherstellen möchten, dass Ihre Seiten in allen standardkonformen Browsern gleich gerendert werden, müssen Sie Workarounds zu Ihrem CSS hinzufügen, um die Unterschiede auszugleichen.

Es könnten noch andere Darstellungsprobleme in Verbindung mit der XML-Deklaration auftreten, diese stellen allerdings nur bei sehr viel älteren Browsern ein Problem dar. Die XHTML-Spezifikation warnt, „dass Verarbeitungsanweisungen auf einigen Benutzerprogrammen dargestellt werden. Außerdem interpretieren einige Benutzerprogramme die XML-Deklaration so, als ob sie unbekanntes XML statt HTML vor sich hätten; und folglich stellen sie das Dokument nicht wie erwartet dar.“ Sie sollten auf entsprechenden Nutzerprogrammen testen, um zu entscheiden, ob das für Sie ein Problem ist.

Natürlich können Sie wie oben erwähnt die XML-Deklaration weglassen, wenn Sie UTF-8 oder UTF-16 verwenden. Die Datei kann dann immer noch als XML oder HTML verarbeitet werden. Das ist vermutlich die einfachste Lösung.

Verwendung von UTF-16

Nach einer Untersuchung von Google über mehreren Milliarden Webseiten sind weniger als 0,01% aller Seiten im Web in UTF-16 codiert. In den meisten Fällen wählt man besser UTF-8 als Zeichencodierung (was gemäß dieser Untersuchung mehr als 50% aller Webseiten tun). Ein Grund dafür ist, dass es spezielle Regeln zur Angabe der Zeichencodierung einer UTF-16-Seite gibt.

In diesem Artikel wird allgemein empfohlen, die Zeichencodierung innerhalb des Dokuments anzugeben, selbst wenn sie auch im HTTP-Header angegeben ist. Die HTML5-Spezifikation verbietet allerdings gegenwärtig die Verwendung des meta-charset-Attributs oder der Pragma-Direktive zur Angabe von UTF-16. Es ist eine Diskussion im Gang, ob das so sein muss; das kann sich noch ändern. Gegenwärtig sollte man, wenn valider HTML5-Code gewünscht ist, diese Angaben nicht für UTF-16-codierte Inhalte verwenden.

Ob Sie Element-basierte Angaben verwenden oder nicht, Sie sollten sicherstellen, dass Sie immer ein BOM (byte-order mark) ganz am Anfang einer UTF-16-codierten Datei zu stehen haben. Im Effekt ist dies die Angabe innerhalb des Dokuments.

Geben Sie für UTF-16-codierte Seiten nicht "UTF-16BE" oder "UTF-16LE" an, sondern verwenden Sie ausschließlich "UTF-16". Das BOM am Dateianfang zeigt an, ob das Codierungsschema little-endian oder big-endian ist. (Der Grund dafür ist, dass als UTF-16BE oder UTF-16LE gekennzeichneter Inhalt kein BOM haben darf; HTML5 für UTF-16-codierte Seiten aber ein BOM verlangt.)

Das charset-Attribut für einen Link

Die HTML-4.01-Spezifikation beschreibt ein charset-Attribut, das für a-, link- und script-Elemente verwendet werden kann und die Zeichencodierung des verlinkten Dokuments angeben soll.

Bei einem Link kann es folgendermaßen verwendet werden:

Man könnte es auch verwenden, um die Zeichencodierung eines CSS-Stylesheets anzugeben:

Die Idee ist, dass der Browser die richtige Zeichencodierung auf das empfangene Dokument anwenden kann, wenn nicht auf eine andere Art die Zeichencodierung für das Dokument angegeben wurde.

Die Verwendung dieses Attributs für a- und link-Elemente ist gegenwärtig von der HTML5-Spezifikation missbilligt. Sie sollten es bei diesen Elementen nicht einsetzen.

Es gibt auch einige Dinge zu bedenken, bevor man dieses Attribut verwendet. Erstens wird es von gängigen Browsern nicht gut unterstützt. Zweitens können Sie kaum sicherstellen, dass die Information stets korrekt ist. Der Autor des verlinkten Dokuments könnte die Zeichencodierung des Dokuments ändern, ohne dass Sie dies erfahren. Wenn der Autor dann immer noch nicht die Zeichencodierung seines Dokuments angibt, weisen Sie den Browser an, eine falsche Zeichencodierung anzuwenden. Und drittens ist dieses Attribut überhaupt nicht nötig, wenn die Ratschläge in diesem Tutorial befolgt werden und Dokumente entsprechend gekennzeichnet sind. Das ist die weitaus bessere Verfahrensweise.

Diese Art der Angabe der Zeichencodierung eines Dokuments hat die niedrigste Priorität (d.h. sie wird ignoriert, wenn die Zeichencodierung auf andere Art angegeben ist). Das bedeutet, dass man dies sowieso nicht dazu verwenden kann, falsche Angaben zu korrigieren.

Prioritätsregeln

Wenn sich mehrere Zeichencodierungs­angaben widersprechen, entscheiden die Prioritätsregeln, welche angewandt wird. In XHTML und HTML ist die Priorität wie folgt, mit 1 als höchster:

1. BOM (byte-order mark)
2. HTTP-Content-Type-Header
3. XML-Deklaration
4. meta-Element
5. link-charset-Attribut

Die hohe Priorität des HTTP-Headers ist wie bereits gesagt von Vorteil, wenn die Zeichencodierung des Dokuments durch einen zwischengeschalteten Server geändert wird, denn bei einer derartigen Umcodierung werden wahrscheinlich keine Angaben innerhalb des Dokuments geändert. Der umcodierende Server sollte allerdings die neue Zeichencodierung im HTTP-Header angeben.

Die HTML5-Spezifikation (die noch nicht endgültig ist) beschreibt formal die Priorität des BOM (byte-order mark). Gemäß dieser Spezifikation hat das BOM eine höhere Priorität als der HTTP-Content-Type-Header und als alles andere. Zum Zeitpunkt dieses Artikels war dies in den aktuellen Versionen der gängigen Browser noch nicht einheitlich implementiert. Für weitere Informationen siehe diese Testergebnisse.