nicht angemeldet
Hallo,
Verzeihung übrigens, dass ich damals auf deine Mail nicht geantwortet hatte -- ich war erst einige Zeit offline und habe dann keine Muße gefunden. Du kannst mir den aktuell gebrauchten Algorithmus aber gerne noch einmal zuschicken, falls dich meine Meinung noch interessiert.
- Wenn ein Dokument z.B. in UTF-16 mit Byte order Mark (BOM) kodiert ist, was bei HTML durchaus erlaubt ist, hat dann die BOM-Kodierung Vorrang vor der Meta-Angabe, oder sogar vor der Angabe des HTTP-Header (eher Unwahrscheinlich, wäre aber praktikabel)?
Da gibt es meines Wissens keine Vorschrift. Ich würde dem gesunden Menschenverstand nach urteilen: Manche Browser beachten die Meta-Angabe, für andere geht das BOM über alles. Sich widersprechende Kodierungsangaben sind also in der Praxis problematisch. Ich würde eine Fehlermeldung ausgeben oder UTF-16 benutzen, aber eine dicke Warnung ausgeben.
- Die Spezifikation lässt einen im Unklaren, welche Zeichensatzkodierung zu benutzen ist wenn überhaupt keine diesbezüglichen Informationen geliefert werden (kein HTTP-Charset, kein BOM, kein Meta-Charset). Dort steht das in solchen Fällen RFC2616 zu ignorieren ist (welches für solche Fälle ISO-8859-1 vorsieht) und kein Standardwert angenommen werden soll. Wenn dem so ist, müsste dann ein Fehler gemeldet werden?!
Ja, das ist richtig.
Ein HTML-Dokument, das weder eine eingebundene Kodierungsangabe hat, noch eine Kodierungsangabe durch das darüberliegende Protokoll (z.B. HTTP) übermittelt wurde, ist nicht standardkonform.
Darüber hinaus ist die Regelung »eine Kodierungsangabe im Übertragungsprotokoll reicht« meiner Meinung nach wenig sinnvoll. Wenn der Anwender das Dokument lokal speichert oder weiterverschickt oder durch ein anderes Protokoll als vorgesehen bezieht, muss der Browser wieder raten. Denn nicht alle Browser sind so klug, die Kodierungsangabe aus dem HTTP-Header beim Speichern eines Dokuments in ein meta-Element zu schreiben. Sprich, ich schlage vor, bei einer im Dokument selbst fehlenden Kodierungsangabe einen Hinweis auszugeben.
Der W3C-Validator führt in solchen Fällen einen Fallback zu US-ASCII durch, was sicherlich falsch sein dürfte (Validome momentan ISO-8859-1).
Wie geht man in solchen Fällen korrekt vor?
Korrekt zu den Standards eben: Wie du sagst, *kein* Fallback, sondern die Validierung abbrechen und eine Meldung ausgeben, dass eine Kodierungsangabe nicht nur in der Theorie, sondern auch in der Praxis unbedingt erforderlich bzw. ratsam ist.
Oder eben ein Fallback zu Latin1 (dies kann man schwach über RFC 2616 rechtfertigen, auch wenn diese Regelung es für HTML außer Kraft gesetzt ist) mit einer dicken Warnung, wie es meines Wissens der W3C-Validator auch macht (im Sinne von: »ja, dieses Dokument entspricht zwar der DTD, aber hat trotzdem andere schwere Fehler, denn wir haben einfach einmal irgendeine Kodierung verwendet«).
Und dann habe ich noch Klärungsbedarf bei XML/XHTMLhttp://edition-w3c.de/TR/2000/REC-xml-20001006/#sec-guessing:
- Wie ist zu Verfahren wenn z.B. der Byte order Mark UTF-8 "sagt", aber das binäre Muster (automatische Erkennung) UTF-16?
a) F.1 des Anhangs empfiehlt, dass UTF-8 anzunehmen ist, sobald ein so kodiertes BOM auftritt.
b) Wenn UTF-16 verwendet wird, muss ein entsprechendes BOM verwendet werden (das ist allerdings normativ). Wenn kein UTF-16-kodiertes BOM vorkommt, dann ist es definitionsgemäß kein UTF-16.
c) Wenn trotzdem offenbar UTF-16-kodierte Zeichen in einer als UTF-8 ausgezeichneten XML-Datei vorkommen, so ist es keine gültige XML-Datei. Denn die ganzen Null-Bytes von UTF-16 verweisen in UTF-8 auf U+0000, das in einem XML-Dokument nicht erlaubt ist.
d) Ein »ä« beispielsweise ist in UTF-16 11100100 00000000, das ist in UTF-8 meines Wissens notwendigerweise illegal, weil 1110xxxxx zwei Folgebytes nach sich zieht, die mit 10 beginnen müssen. Sprich: Wie kann man UTF-16 überhaupt als UTF-8 verarbeiten? Soweit ich es sehe gar nicht, also versteht es sich von selbst, dass der Parser abbrechen muss und einen Fatal Error zurückgeben muss.
- Was muss passieren wenn in der XML-Deklaration ein anderer Zeichensatz steht als im BOM/automatische Erkennung/HTTP-Header?
Gute Frage, dazu finde ich auch keine ausdrückliche Aussage. Aber zum BOM:
»In den (...) Fällen, [sinngemäß: in denen eine BOM für UCS-4, UTF-8 oder UTF-16 vorhanden ist], verlangt Abschnitt 4.3.3 (...), dass die Kodierungsdeklaration, falls vorhanden, gelesen wird und dass geprüft wird, dass der Kodierungsname mit der tatsächlichen Kodierung des Entity übereinstimmt.«
Sprich: Wenn ein BOM gefunden wird, schaue nach einer Kodierungsdeklaration direkt dahinter. Überprüfe, ob die Kodierung, die das BOM anzeigt, mit der Kodierung, die die XML-Deklaration möglicherweise anzeigt, identisch ist. In Abschnitt 4.3.3 finde ich nun keine eindeutige Aussage: Wenn Sie nicht identisch sind, dann breche das Parsen ab. Dies halte ich aber für einzig sinnvoll, da das BOM den Ton angibt.
Im Grunde reduzieren sich meine Fragen auf die Prioritätenreihenfolge der möglichen Zeichensatzkodierungen (HTTP/BOM/automatische Erkennung/XML-Deklaration/Meta-Tag) in Abhängigkeit zu HTML oder XML/XHTML, und die zu verwendende Zeichensatzkodierung wenn überhaupt keine Deklariert wurde.
Ich sehe da ehrlich gesagt keine große Schwierigkeit, weil ich, sobald ein offensichtlicher Widerspruch festgestellt wird, sofort eine Fehlermeldung ausgeben würde. D.h. wenn z.B. der Content-Type eine Kodierung behauptet, die dem BOM widerspricht, liegt ein Fehler vor, wenngleich empfohlen wird, das BOM zu beachten. Oder wenn der Content-Type der Meta-Angabe widerspricht, dann ist der Server falsch konfiguriert, wenngleich feststeht, dass die Kodierungsangabe im der Content-Type ausschlaggebend ist.
Mathias