encodeURI & rawurlencode

[Fabian]

Hiho!

Ich lese aus einer textarea einen Text aus und verschickte in per Ajax per POST. Das hat immer Probleme bei Umlauten gemacht. Also hab ich mir gedacht ich codier das ganze per encodeURI und decodier es in meinem PHP Skript wieder per rawurlencode. Klappt aber irgendwie nicht. Es werden trotzdem kryptische Zeichen in die DB eingetragen.

$antwort = addslashes(htmlentities(rawurldecode($_REQUEST['antwort'])));

Wenn ich das Skript jetzt aber "händisch" aufrufe, also per

test.php?antwort=L%E4ufer%20und%20K%E4se%20k%F6nnen

Dann wird alles korrekt in die DB eingetragen.

Wo drückt der Schuh? Codiert encodeURI anders als rawurldecode decodiert?

Hat jemand einen Tipp?

Gruß
Fabian

[Cheatah]

Hi,

$antwort = addslashes(htmlentities(rawurldecode($_REQUEST['antwort'])));

warum dekodierst Du einen dekodierten Wert?

Wenn ich das Skript jetzt aber "händisch" aufrufe, also per
test.php?antwort=L%E4ufer%20und%20K%E4se%20k%F6nnen

Wie lautet das Ergebnis Deines o.g. PHP-Codes? Und warum hast Du Deine Frage im Themenbereich "JavaScript" eingeordnet?

Cheatah

[Fabian]

Hi,

$antwort = addslashes(htmlentities(rawurldecode($_REQUEST['antwort'])));

warum dekodierst Du einen dekodierten Wert?

Weil ich keine %E4 haben will, sondern ä.

Wenn ich das Skript jetzt aber "händisch" aufrufe, also per
test.php?antwort=L%E4ufer%20und%20K%E4se%20k%F6nnen

Wie lautet das Ergebnis Deines o.g. PHP-Codes?

»»
"Läufer und Käse können"
»»Und warum hast Du Deine Frage im Themenbereich "JavaScript" eingeordnet?

Weil ich nicht weiß wo der Fehler ist. Wenn ich ihn in PHP eingeordnet hätte, dann hätte mich gefragt, warum ich ihn nicht in JS eingeordnet hab.

Ich hab jetzt aber schon eine Lösung gefunden. Die ist sicher nicht schön; aber sie tut:

$antwort = addslashes(htmlentities(utf8_decode(rawurldecode($_REQUEST['antwort']))));

Geht zurück auf die Methode "wildes rumprobieren".

Gruß
Fabian

[shn]

Servus,

Weil ich keine %E4 haben will, sondern ä.

Warum sollte man so etwas wollen?

Gruss
Patrick

[Fabian]

Servus,

Weil ich keine %E4 haben will, sondern ä.
Warum sollte man so etwas wollen?

Gruss
Patrick

Um auch Leuten mit älteren Browsern und anderen Zeichensätzen Anzeigeschwierigkeiten zu ersparen. Vll ist es ja ein Anachronismus. Aber ich mach's halt.

Gruß
Fabian

[Gunnar Bittersmann]

Hello out there!

Weil ich keine %E4 haben will, sondern ä.
Warum sollte man so etwas wollen?

Um auch Leuten mit älteren Browsern und anderen Zeichensätzen Anzeigeschwierigkeiten zu ersparen. Vll ist es ja ein Anachronismus. Aber ich mach's halt.

Das ist aber Unsinn.

In der Datenbank sollten unverfälschte Daten stehen; also 'ä', keinesfalls 'ä'.

Wenn du wirklich 'ä' beim Ausgeben rausschicken willst, dann hat diese Codierung genau _dann_ stattzufinden; also nicht vor dem Eintragen in die DB, sondern nach dem Auslesen aus dieser.

Der Empfänger der Daten, also der Nutzer deiner Webseiten, hat nie ein Problem mit falschen Zeichencodierungen, wenn du serverseitig alles richtig machst. Du kannst also getrost 'ä' im Quelltext verwenden, wenn du das richtig codierst (UTF-8 oder auch ISO 8859-1, -15) und deinen Server auch diese Codierung abgeben lässt, ist clientseitig alles bestens.

Browser, die kein UTF-8 können, sind wohl seit langer Zeit ausgestorben. (Solche, die kein ISO 8859-1 können, hat’s wohl nie gegeben?)

Also nur Mut zum 'ä': auf jeden Fall in der DB, aber auch im HTML:

“It is almost always preferable to use an encoding that allows you to represent the characters in their normal form, rather than using character entities or NCRs.” [QA-ESCAPES]

Wenn der Nutzer keine Schriftart mit 'ä' hat, hilft auch 'ä' nicht; aber solche Nutzer gibt es wohl nicht.

See ya up the road,
Gunnar

[Cheatah]

Hi,

$antwort = addslashes(htmlentities(rawurldecode($_REQUEST['antwort'])));
warum dekodierst Du einen dekodierten Wert?

Weil ich keine %E4 haben will, sondern ä.

Du hast kein %E4, es sei denn, dies war der ursprüngliche, _un_kodierte Wert. Wenn jemand in ein Formularfeld "%E4" eingibt, was hat das dann mit "ä" zu tun?

Wenn ich das Skript jetzt aber "händisch" aufrufe, also per
test.php?antwort=L%E4ufer%20und%20K%E4se%20k%F6nnen

Also nicht
test.php?antwort=L%25E4ufer%2520und%2520K%25E4se%2520k%25F6nnen

Wie lautet das Ergebnis Deines o.g. PHP-Codes?
"Läufer und Käse können"

Das glaube ich nicht, denn dann wäre htmlentities() kaputt.

»»Und warum hast Du Deine Frage im Themenbereich "JavaScript" eingeordnet?
Weil ich nicht weiß wo der Fehler ist. Wenn ich ihn in PHP eingeordnet hätte, dann hätte mich gefragt, warum ich ihn nicht in JS eingeordnet hab.

Okay.

Ich hab jetzt aber schon eine Lösung gefunden. Die ist sicher nicht schön; aber sie tut: [...]
Geht zurück auf die Methode "wildes rumprobieren".

Ja, das ist alles andere als planvoll. Du hast einen Wert, der genau einmal kodiert wurde, dreimal dekodiert. Ich kenne nur eine Kodierung[1], bei der das zum gewünschten Ergebnis führt: ROT13.

Cheatah

[1] Na gut, zwei.

[Fabian]

Hiho,

Hi,

$antwort = addslashes(htmlentities(rawurldecode($_REQUEST['antwort'])));
warum dekodierst Du einen dekodierten Wert?

Weil ich keine %E4 haben will, sondern ä.

Du hast kein %E4, es sei denn, dies war der ursprüngliche, _un_kodierte Wert. Wenn jemand in ein Formularfeld "%E4" eingibt, was hat das dann mit "ä" zu tun?

Stimmt. Aber wenn jemand "%E4" in das Formular eingibt, dann bekommt er das auch wieder. Und kein "ä". Was ich will ist ja nur ein "ä" in "ä" unwandeln. Aber über mehrer Schritte.
1. Eingabe vom User: "ä"
2. Kodieren mit URIencode -> "%E4"
3. Verschicken
4. Decodieren von "%E4" in "ä"
5. Codieren von "ä" in "ä"
6. Eintrag in die DB

Wenn ich das Skript jetzt aber "händisch" aufrufe, also per
test.php?antwort=L%E4ufer%20und%20K%E4se%20k%F6nnen

Also nicht
test.php?antwort=L%25E4ufer%2520und%2520K%25E4se%2520k%25F6nnen

Wie lautet das Ergebnis Deines o.g. PHP-Codes?
"Läufer und Käse können"

Das glaube ich nicht, denn dann wäre htmlentities() kaputt.

Stimmt. Die Ausgabe ist schon "Läufer und Käse können". Aber mein Browser schreibt halt "Läufer und Käse können"

Ich hab jetzt aber schon eine Lösung gefunden. Die ist sicher nicht schön; aber sie tut: [...]
Geht zurück auf die Methode "wildes rumprobieren".

Ja, das ist alles andere als planvoll. Du hast einen Wert, der genau einmal kodiert wurde, dreimal dekodiert. Ich kenne nur eine Kodierung[1], bei der das zum gewünschten Ergebnis führt: ROT13.

ROT13 kenn ich nicht :) Ich weiß durchaus, dass das nicht planvoll ist. Aber jetzt tut es. Mit planvoll kam ich ja nicht weiter. Codieren und Decodieren alleine hat ja nicht funktioniert.

Cheatah

Gruß
Fabian

[shn]

Servus,

5. Codieren von "ä" in "ä"
6. Eintrag in die DB

Wenn du schon Umlaute als Entities ausgeben willst (wobei die bevorzugte Methode wäre, dies nicht zu tun), solltest du dennoch die Daten in Rohform speichern, und sie erst bei der Verwendung (z.B. HTML-Ausgabe) dem jeweiligen Kontext entsprechend maskieren.

Gruss
Patrick

[shn]

Servus,

und nochmal der Link mit passendem Anker

Gruss
Patrick

[Cheatah]

Hi,

Stimmt. Aber wenn jemand "%E4" in das Formular eingibt, dann bekommt er das auch wieder. Und kein "ä". Was ich will ist ja nur ein "ä" in "ä" unwandeln. Aber über mehrer Schritte.

so soll es sein.

1. Eingabe vom User: "ä"
2. Kodieren mit URIencode -> "%E4"
3. Verschicken

Bis hierhin richtig; vorausgesetzt der letzte Punkt impliziert keine weitere Kodierung.

4. Decodieren von "%E4" in "ä"

Dies ist auch richtig - falsch ist jedoch, was Du damit tust. Die Dekodierung hat PHP beim Befüllen von $_REQUEST längst übernommen. Du dekodierst zwei zusätzliche Male.

ROT13 kenn ich nicht :)

"ROT" steht für "Rotate", 13 ist die Anzahl der Zeichen, um die jeder Buchstabe im Alphabet (rotierend, also über die Alphabetgrenzen hinaus) verschoben wird. Aus "a" wird also "n", aus "b" "o" usw. Die Dekodierung von ROT13 ist ROT13.

Ich weiß durchaus, dass das nicht planvoll ist. Aber jetzt tut es.

_Weißt_ Du das oder _glaubst_ Du das?

Mit planvoll kam ich ja nicht weiter.

Dann glaubst Du also nur.

Codieren und Decodieren alleine hat ja nicht funktioniert.

Finde heraus, welche Kodierungen durchgeführt werden, egal ob von Dir oder etwas anderem, und sorge dafür, dass in umgekehrter Reihenfolge die jeweils zugehörige Dekodierung stattfindet, egal ob von Dir oder etwas anderem. Jedes Ergebnis, das davon abweicht, ist falsch und bringt Dich langfristig in Diablos Futtermachraum.

Cheatah

[Fabian]

Hiho!

Hi,

4. Decodieren von "%E4" in "ä"

Dies ist auch richtig - falsch ist jedoch, was Du damit tust. Die Dekodierung hat PHP beim Befüllen von $_REQUEST längst übernommen. Du dekodierst zwei zusätzliche Male.

Das hieße doch, dass wenn ich "echo  $_REQUEST['antwort'];" schreibe, dass dann ein "ä" kommen muss. Aber wenn ich das mach, dann kommt nur ein tolles Fragezeichen an statt. Ich weiß es nicht, aber mir scheint, dass deine Argumentation damit dem Beweis nicht standhalten kann.

ROT13 kenn ich nicht :)

"ROT" steht für "Rotate", 13 ist die Anzahl der Zeichen, um die jeder Buchstabe im Alphabet (rotierend, also über die Alphabetgrenzen hinaus) verschoben wird. Aus "a" wird also "n", aus "b" "o" usw. Die Dekodierung von ROT13 ist ROT13.

Danke. Hatte es schon auf wiki nachgelesen.

Ich weiß durchaus, dass das nicht planvoll ist. Aber jetzt tut es.

_Weißt_ Du das oder _glaubst_ Du das?

»»
Das weiß ich. Jetzt ist alles korrekt, so wie ich es will in DB eingetragen. Und ich konnte noch kein Fehlverhalten durch Falscheingaben erzwingen.

Mit planvoll kam ich ja nicht weiter.

Codieren und Decodieren alleine hat ja nicht funktioniert.

Finde heraus, welche Kodierungen durchgeführt werden, egal ob von Dir oder etwas anderem, und sorge dafür, dass in umgekehrter Reihenfolge die jeweils zugehörige Dekodierung stattfindet, egal ob von Dir oder etwas anderem. Jedes Ergebnis, das davon abweicht, ist falsch und bringt Dich langfristig in Diablos Futtermachraum.

Ich weiß welche Codierung angewendet wurde. Das war ich ja selbst. Aber die Decodierung brachte nicht das gewünschte Erbgebnis. Daher ja auch der Thread hier ;)

Ich weiß, dass es nicht schön ist. Aber wenn niemand einen besseren Vorschlag hat, dann muss es wohl so weiterlaufen.

Gruß
Fabian

[Harlequin]

Yerf!

4. Decodieren von "%E4" in "ä"

Dies ist auch richtig - falsch ist jedoch, was Du damit tust. Die Dekodierung hat PHP beim Befüllen von $_REQUEST längst übernommen. Du dekodierst zwei zusätzliche Male.

Das hieße doch, dass wenn ich "echo  $_REQUEST['antwort'];" schreibe, dass dann ein "ä" kommen muss. Aber wenn ich das mach, dann kommt nur ein tolles Fragezeichen an statt. Ich weiß es nicht, aber mir scheint, dass deine Argumentation damit dem Beweis nicht standhalten kann.

Cheatah übersieht hier glaub ich, dass Du die Daten per POST verschickst und somit keine Automatische kodierung stattfindet (die bei GET ja notwendig wäre). Allerdings ist deine eigene URL-Kodierung ebenfalls überflüssig, dein Umlautproblem kommt durch etwas anderes. Dein Request wird vom Browser als utf-8 versendet, PHP erwartet aber scheinbar ISO. Deshalb ist utf8_decode das einzige, was Du wirklich brauchst (oder PHP utf8 beibringen....)

Gruß,

Harlequin

[Fabian]

Hiho!

Cheatah übersieht hier glaub ich, dass Du die Daten per POST verschickst und somit keine Automatische kodierung stattfindet (die bei GET ja notwendig wäre). Allerdings ist deine eigene URL-Kodierung ebenfalls überflüssig, dein Umlautproblem kommt durch etwas anderes. Dein Request wird vom Browser als utf-8 versendet, PHP erwartet aber scheinbar ISO. Deshalb ist utf8_decode das einzige, was Du wirklich brauchst (oder PHP utf8 beibringen....)

Du bist ein Schatz :) Jep. Genau das hat mir gefehlt! Dann brauch ich es nicht vorher zu kodieren (was ja anscheinend sowieso sinnlos ist).

Gruß,

Harlequin

Gruß
Fabian

[Fabian]

Hi!

Ich nehme (fast) alles wieder zurück :)
Ic hwar so "schlau" und hab den Header nicht vollständig mitgeschickt (Was mir ja auch mal früher hätte auffallen können). Wenn ich schön mein Charset mitschicke, dann wird es auch korrekt angezeigt.

Was jedoch nicht behoben ist: Die Daten werden immernoch als %E4 usw in der DB gespeichert. (Der Header zeigt das ja nur richtig an, aber hat mit der Datenverarbeitung ja nix weiter am Hut, oder?).
Weiterhin bringt mich hier nur

$antwort = utf8_decode(rawurldecode($_REQUEST['antwort']));

weiter.

Gruß
Fabian