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.