Accesskey n springt zur Seitennavigation. Springe zum Inhalt.
Dieses Dokument ist eine Übersetzung. Im Falle von Abweichungen oder Fehlern sollte das aktuelle englische Original als maßgeblich angenommen werden. Das W3C besitzt das Copyright am Original, wie unten beschrieben.
Übersetzer: Gunnar Bittersmann
Zielgruppe: XHTML/HTML-Autoren (die Web-Editoren/Texteditoren oder Scripte benutzen), Script-Entwickler (PHP, JSP u.a.), CSS-Entwickler, Webprojekt-Manager und alle, die sich eine Einführung wünschen, wie die Zeichencodierung einer (X)HTML- oder CSS-Datei anzugeben ist
Wie muss man die Zeichencodierung einer HTML-Datei angeben?
Man sollte immer die für ein HTML- oder XML-Dokument verwendete Zeichencodierung angeben. Andernfalls riskiert man, 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. Sie sollten auch überprüfen, dass Sie nicht an verschiedenen Stellen verschiedene Zeichencodierungen angeben.
Dieser Artikel gibt einfache Ratschläge, wie man die benötigten Angaben erstellt. Er tut das auf zweierlei Art:
Wenn Sie besser verstehen möchten, was Zeichen und Zeichencodierungen sind, lesen Sie den Artikel Zeichencodierung für Anfänger. Für Informationen zur Angabe der Zeichencodierung für CSS-Stylesheets lesen Sie Angabe der Zeichencodierung in CSS.
Es folgt eine kurze Zusammenfassung von Informationen für diejenigen, die schnell wissen möchten, was sie tun müssen, mit minimalen Erläuterungen. Folgen Sie diesen Schritten:
Wenn Sie diese Zusammenfassung nicht verstehen oder wenn Sie die Gründe verstehen möchten, folgen Sie den Links zu nachfolgenden Abschnitten auf dieser Seite, wo Beispiele und Erklärungen gegeben werden.
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.
Setzen Sie in den folgenden Beispielen die jeweilige Zeichencodierung anstelle von "UTF-8" ein, wenn nicht anders angegeben.
| Format | Was Sie tun müssen |
|---|---|
| HTML5 |
Verwenden Sie das meta-charset-Attribut in einem meta-Element zu Beginn des head-Elements. Stellen Sie sicher, dass die gesamte Angabe innerhalb der ersten 1024 Bytes des Seitenquelltexts Platz findet.
|
| HTML5 mit UTF-16 |
Stellen Sie sicher, dass ein BOM (byte-order mark) am Anfang der Datei vorhanden ist. Die HTML-Arbeitsgruppe diskutiert gegenwärtig, ob man bei UTF-16 eine meta-Element-Angabe im head-Element verwenden kann. Zum jetzigen Zeitpunkt gilt: Verwenden Sie keine. |
| HTML4 |
Verwenden Sie eine Pragma-Direktive zu Beginn des head-Elements. <meta http-equiv="Content-type" content="text/html;charset=UTF-8"> |
| XHTML 1.x ausgeliefert mit Medientyp text/html |
Verwenden Sie UTF-8 als Zeichencodierung und verwenden Sie eine Pragma-Direktive zu Beginn des head-Elements.
(Wenn sie ein andere Zeichencodierung verwenden möchten, lesen Sie die detaillierteren Informationen weiter unten.) |
| 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).
|
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.
Es gibt verschiedene Alternativen zu den oben empfohlenen Ansätzen; diese haben Vor- und Nachteile. Folgen Sie diesen Links für weitere Details:
Nun folgen detailliertere Informationen zu den verschiedenen Möglichkeiten, die Zeichencodierung anzugeben, beginnend mit HTTP-Headern, dann eine Auflistung der verschiedenen Ansätze zur Angabe innerhalb des Dokuments für nicht in UTF-16 codierte Seiten. Für UTF-16-codierte Seiten gibt es einen speziellen Unterabschnitt.
Dieser Abschnitt beinhaltet:
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.:
<?php header('Content-type: text/html; charset=utf-8'); ?>
<!DOCTYPE html>
...
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:
AddType 'text/html; charset=UTF-8' html
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 Zeichencodierungsinformation leicht finden, wenn sie im HTTP-Header gesendet wird.
Nachteile
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 Harddisk 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.
(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.)
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:
<meta charset="UTF-8"> Die HTML5-Spezifikation verlangt, dass das gesamte meta-Element in den ersten 1024 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.
Das ist ein meta-Element, das so früh wie möglich zu Beginn des head-Elements stehen sollte und folgendermaßen aussieht:
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">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 Zeichencodierungsinformation 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 1024 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 ist durch den XML-Standard definiert. Sie tritt am Anfang einer XML-Datei auf und ermöglicht eine encoding-Angabe. Zum Beispiel:
<?xml version="1.0" encoding="UTF-8"?> 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.
Verwendung der XML-Deklaration bei als HTML ausgeliefertem XHTML: Als HTML ausgeliefertes XHTML wird als HTML geparst, obwohl es auf XML-Syntax basiert, und deshalb sollte eine XML-Deklaration vom Browser nicht beachtet werden. Aus diesem Grund sollten Sie eine Pragma-Direktive zur Angabe der Zeichencodierung verwenden, wenn Sie XHTML als HTML ausliefern.*
* Andersherum wird die Pragma-Direktive, obwohl valide, von XML-Parsern nicht als Zeichencodierungsangabe anerkannt.
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:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
<meta http-equiv="Content-type" content="text/html;charset=ISO-8859-1" />
... 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.
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.)
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:
Siehe <a href="/mysite/mydoc.html" charset="ISO-8859-1">Liste unserer Publikationen</a>. Man könnte es auch verwenden, um die Zeichencodierung eines CSS-Stylesheets anzugeben:
<link rel="stylesheet" charset="Windows-1251" href="mystyles.css" type="text/css"> 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.
Wenn sich mehrere Zeichencodierungsangaben widersprechen, entscheiden die Prioritätsregeln, welche angewandt wird. In XHTML und HTML ist die Priorität wie folgt, mit 1 als höchster:
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 niedrigere Priorität als der HTTP-Content-Type-Header, aber eine höhere Priorität 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.
Sagen Sie uns, was Sie denken (auf Englisch).
Abonnieren Sie unseren RSS-Feed.
Twitter (News auf der Startseite)
Übersetzung der englischen Version vom 2010-09-09. Letzte Änderung der übersetzten Version am 2011-08-17 14:52 GMT.
Suchen Sie nach qa-html-encoding-declarations im i18n-Blog, um alle Dokumentänderungen nachzuvollziehen.
Copyright © 2010-2011 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
Neue Ressourcen
@webi18n