Wie sollte man die Zeichencodierung einer HTML-Datei angeben?
Sie sollten immer die für ein HTML- oder XML-Dokument verwendete Zeichencodierung angeben. Andernfalls riskieren Sie, dass Zeichen im Inhalt nicht korrekt interpretiert werden. Das betrifft nicht nur die Lesbarkeit für Menschen, in zunehmendem Maße müssen auch Maschinen Ihre Daten verstehen können. Die Angabe der Zeichencodierung wird auch benötigt, um Nicht-ASCII-Zeichen verarbeiten zu können, die von Nutzern in Formulare eingegeben werden oder die in durch Scripte generierten URLs auftreten usw. Dieser Artikel beschreibt, wie Sie das für HTML-Dateien umsetzen.
Geben Sie immer die Zeichencodierung Ihrer Dokumente mittels meta-Element an – entweder mit charset-Attribut oder mit http-equiv- und content-Attributen (der sogenannten Pragma-Direktive). Die Angabe der Zeichencodierung sollte in den ersten 1024 Bytes des Dokuments Platz finden. Setzen Sie diese also am besten gleich hinter das Start-Tag des head-Elements.
Es macht keinen Unterschied, welches Sie verwenden, das erste ist jedoch einfacher einzugeben. Es macht auch keinen Unterschied, ob Sie UTF-8 oder utf-8 schreiben.
Sie sollten immer UTF-8 als Zeichencodierung verwenden. (Das heißt, der Inhalt muss auch wirklich als UTF-8 gespeichert werden.) Beachten Sie, was Sie bedenken müssen, wenn Sie wirklich nicht UTF-8 verwenden können.
Wenn Sie Zugang zu den Servereinstellungen haben, sollten Sie auch bedenken, ob es sinnvoll ist, die Zeichencodierung im HTTP-Header anzugeben. Beachten Sie aber, dass der HTTP-Header höhere Priorität hat als meta-Angaben im Dokument und Autoren deshalb immer berücksichtigen müssen, ob die Zeichencodierung bereits im HTTP-Header angegeben ist. Wenn das der Fall ist, dann muss das meta-Element dieselbe Codierung angeben.
Wenn ein UTF-8-BOM (byte-order mark) am Dateianfang steht, erkennen gängige Browser außer Internet Explorer 10 und 11, dass die Seite in UTF-8 codiert ist. Das BOM hat höhere Priorität als jede andere Angabe, auch als der HTTP-Header.
Man könnte auf die meta-Angabe zur Zeichencodierung verzichten, wenn ein BOM vorhanden ist. Wir empfehlen aber, eine zu verwenden, denn sie hilft denen, die sich den Quelltext ansehen, die Zeichencodierung der Seite zu erkennen.
Sollte man die Zeichencodierung im HTTP-Header angeben?
Verwenden Sie Angaben zur Zeichencodierung in HTTP-Headern für alle Inhaltstypen, für die das sinnvoll ist und für die Sie dazu in der Lage sind, aber in Verbindung mit einer Angabe im Dokument.
Stellen Sie immer sicher, dass die HTTP-Angaben mit den Angaben im Dokument übereinstimmen.
Für und Wider der Angabe im HTTP-Header
Ein Vorteil der Angabe im HTTP-Header ist, dass Nutzerprogramme die Zeichencodierungsinformation früher finden können, wenn sie im HTTP-Header gesendet wird.
Andererseits bringt das eventuell Nachteile mit sich:
Für Inhaltsautoren kann es schwierig sein, die Zeichencodierungsinformation 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 Festplatte gespeichert sind. In diesen Fällen gibt es gar keine Zeichencodierungsinformation 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 Zeichencodierungsinformation immer auch zusätzlich innerhalb des Dokuments anzugeben. Eine Angabe innerhalb des Dokuments ist auch hilfreich für Entwickler, Tester und Übersetzunsprozessmanager, die die Zeichencodierung eines Dokuments visuell prüfen möchten.
(Manche vertreten die Auffassung, dass es wenig 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.)
Polyglottes HTML und XML-Formate
XHTML5: Ein XHTML5-Dokument wird als XML ausgeliefert und verwendet XML-Syntax. XML-Parser beachten nicht die Zeichencodierungsangabe in meta-Elementen. Sie beachten nur die XML-Deklaration. Hier ein Beispiel:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html ....
Die XML-Deklaration ist nur erforderlich, wenn die Seite nicht in UTF-8 (oder UTF-16) codiert ist. Sie dennoch zu verwenden ist allerdings hilfreich für Entwickler, Tester und Übersetzunsprozessmanager, die die Zeichencodierung eines Dokuments visuell prüfen möchten, wenn sie sich den Quelltext ansehen.
Polyglottes Markup: Eine Seite in polyglottem Markup verwendet eine Untermenge von HTML in XML-Syntax. Sie kann sowohl von einem HTML-Parser als auch einem XML-Parser verarbeitet werden. Das wird in Polyglot Markup: A robust profile of the HTML5 vocabulary beschrieben.
Weil polyglottes Markup in UTF-8 codiert sein muss, müssen Sie keine und dürfen Sie auch keine XML-Deklaration verwenden. Wenn die Datei andererseits als HTML verarbeitet werden soll, müssen Sie die Zeichencodierung per meta-Element, BOM oder HTTP-Header angeben.
Da die Angabe mittels meta-Element nur von HTML-Parsern beachtet wird, sollte, wenn Sie den Weg mit content-Attribut gehen, dessen Wert mit text/html; beginnen.
Wenn Sie ein meta-Element mit charset-Attribut verwenden, müssen Sie hier nichts bedenken.
Weitere Informationen
Dieser Abschnitt enthält Feinheiten, die Sie nicht unbedingt wissen müssen, die aber der Vollständigkeit halber hier erwähnt sind.
Andere Zeichencodierungen als UTF-8
Die Verwendung von UTF-8 macht nicht nur die Erstellung von Seiten einfacher, damit verhindert man auch unerwartete Resultate bei der Übertragung von Formularen und bei der Codierung von URLs, wo auch die Zeichencodierung des Dokuments als Grundlage verwendet wird. Wenn Sie es wirklich nicht vermeiden können, eine andere Codierung als UTF-8 zu verwenden, müssen Sie einen aus einer begrenzten Menge von Bezeichnern für Zeichencodierungen wählen, um maximale Interoperabilität und zukünftige Lesbarkeit Ihrer Inhalte zu gewährleisten.
Bis vor Kurzem war das IANA-Register das Nachschlagewerk für Bezeichner von Zeichencodierungen. Das IANA-Register enthält oft mehrere Bezeichner für dieselbe Codierung. In diesen Fällen sollten Sie den als „preferred“ (bevorzugt) gekennzeichneten Bezeichner verwenden.
Die neue Spezifikation Encoding enthält eine Liste, die gegen aktuelle Browserimplementierungen getestet wurde. Sie finden Sie in der Tabelle im Abschnitt Encodings. Am besten verwenden Sie die Bezeichner in der linken Spalte dieser Tabelle.
Beachten Sie: Wenn ein Bezeichner in einer dieser Quellen vorkommt, bedeutet das nicht automatisch, dass es gut wäre, diese Codierung zu verwenden. Einige der Codierungen sind problematisch. Wenn Sie wirklich nicht UTF-8 verwenden können, beachten Sie die Ratschläge im Artikel Eine Zeichencodierung wählen und anwenden.
Entwerfen Sie keine eigenen Bezeichner für Zeichencodierungen mit vorangestelltem x-! Das wäre eine schlechte Idee, denn es schränkt die Interoperabilität ein.
Ältere HTML-Formate
HTML 4.01 spezifiziert kein charset-Attribut für das meta-Element, doch jeder gängige Browser erkennt es und wendet es an, auch wenn die Seite als HTML4 und nicht als HTML5 deklariert ist. Dieser Abschnitt ist nur relevant, wenn Sie aus anderen Gründen als die Auslieferung an Browser an eine ältere HTML-Version gebunden sind. Er beschreibt Abweichungen vom Abschnitt Details weiter oben.
HTML4: Wie eben gesagt, müssen Sie die Pragma-Direktive statt des charset-Attributs verwenden, um konform mit HTML 4.01 zu sein.
XHTML 1.x ausgeliefert text/html: Auch hier müssen Sie die Pragma-Direktive statt des charset-Attributs verwenden, um konform mit HTML 4.01 zu sein. Sie müssen keine XML-Deklaration verwenden, denn die Datei wird als HTML verarbeitet.
XHTML 1.x ausgeliefert als XML: Verwenden Sie die encoding-Angabe in der XML-Deklaration in der ersten Zeile des Seitenquelltexts. Stellen Sie sicher, dass nichts davor steht, auch keine Leerzeichen. (Ein BOM (byte-order mark) ist aber OK.)
Das charset-Attribut für einen Link
HTML5 missbilligt die Verwendung des charset-Attributs für a- und link-Elemente; Sie sollten es nicht einsetzen. Es war in der HTML-4.01-Spezifikation für a-, link- und script-Elemente vorgesehen und sollte die Zeichencodierung des verlinkten Dokuments angeben.
Es war für Links folgendermaßen gedacht:
Achtung! Diesen Code nicht verwenden!
Siehe unsere <a href="/mysite/mydoc.html" charset="iso-8859-15">Liste der Publikationen</a>.
Die Idee war, 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 war schon immer problematisch. Erstens wird es von gängigen Browsern nicht gut unterstützt. Es gibt einen Grund, dieses Attribut nicht zu unterstützen: Wenn Browser dies ohne zusätzliche Regeln täten, wäre das ein Angriffspunkt für XSS-Attacken. 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.
Verwendung von UTF-16
Nach einer Untersuchung von Google über mehrere Milliarden Webseiten sind weniger als 0,01% aller Seiten im Web in UTF-16 codiert. UTF-8 macht über 80% aller Webseiten aus, wenn man ASCII als Untermenge mitzählt, sonst über 60%. Es wird dringend davon abgeraten, UTF-16 als Codierung für Ihre Seiten zu verwenden.
Wenn Sie aus irgendeinem Grund keine andere Wahl haben, hier einige Regeln, wie diese Codierung anzugeben ist. Sie unterscheiden sich von denen für andere Codierungen.
Die HTML5-Spezifikation verbietet die Verwendung des meta-Element zur Angabe von UTF-16, denn die Werte müssen ASCII-kompatibel sein. Stattdessen sollten Sie 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.)
Achtung! Diesen Code nicht verwenden!