Um welche Seite geht es?
Es ist gar kein Fehler. Man kann nicht ein Text der in Kodierung foo kodiert ist mit Kodierung bar dekodieren.
Es ist kein Fehler wenn dieser Meta Tag fehlt im Zweifel vertraut ein vernünftiger Browser darauf sowieso nicht.
Entscheidend ist welche Kodierung der Server im HTTP Header angibt.
Zitat von ThundiX(Per Paste da es im Forum nicht angezeigt wird auch nicht mit Code)
Häkchen machen bei "HTML in diesem Beitrag deaktivieren".
Auch wenn für den Browser die Angabe des Http-Headers verbindlich sein sollte, ist es trotzdem eine gute Idee, das Charset im Meta-Tag anzugeben (bei Kodierungen, die bis einschließlich Code 127 identisch mit US-ASCII sind). Zumindestens, wenn man keine Kontrolle über den Server hat. Zum einen gibt es ein sicheres Fallback für Browser, wenn das Charset nicht im Http-Header übertragen wird. Zum anderen sollte ein Webserver eine Seite parsen, bevor er sie ausgibt. Mit der Meta-Angabe hätte er die Möglichkeit, das korrekte Charset zu ermitteln, anstatt irgendwelche Default-Einstellungen zu verwenden oder das Charset zu erraten, was beides zu Darstellungsfehlern führen kann.
Und nur so nebenbei - das Default-Charset sollte eh auf ISO 8859-1 bzw. 8859-15 stehen und nicht auf UTF8. Damit sollte man in der überwiegenden Zahl der Fälle eine korrekte Anzeige bekommen, wenn kein Charset übermittelt wird.
was meiner Meinung an diesem Code liegt:
http://paste2.org/p/179657
Wie DasIch schon schrieb, ist zunächst der HTTP-Header Content-Type dafür maßgeblich. Du kannst Erweiterungen wie HTTPFox oder Tamper Data verwenden, um dir diesen anzeigen zu lassen. Browserunabhängig geht das natürlich auch, bspw. mit Wireshark.
Die Angabe im HTTP-Header hat Priorität über eine Meta-Angabe im HTML-Head. Erst wenn erstere fehlt, ist letztere relevant.
So oder so liegt es im Verantwortungsbereich des Serverbertreibers/Webadmins, dem Browser die korrekte Kodierung mitzuteilen.
Zum anderen sollte ein Webserver eine Seite parsen, bevor er sie ausgibt.
Wäre eine Belastung der Ressourcen, vor allem auch unnötig, wenn eine Kodierung vorab durch die Konfiguration des Servers angegeben werden kann.
das Default-Charset sollte eh auf ISO 8859-1 bzw. 8859-15 stehen und nicht auf UTF8.
Hängt natürlich davon ab, auf welchen Seiten (auch Sprachräumen) man sich meist herum treibt.
Es geht beim Parsen ja nicht nur (bzw. nicht vorrangig) um das Charset. HTML ist eine SGML-Anwendung und deshalb dürfen HTML-Dokumente auch Verarbeitungsanweisungen enthalten, die vom Server beachtet werden müßten, wenn er sich SGML-konform verhält. Das zusätzliche Auslesen des Charsets wäre damit nicht wirklich eine Zusatzbelastung. Leider wird in der Praxis die SGML-Natur von HTML zumeist ignoriert.
http://www.edition-w3.de/TR/1999/REC-ht…form.html#h-4.2
http://www.edition-w3.de/TR/1999/REC-ht…ml#sgmlfeatures
und deshalb dürfen HTML-Dokumente auch Verarbeitungsanweisungen enthalten, die vom Server beachtet werden müßten
Das stimmt, wenn Web-Server SGML-konforme Systeme darstellen würden, allerdings haben diese den Anspruch nicht.
Aus http://www.w3.org/2007/03/HTML-WG-charter
The Group will define conformance and parsing requirements for 'classic HTML', taking into account legacy implementations; the Group will not assume that an SGML parser is used for 'classic HTML'.
Das W3C scheint selbst schon die Hoffnung aufgegeben zu haben, dass sich Web-Server zu solchen Systemen entwickeln. In der Hinsicht ist auch die Abwendung von SGML bei HTML5 zu verstehen.
Grundsätzlich wäre es allerdings trotzdem ein gewisser Performance-Verlust (Im Vergleich zu nicht SGML-konformen Web-Servern), da ein SGML-konformer Webserver die Dokumente parsen und nicht nur ausliefern müsste.
Darüber hinaus sehe ich keine entscheidenden Vorteile durch einen SGML-Parser, jedenfalls keine die nicht durch andere Webserver-Anwendungen realisiert werden können.
Zitat von boardraider
Wie DasIch schon schrieb, ist zunächst der HTTP-Header Content-Type dafür maßgeblich. Du kannst Erweiterungen wie HTTPFox oder Tamper Data verwenden, um dir diesen anzeigen zu lassen. Browserunabhängig geht das natürlich auch, bspw. mit Wireshark.Die Angabe im HTTP-Header hat Priorität über eine Meta-Angabe im HTML-Head. Erst wenn erstere fehlt, ist letztere relevant.
So oder so liegt es im Verantwortungsbereich des Serverbertreibers/Webadmins, dem Browser die korrekte Kodierung mitzuteilen.
Und wo kann ich mir da angucken was der Server mitgesendet hat?
Bei Request Header steht UTF-8 ist es da?
Jedoch wird die Seite ja mit UTF-8 falsch angezeigt auf ein paar
Seiten.
Hängt vom Tool ab, mit dem du es versuchst. Request ist die Anfrage des Browsers, Response die Antwort des Servers.
Zitat von ThundiXHier ist noch so eine Seite, habt ihr da auch Fehler?
http://tinyurl.com/dn6f5r[Blockierte Grafik: http://www.abload.de/thumb/pic090ts9j.png]
Ja. Zeichenkodierung manuell auf ISO-8859-1 stellen und es sieht OK aus.
Bei mir sieht die Zeichenkodierung so aus:
[Blockierte Grafik: http://s10b.directupload.net/images/090217/temp/cdmyq5ho.png]
Unter Extras - Einstellungen - Inhalt - Schriftarten - Erweitert sieht es so aus:
[Blockierte Grafik: http://s4b.directupload.net/images/090217/temp/f7era5h6.png]
Damit wird die Seite http://tinyurl.com/dn6f5r bei mir korrekt angezeigt.
Ob es ein Fehler Deinerseits war, kann ich nicht beurteilen. ich kann nur sagen, dass ich in einem neu installierten Firefox 3.0.8 die obigen Einstellungen standardmässig vorgefunden habe und die Seite damit korrekt angezeigt wurde.
Ich möchte mal ThundiX von einem Fehler freisprechen.
Wie bei den meisten Problemen mit der Zeichenkodierung ist der Schuldige am anderen Ende der Leitung zu finden, so auch hier, da weder der Server noch der Inhalt der Seite eine Angabe dazu liefert.
Im Regelfall greift dann "Extras -> Einstellungen -> Inhalt -> Schriftarten -> Erweitert" - aber nicht immer.
Experiment:
a.) man stelle sicher, unter "Extras -> Einstellungen -> Inhalt -> Schriftarten -> Erweitert" stehe Westlich (ISO-8859-1)
b.) man rufe die Seite http://www.dentes-zahn.de/Zahntechnik-10/bruecken.html auf und stelle unter "Ansicht -> Zeichenkodierung -> Unicode (UTF-8)" ein. Mit dem Ergebnis
[Blockierte Grafik: http://img3.imagebanana.com/img/qfle0m80/thumb/DentesZahntechnikGmbHBrcken.png]
c.) man beende den FF ohne Löschung der History
d.) man starte den FF und rufe wieder obige Seite auf. Die Seite wird identisch falsch dargestellt und die Probe unter "Ansicht -> Zeichenkodierung" zeigt wieder "Unicode (UTF-8)"
An dieser Stelle schlägt der moderne FF 3.x mit seinem Komfort zu. Wie den benutzten Zoom einer Seite merkt er sich auch die benutzte Zeichenkodierung in der places.sqlite, siehe Spalte "content"
Der Inhalt von "content" wird aber nur benutzt, wenn weder der Server noch die Seite eine Angabe zur Zeichenkodierung liefern - was ja hier gegeben war.
P.S. einen Versuch mit einer Seite dieses Forums kann man sich aus bekannten Gründen sparen.
