nicht angemeldet
Hallo,
ich sehe dein spezielles Problem nicht. Die Frage wurde im Allgemeinen hier schon öfters diskutiert mit ähnlichen Ausgängen. Das Ergebnis ist meist der Rat, konsequent UTF-8 zu verwenden, sodass sich alle möglichen Kodierungsfragen überhaupt nicht stellen. Was spricht gegen diese Patentlösung?
sollte man lieber auf die XML-Deklaration verzichten (im Zweifelsfall kann man ja sein Dokument als UTF-8 schicken lassen und trotzdem nur ISO-konforme Zeichen nehmen..
Warum nicht UTF-8 auch ausreizen, wenn man es einsetzt? Es gibt Browser, die gewisse seltene Zeichen UTF-8-kodiert nicht verstehen, aber dieselben Zeichen z.B. als numerische Zeichenreferenzen?
ich bin nämlich der Meinung, dass IE7 leider trotz der vielen (lobenswerten) Verbesserungen, so auch der <?xml-Verbesserung, kann man auch in Zukunft nicht auf diesen Browser setzen
Ok. Das Aufkommen des IE 7 ändert tatsächlich erst einmal nichts an der Richtigkeit der besagten Standardlösung.
Was tun, sprach Zeus? Standardkonform arbeiten - oder Microsoft-konform?
Du kannst auch weiterhin ISO-8859-1-kodiertes XHTML verwenden und die Kodierung sowohl im HTTP-Header als auch in einem meta-Element angeben. Solange du das XHTML nur als text/html auslieferst, birgt das keine praktischen Probleme. Allerdings ist das Dokument dann für sich genommen fehlerhaftes XML. Das ist ein hypothetisches Problem, das real wird, wenn du autoren- oder serverseitig XML-Prozessoren verwendest und vor dem Parsen kein <?xml version="1.0" encoding="ISO-8859-1" ?> ins Dokument eingefügt hast. Genauso wird diese Vorgehensweise problematisch, wenn du das XHTML-Dokument irgendwann als application/xhtml+xml auslieferst. Denn z.B. Mozilla und Opera übernehmen die Kodierungsangabe im HTTP-Header nicht in eine XML-Deklaration, wenn das Dokument lokal gespeichert wird oder ähnliches. Dann gibt es irgendwann Zeichensalat.
Mathias