falsche Zeichenkodierung?
0 
Matthias Apsel
0 
Der Martin
0 
dedlfix
0 Der Martin
0 dedlfix
falsche Zeichenkodierung?
Hallo!
Ich habe das Problem, dass ich per ajax eine .html Datei in ein Div hole. Umlaute werden als
Fragezeichen dargestellt.
Was kann ich da machen, bzw. ich muss doch einen ContentType definieren. Die Frage ist welche und wo?
Danke für Antworten im voraus!
-
Om nah hoo pez nyeetz, Cano!
das Studium der Artikel Kontextwechsel und die Fortsetzung Kontextwechsel erkennen und behandeln sollte hilfreich sein.
Matthias
--
1/z ist kein Blatt Papier.
-
Hi,
Ich habe das Problem, dass ich per ajax eine .html Datei in ein Div hole. Umlaute werden als Fragezeichen dargestellt.
dann ist vermutlich das äußere Dokument in UTF-8 codiert, der nachdeladene Teil aber in einer anderen Codierung, möglicherweise ISO-8859-1.
Was kann ich da machen, bzw. ich muss doch einen ContentType definieren. Die Frage ist welche und wo?
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.
Ciao,
Martin--
Datenbanken speichern keine User.
Das liegt daran, daß Datenbanken mit der Lebensmittelversorgung für gespeicherte biologische Lebensformen derzeit noch Probleme haben.
(Christoph Schnauß)
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Tach!
Ich habe das Problem, dass ich per ajax eine .html Datei in ein Div hole. Umlaute werden als Fragezeichen dargestellt.
dann ist vermutlich das äußere Dokument in UTF-8 codiert, der nachdeladene Teil aber in einer anderen Codierung, möglicherweise ISO-8859-1.
Was kann ich da machen, bzw. ich muss doch einen ContentType definieren. Die Frage ist welche und wo?
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.
Auch kann es nicht angehen, dass sämtliche nachzuladende Ressourcen immer der Kodierung des Hauptdokuments entsprechen müssen, schließlich kann jede Ressource ja ihre eigene charset-Angabe im Content-Type-Header haben. Die soll dann nicht mehr gelten, wenn das Dokument von anderwo referenziert ist? Und was sollte geschehen, wenn ein Dokument von zwei anderen mit unterschiedlicher Kodierung nachgeladen wird? Nein, das kann es nicht sein, und das kann auch nicht anders sein, wenn man ein Dokument mit Ajax nachlädt. Das wäre nicht sehr sinnvoll.
Umkodieren in Javascript ist nicht vorgesehen, weil Javascript nicht mit Kodierungen in Berührung kommt. Es arbeitet nur mit Zeichen. Es ist keine Möglichkeit vorgesehen, mit Bytes zu arbeiten, was eine Umkodierung, vielleicht nicht unmöglich macht, aber doch sehr erschwert.
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.
dedlfix.
-
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:(-
Tach!
Jetzt hab ich doch mal einen kleinen Test aufgesetzt (mit Firefox).
- Dokument A, UTF-8, lädt per jQuerys .load() B nach, das angibt, es sei ISO-8859-1 stattdessen aber UTF-8 kodiert ist: Ä statt Ä
- B umkodieren nach ISO-8859-1: perfektes Ä
- charset auf UTF-8 ändern: �
- umkodieren nach UTF-8: wieder perfektes Ä
- B sendet keine charset-Angabe und ISO-8859-1: �
- umkodieren nach UTF-8: wieder perfektes Ä
Dasselbe Versuchsergebnis ergibt sich, wenn das A-Dokument ISO-8859-1-kodiert ist (und es so angibt). Im Browser selbst ist keine Kodierung festgetackert. Das heißt, dass die Zeichenkodierung des einbindenden Dokuments, wie angenommen, keine Rolle spielt, und jede Ressource ihre eigene Zeichenkodierung richtig angeben muss.
Dann ist es wohl eher so, dass Cano ein Dokument in irgendeiner ISO-Codierung nachlädt, der Server aber behauptet, es sei UTF-8.
Nach den Indizien zu urteilen, ist das ein mögliches Szenario. Aber auch wenn keine Kodierung angegeben ist, muss sich dieses Bild ergeben, denn (meines Wissens) geht Ajax per Default immer von UTF-8 aus.
Die Frage ist auch noch, ob er mit "Fragezeichen" wirklich ein ? meinte oder das �. Ein ? kommt nach meiner Erfahrung nur dann vor, wenn ein Zeichen, das in ISO-8859-1 nicht enthalten ist, in diese Kodierung gebracht werden soll. Für ungültige UTF-8-Sequenzen gibt es ja das Spezialzeichen �. Ein Äquivalent gibt es jedoch in ISO-8859-1 nicht, weswegen man da mit einem einfachen ? vorliebnehmen muss. Wenn er also ein ? sieht, kann die Ursache auch noch ganz woanders vesteckt sein.
dedlfix.
-
Hallo,
es ist so, dass ich � sehe!
Ich werde mal eure Tipps im Laufe des Tages ausprobieren. Danke.
-
-
-