Umlaute und Sonderzeichen ändern

[dedlfix]

Hi!

echo urlencode($_POST["Site"]); gibt aus: M%E4rchen.
Okay, das ist eine 1-Byte-Codierung, vermutlich ISO-8859-1. Dann ist wohl das Script selbst (vermutlich!) in UTF-8 codiert.
Das kann man daraus nicht erkennen.

nein, aber daraus, dass das ISO-codierte 'ä' NICHT als identisch mit dem im Script notierten 'ä' erkannt wird, kann man zumindest schließen, dass das Script selbst NICHT in ISO-8859-1 vorliegt. UTF-8 habe ich deshalb angenommen, weil es unter diesen Voraussetzungen am wahrscheinlichsten ist.

OK, als indirekte Folgevermutung kann man das annehmen.

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Hier behauptest du, das Dokument sei in ISO-8859-1 codiert - das ist aber anscheinend nicht wahr.
Warum nicht?
Siehe oben. Wenn es so wäre, gälte im Script auch ('ä' von außen) == ('ä' im Script).

Er hat aber damit nicht behauptet, das Script sei so kodiert, sondern dessen Ausgabe. Die charset-Angabe des Content-Type ist unabhängig von der Kodierung des Erzeugers dieses Contents.

Du hast ein generelles Problem, weil die Codierung von URL-Parametern nicht wirklich festgelegt ist.
URL-Parameter haben wir hier nicht, sonder ein per POST gesendetes Formular.
Ja, stimmt. POST-Parameter werden aber genauso behandelt und unterliegen den gleichen Regeln. Sie werden nur anders übermittelt, und dadurch entfällt eine eventuelle Längenbeschränkung.

POST-Daten setzen in einem üblichen Browser ein Formular voraus. Die kann man nicht einfach ins Blaue hinein in der Adresszeile oder ähnlichem eingeben. Zur Kodierung der POST-Daten wird der Browser immer die Kodierung der Formularseite verwenden (accept-charset mal nicht beachtet). Die von dir erwähnte Nicht-Festlegung betrifft händisch eingegebene URLs. Und das geht aus Prinzip (auf üblichem Weg) mit POST-Daten nicht.

Und die unterschiedlichen Kodierungen kommen nur dann zustande, wenn man URLs händisch eingibt.
Ansonsten verwendet der Browser wohl die Codierung des Dokuments.

Ja.

Wenn der Browser aus Formulardaten einen Querystring zusammenbaut, orientiert er sich an der Kodierung der Seite. Aber, wie gesagt, das interessiert bei diesem Problem nicht.
Doch, sicher - das ist anscheinend genau das Kernthema dieses Threads.

Nein, weil $_POST und nicht $_GET sein Problem ist.

Lo!