Hi,
Du musst dafür sorgen, dass die nachgeladenen Inhalte genauso codiert sind wie das Hauptdokument. Entweder du stellst sie generell auf UTF-8 um, oder du codierst im Javascript die empfangenen Daten um, bevor du sie ins DOM einfügst.
Ich habe es noch nicht ausprobiert, aber das scheint mir so nicht richtig zu sein. Nach meinem Überlegungen spielt doch die Zeichenkodierung nachdem der Browser ein Dokument gelesen hat keine Rolle mehr, weil er es für seine interne Verarbeitung sowieso in eine für ihn genehme Kodierung gebracht hat. Vermutlich wird das UTF-16 oder etwas ähnliches sein. Jedenfalls würde ich als Browser es als sehr ungünstig empfinden, zum Beispiel ein ISO-8859-1-Dokument mit jeder Menge NCRs oder Entitys drin in dieser Form zu belassen, um dann für alle Funktionen der Stringverarbeitung ständig umrechen zu müssen.
hmm, das hat was für sich ...
Die Lösung kann nach meinem Wissen und Verständnis nur sein: Korrekte Auszeichnung aller Ressourcen, sprich: Content-Type mit charset-Angabe, und die Ressourcen auch in dieser angegebenen Kodierung ausliefern.
Das klingt überzeugend. Dann ist es wohl eher so, dass Cano ein Dokument in irgendeiner ISO-Codierung nachlädt, der Server aber behauptet, es sei UTF-8.
Ciao,
Martin
Männer sind ungerecht: Sie sehen immer nur den Baum, den eine Frau mit dem Auto gerammt hat. Aber die vielen Bäume, die sie nicht einmal gestreift hat, sehen sie nicht.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(