Hallo Thomas,
Beispielsweise ein XHTML-Dokument mit Kodierungsangabe in der XML-Deklaration als .xhtml über das lokale Dateisystem:
http://home.t-online.de/home/dj5nu/fanhost/xhtml1.pngOhne XHTML-Deklaration:
http://home.t-online.de/home/dj5nu/fanhost/xhtml2.pngDas verstehe ich jetzt nicht.
Ich habe jetzt mit Firebirds und Opera getestet (beide Dokumente sind XHTML Doks):
Ohne XML-Deklaration/encoding-Attribut und ohne Kodierungsangabe via meta-Element? Mein Testdokument sieht so aus:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="de" xml:lang="de">
<head>
<title>Testdokument</title>
</head>
<body>
<p>Dies ist ein XHTML-Dokument mit Zeichen aus<br />dem 8-Bit-Bereich von ISO-8859-1 kodiert in ISO-8859-1.</p>
<p>¡¢£€¥Š§š©ª«¬®¯°±²³Žµ¶·ž¹º»ŒœŸ¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐ<br />ÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ</p>
</body>
</html>
(Die Zeichen werden wahrscheinlich nicht alle übertragen, es sind wie gesagt die 8-Bit-Zeichen von ISO-8859-1.)
Das Dokument wird ohne charset-Angabe im Content-Type-Header ausgeliefert (mir ging es aber im Grunde genommen nur um Dokumente außerhalb des HTTP-Kontexts und somit um die XML-Deklaration).
Beide zeigten mir beide Seiten identisch an (auch ohne charset durch HTTP, bzw. auch über das lokale System (ich habe extra für .xhtml das jetzt auf application/xhtml+xml umgestellt)
Gecko (hier unter Windows) rät bei fehlenden Angaben die Kodierung. Dabei kommt bei Hinweisen auf ISO-8859-1 Windows-1252 heraus, und UTF-8 erkennt er auch als solches. Das ist meines Wissens lediglich Fehlertoleranz und ignoriert im Falle von XHTML als application/xhtml+xml/.xhtml XML-Regeln.
Opera 7.20 rät meinen Tests zufolge bei XHTML nicht. Wenn ein XHTML-Dokument als application/xhtml+xml ausgeliefert wird bzw. als solches lokal aufgerufen wird und keine Kodierung (HTTP-Header oder XML-Deklaration) angegeben ist, nimmt Opera immer als Fallback UTF-8 an. Dadurch entsteht das genannte Zeichenchaos, wenn das Dokument eine andere Kodierung verwendet. In den Fällen ist in der Hotlist-Karteikarte Info zu lesen:
Encoding from server (used by Opera):
- not supplied - (utf-8)
(Unter »Encoding from server« steht die irgendwo angegebenen Kodierung [auch meta-Element und XML-Deklaration], damit ist nicht zwangsläufig HTTP gemeint, eine Byte Order Mark wird bspw. auch als Indikator genutzt.)
Wenn allerdings ein meta-Element mit Kodierung existiert, wird diese verwendet - was nach XML-Regeln kompletter Unsinn ist, aber im Hinblick auf das Ausgangsproblem zu begrüßen ist... Denn ein meta-Element ist unproblematisch. Nur ist wie gesagt das Ratespiel genauso wenig verlässlich wie dieser Workaround auf andere Browser übertragbar.
Erst wenn ich dies explizit im Browser verändert habe, kamen die kleinen Kästchen/ Fragezeichen: beide zeigten in diesem Fall (encoding des Browser auf UTF-8 umgestellt) Kästchen/ Fragezeichen mit _und_ ohne die XML-Deklaration im Dokument.
Das sowohl über das lokale System als auch über HTTP.
Bei Gecko ist das wie gesagt über die automatische Erkennung erklärbar, beim Opera teile ich im Falle von »echtem« XHTML deine Beobachtung nicht, kann es mir nur durch ein eventuell vorhandenes meta-Element erklären; oder du verwendest eine andere Opera-Version.
(übrigens beide zeigten sowohl das xhtml als auch das html Dokument ohne die XML-Dekl. auch mit US-ASCII als Encoding richtig an)
Diesen Satz verstehe ich nicht. Falls du meinst, trotz US-ASCII-Kodierungsangabe über HTTP/XML-Deklaration/meta-Element die 8-Bit-Zeichen trotzdem gemäß Windows-1252 umgesetzt werden: das stimmt. Falls du meinst, dass Opera Windows-1252 letztlich verwendet, wenn man die Kodierung manuell auf US-ASCII stellt: das stimmt auch.
Mathias