encodeURIComponent codiert ß falsch

[Adi Wehrli]

Hallo zusammen

Normalerweise sollte der Befehl 'encodeURIComponent("ß")' doch als Resultat den String "%C3%F9" zurückgeben. Nun gibt es bei uns aber einzelne Clients, bei denen sowohl im FF als auch im IE jeweils andere Hex-Werte zurückgegeben werden. Was könnte das sein? Das "Phänomen" ist wie erwähnt nicht auf allen PCs zu beobachten.

Im Web habe ich darüber nichts gefunden. Die relevanten Encoding-Einstellungen (META-Tag, Request-Header etc.) sind auf UTF-8 gesetzt.

Vielen Dank im Voraus.

[Adi Wehrli]

PS: alle anderen Umlaute oder Sonderzeichen werden korrekt codiert.

[molily]

Hallo,

Nun gibt es bei uns aber einzelne Clients, bei denen sowohl im FF als auch im IE jeweils andere Hex-Werte zurückgegeben werden.

Bei welchen Versionen? Welche Hexwerte werden zurückgegeben?

Was könnte das sein?

Möglicherweise Browserfehler. Allerdings sind mir keine entsprechenden im Zusammenhang mit encodeURIComponent bekannt.

Die relevanten Encoding-Einstellungen (META-Tag, Request-Header etc.) sind auf UTF-8 gesetzt.

Wo kommt das ß her? Steht es als String im Dokument? Wie kommt es da hinein? Aus einer Datenbank vielleicht? Ist sichergestellt, dass das Dokument korrekt kodiert ist?

Mathias

[Adi Wehrli]

Moin

1. Versionen der Browser: FF=2, IE=6. Die korrekten Hex-Rückgabewerte für das "EssZett" sollten %C3%9F lauten.

2. An den Browsern selbst sollte es eigentlich nicht liegen, denn diese fehlerhafte Codierung kommt auf denselben Clients sowohl im IE als auch im FF vor. Und auch ein Test mit unterschiedlichen Service-Packs der Windows-Versionen (WinXP SP2 und SP3) hat nichts erhellt, da dies scheinbar auch nicht das Problem sein kann.

2. Das ß wird in einem Eingabefeld (also INPUT-Tag, type="text") eines Forms eingegeben, also alles normales HTML. Das Form wird über AJAX verarbeitet.

Vielen Dank.

Adi

[Cheatah]

Hi,

Normalerweise sollte der Befehl 'encodeURIComponent("ß")' doch als Resultat den String "%C3%F9" zurückgeben. Nun gibt es bei uns aber einzelne Clients, bei denen sowohl im FF als auch im IE jeweils andere Hex-Werte zurückgegeben werden.

auf welche Weise (und an welcher Stelle) hast Du dies verifiziert? Und, wie molily schon fragte, wie lauten die Werte?

Cheatah

[LX]

Kann es sein, dass tatsächlich die korrekten Werte zurückgegeben werden, diese aber innerhalb des ISO-8859-1-Charspace zumindest teilweise in ein Steuerzeichen umgewandelt werden (insbesondere beim MSIE)?

Kann es sein, dass Du versuchst, einem ISO-8859-1-kodierten Formular das Senden von Wertem in UTF-8-Zeichenkodierung beizubringen?

Falls ja, vergiß es - es klappt leider nicht.

Gruß, LX

[Cheatah]

Hi,

Kann es sein, dass Du versuchst, einem ISO-8859-1-kodierten Formular das Senden von Wertem in UTF-8-Zeichenkodierung beizubringen?

ich? Ja - aber das weißt Du doch schon ;-)

Cheatah, SCNR

[Adi Wehrli]

Kann es sein, dass Du versuchst, einem ISO-8859-1-kodierten Formular das Senden von Wertem in UTF-8-Zeichenkodierung beizubringen?

Wenn das so sein sollte, dann müsste das ja bei jedem Client auftreten...

Übrigens: der inkorrekt codierte Hexwert für das EssZett wäre %B2%CE.

[Adi Wehrli]

auf welche Weise (und an welcher Stelle) hast Du dies verifiziert? Und, wie molily schon fragte, wie lauten die Werte?

Verifiziert habe ich dies über einen Alert auf den verschiedenen Clients. Die inkorrekten Hex-Rückgabewerte weiss ich leider grade nicht mehr.

[Struppi]

Normalerweise sollte der Befehl 'encodeURIComponent("ß")' doch als Resultat den String "%C3%F9" zurückgeben. Nun gibt es bei uns aber einzelne Clients, bei denen sowohl im FF als auch im IE jeweils andere Hex-Werte zurückgegeben werden. Was könnte das sein?

Vodooo.
Für das Phänomen deiner Beschreibung gibt es keine Erklärung.

Struppi.

[Adi Wehrli]

So, Problem gelöst. Das Zeichen war kein EssZett sondern ein kleines Beta. Nun, es ist ja in gewissen Schriftarten auch nicht leicht, ein ß von einem β zu unterscheiden.

Anfrage geschlossen.

Grüsse
Adi