get-parameter convertieren

[Bernd R. Rickert]

Hallo,

In einem Email habe ich einen Umlaut im query string.
Beispielweise im Outlook erscheint dann: file.php?member="Tümmel".
Wenn man jetzt den Link klickt kommt statt dem "ü" ein "%C3%BC" im Browser.
php liest anschliesend das "%C3%BC" als "ü" aus und ich weiss nicht mit welchem Charset ich das
"ü" wieder in ein "ü" konvertieren kann.
Alle Umlaute einzeln zu ersetzen, habe ich keine Lust.
Weiss jemand Abhilfe?

Gruss

Bernd R. Rickert

editiert: Hat sich erledigt. Ich wandel die Umlaute im Vorweg in hexadezimal Code um.
Sieht ja auch gleich viel sicherer aus.

 

[Jürgen Auer]

Das

QUOTE (Bernd R. Rickert @ Sa 8.4.2006, 23:36)ü


ist die UTF-8 - Darstellung von ü, also mußt Du diese Stringeingabe als UTF-8-String betrachten und weiterverarbeiten.

Nur verwende ich kein PHP, deshalb geht es an dieser Stelle nicht weiter.

Mit NET habe ich all diese Probleme schon längst nicht mehr.

 

[Bernd R. Rickert]

Danke jAuer,

Ich hab stundenlang nach dem Charset gesucht. Nun isses zu spät.

Danke trotzdem

Gruss

Bernd R. Rickert

 

[Bernd R. Rickert]

QUOTE Mit NET habe ich all diese Probleme schon längst nicht mehr.


Ist utf8 in net voreingestellt?
Ich habe nach dem php-update vergessen, utf8 in der php.ini einzugeben. Danke für den reminder.

Gruss

Bernd R. Rickert

 

[Jürgen Auer]

QUOTE (Bernd R. Rickert @ So 9.4.2006, 0:13)Ist utf8 in net voreingestellt?

.NET kennt intern nur Strings, die selbstverständlich immer Unicode-Strings sind. Bei der Ausgabe in eine Datei oder als Webserver wird ein Stream - üblicherweise UTF-8 - gesendet. Nur wenn man die Ausgabe explizit bsp. als ASCII deklariert, wird nur eine 8-Bit-Codierung erzeugt.

Der Zugriff auf die Daten des sendenden Browsers (Url, Querystring nach ?) geschieht über Objekte, welche in der Regel die Transformation selbst vornehmen. Ferner gibt es einige Werkzeuge, mit denen direkt transformiert werden kann.

Diese gruseligen Dinge von C++ und anderen Programmiersprachen mit Ascii- und Unicode-Strings, BufferOverflows durch fehlerhafte Längenüberprüfungen und ähnlichem oder die verschiedenen Api-Funktionen für 8- und 16-Bit-Codierungen gehören in .NET längst zur Vergangenheit.

 

[Bernd R. Rickert]

Tatsächlich scheint apache 2.2 ein Problem mit mehreren Charsets zu haben.
Die Charsets werden nomalerweise neben einem default charset in der http.conf hinzugefügt.
Mit Apache 2.0 funkioniert das auch, mit Apache 2.2 wird der default Charset überschrieben.
Ein äusserst bedenklicher Makel in Zusamenhang mit mysql-Daten.
Ich habe es bislang jedenfalls nicht geschafft mysql-Daten und utf8-get-parameter unter einen charSet-Hut
zu bringen und benutze den bin2hex work around.

Gruss

Bernd Reinhard Rickert