Problem: Session Sprachcodierung mit GoogleChrome

[Schumiel]

Hallo,

und zwar übergebe ich eine GET-Variable in eine Session. Nachdem ich die Session nach ein Reload der URL aktiv nutze, macht er z.B. aus einem "ü" -> "ü". Alle Browser haben damit keine Probleme, sondern nur GoogleChrome.

Eine Sprachcodierung ist auf meiner Webseite eingebaut:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

Weiß jemand rat?

 

[Eagle-PsyX-]

Hi,

vermutlich hat das Dokument (der Quelltext) eine andere Kodierung. Auch die Datei die geöffnet wird, sollte eine ähnlich, oder die gleiche Kodierung aufweisen.
Zum Beispiel, wenn ich ein Dokument in UTF-8 abspeichere, aber mit "ISO-8859-1" ausführe, kommt so ein Fehler zustande.Doch wenn das Dokument in ANSI gespeichert ist, funktioniert alles wunderbar.
-Könntest du uns einen Link zu der Seite schicken?

P.S.: Mit Notepad++ kannst du erfahren was für eine Kodierung der Text hat, und auch umkodieren lassen.

Edit: Ahja, der PHP-Header sollte auch einheitlich sein. Wenn es sich um eine Datenbankabfrage handelt ebenfalls (wobei ich glaub das ISO Standard ist); auch die Koallition dürfte dabei eine Rolle spielen...

 

[Gumbo]

Doch wenn das Dokument in ANSI gespeichert ist, funktioniert alles wunderbar.

ANSI ist das American National Standards Institute, was in seiner Bedeutung mit dem Deutsche Institut für Normung e. V. (DIN) zu vergleichen ist.
Du meinst also wohl eher ASCII, eine vom ANSI spezifizierte Zeichenkodierung, was in diesem Fall aber ebenfalls falsch ist, da der ASCII-Zeichensatz das „ü“-Zeichen nicht enthält und es somit auch nicht kodiert werden kann.

 

[Eagle-PsyX-]

Okay, stimmt. Dann würd ich gern wissen, welche Kodierung Windows verwendet wenn er Dokument als "ANSI" speichert. Immerhin enthalten die Umlaute.

Was ich aber damit sagen will, ist das alle Komponente ( wie {X}HTML Meta, PHP-Header, Quelltextkodierung, Datenbank Koallition und Datenbank-Abfragen ) entsprechend gleich kodiert sein sollten, um solche Fehler vollkommen auszuschließen.
Da es nicht bei jeder Seite mit Google Chrome zu diesem "Bug" (bzw. Fehler-Intolleranz des Browser [nehm ich an] } kommt, ist doch wahrscheinlich ein Fehler auf der Seite.

P.S.: Habt ihr gewusst, dass es mehrdimensionale Sessions gibt? Hab ich grad rausgefunden {probiert} ist ja genial! ...

 

[Schumiel]

Hm, die Daten kommen aus einer Datenbank, die utf-8 hat. Wird das also die Ursache sein? Wenn ja, wie lös ich da nun mein Problem?

 

[Gumbo]

Wo kommt denn das „ü“ her, das später als „ü“ dargestellt wird?

Der Darstellung nach zu urteilen, ist das „ü“ bereits UTF-8-kodiert (0xC3BC), wird jedoch als ISO 8859-1 interpretiert und nochmals kodiert (0xC3 0xBC ? 0xC383 0xC2BC) und dann wiederum vom Browser als ISO 8859-1 interpretiert und so dargestellt.

 

[Eagle-PsyX-]

Ist das die Lösung?
Er muss irgendwie die DB umkodieren, die entsprechende Koallition einstellen.
- Wenn ich eine Koallition einfach ändere, wird es umkodiert, oder nur anders interpretiert?

 

[Gumbo]

Nein, das ist eine mögliche Erklärung für den Fehler. Wo aber nun das erneute Kodieren stattfindet, weiß ich nicht.

 

[Schumiel]

Gambo, das "ü" kommt aus der Datenbank. Dies wird dann über ein javascript mit "top.location.href" zweimal weitergeleitet. Über Sinn und Zweck der Sache, sei mal egal. Es ist so und ich möcht es so.

Vor dem ersten "top.location.href" bestücke ich die SESSION-Variable mit der GET-Variable. Danach wird nur noch das SESSION genutzt, wo aus dem "ü" so die "komischen" Zeichen werden.