urldecode ?

[Martin Hein]

Hallo Forum,

ich habe eine XHML-Site auf, der ein Forumlar (method=post),
bestehend aus einem Eingabefeld 'Suchbegriff' existiert.
Der Name ist Programm - Die Empfängerseite verwendet den Wert
aus diesem Eingebafeld $_POST['Suchbegriff'] für ein SELECT-
Statement auf eine MySQL-DB ->

SELECT * ... LIKE "%'.$_POST['Suchbegriff'].'%"

Das MySQL Statement-funktionierte bis zu dem Zeitpunkt, als
ich anstelle %'.$_POST['Suchbegriff'].'% den String 'Zähne'
dirket dort drin stehen hatte.

Sprich: Der Parameter kommt nicht als String Zähne an, sondern
ist vorher scheinbar in irgend einer Weise verändert worden.

ich habe daher folgendes ausprobiert:
-------------------------------------

SELECT * ... LIKE "%'.urldecode($_POST['Suchbegriff']).'%" und

SELECT * ... LIKE "%'.rawurldecode($_POST['Suchbegriff']).'%"

brachte mich beides nicht weiter.

kann mir jemand nen Tipp geben ?

danke und

beste gruesse,
heinetz

[illcp]

Hallo,

Probleme mit Umlauten (ä,ö,ü) hängen fast immer mit verschiedenen Zeichensätzen (meist ISO-8859-1 und UTF-8) zusammen. Wie ist das Encoding des Dokumentes, aus dem du schickst, und wie das des Empfängerdokumentes ?

Setzt' doch spaßeshalber mal im Empfängerdokument ein

echo $_POST['Suchbegriff'];

ein und schau was herauskommt.

Evtl. hilft auch ein

mysql_query('SET NAMES 'utf8'');

bzw.

mysql_query('SET NAMES 'latin1'');

vor dem eigentlichen Such-Query.

P.S.: Niemals Daten aus Eingabefeldern direkt so in einen SQL-String stecken, sondern vorher mit mysql_real_escape_string() escapen, also z.B. mysql_real_escape_string($_POST['Suchbegriff']) (Stichwort Fehler und SQL-Injections).

[Martin Hein]

Hi,

merci, die spasseshalber ausgabe hab ich schon mal gemacht:

echo $_POST['Suchbegriff']; exit; ->

... und der Browser gibt sauber "Zähne" aus.
Worauf ich mir aber nix einbilde ;)

Die Seiten sind beide durch:
----------------------------

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

... als UTF-8 ausgezeichnet.

Vor dem latin1 fürchte ich mich ein wenig ;)

Hintergrund:
------------
Die MySQL, meiner Testumgebung ist eine andere Verion,
als die auf dem Liveserver, weshalb ich mit den Dumps
Probleme hatte. Dort musste ich manuell aus meinem Dump
den String 'latin1' rausschmeissen.

danke und

beste gruesse,
martin hein

[Martin Hein]

Hi,

ergänzend:
----------
$search_str = "Zähne";
SELECT * ... LIKE "%'.$search_str.'%"
--> funktioniert

$search_str = $_POST['Suchbegriff'];
SELECT * ... LIKE "%'.$search_str.'%"
--> funktioniert nicht

$search_str = mysql_real_escape_string($_POST['Suchbegriff']);
SELECT * ... LIKE "%'.$search_str.'%"
--> funktioniert leider auch nicht

beste gruesse,
martin hein

[Martin Hein]

Hi,

noch ne Ergänzung:
------------------
$search_str = htmlentities($_POST['Suchbegriff']);

... führt zu der merkwürdigen Anzeige: Z&Atilde;&curren;hne

nächster Versuch:
-----------------
$query = "SET NAMES utf8";
$result = mysql_query($query);

... führt zu einem Ergebnis. Allerdings krieg ich die
DB-Werte dann nicht mehr mit htmlentities vernünftig
maskiert.

nächster Versuch:
-----------------
in der Datenbank habe ich mal 'Kollation: utf8_unicode_ci'
eingestellt. Das führte aber auch nicht zu einem Ergebnis.

beste gruesse,
martin hein

[Sven Rautenberg]

Moin!

nächster Versuch:

$query = "SET NAMES utf8";
$result = mysql_query($query);

... führt zu einem Ergebnis. Allerdings krieg ich die
DB-Werte dann nicht mehr mit htmlentities vernünftig
maskiert.

Mußt du ja auch gar nicht. Nimm htmlspecialchars(), das reicht vollkommen aus. Es ist ja gerade das nette Feature, dass man mit einer Unicode-Codierung wie UTF-8 keinerlei Entities mehr benötigt, weil alle Zeichen durch UTF-8 direkt codiert werden können. Lediglich die HTML-eigenen Sonderzeichen müssen natürlich maskiert werden.

htmlentities() gehört von daher eigentlich schon lange auf den Müll.

- Sven Rautenberg

[Martin Hein]

Moin,

funktioniert problemlos.

"'htmlentities' gehört auf den Müll
und 'htmlspecialchars' tut das gleiche"

... derartige Aussagen liebe ich ;)

merci,
martin hein

... extended searching and replacing

[illcp]

$search_str = htmlentities($_POST['Suchbegriff']);

... führt zu der merkwürdigen Anzeige: Z&Atilde;&curren;hne

...

»»

$query = "SET NAMES utf8";
$result = mysql_query($query);

... führt zu einem Ergebnis. Allerdings krieg ich die
DB-Werte dann nicht mehr mit htmlentities vernünftig
maskiert.

htmlentities(utf8_decode(mysql_result($result, $i,0)));

Ein bisschen umständlich, aber funktioniert. So ganz 100% kenn' ich mich dann im HTML-PHP-MySQL-Charset-Dschungel auch nicht aus, bzw. wo man z.B. den Standard-Zeichensatz für PHP ändern kann (ist soweit ich weiß per Default ISO-8859-1).

in der Datenbank habe ich mal 'Kollation: utf8_unicode_ci'
eingestellt. Das führte aber auch nicht zu einem Ergebnis.

Die Kollation ist nur für die Sortierungs-Richtlininen zuständig, also z.B. ob ein "ä" vor oder nach einem "a" kommt etc. Sollte mit deinem Problem nichts zu tun haben.

[Sven Rautenberg]

Moin!

htmlentities(utf8_decode(mysql_result($result, $i,0)));

Eine ganz extrem schlechte Lösung. Warum dann noch UTF-8 benutzen?

Ein bisschen umständlich, aber funktioniert. So ganz 100% kenn' ich mich dann im HTML-PHP-MySQL-Charset-Dschungel auch nicht aus

Das merkt man deutlich!

Die Funktion utf8_decode wandelt UTF-8 in ISO-8859-1 um. Das Problem dabei ist, dass in ISO nur 256 unterschiedliche Zeichen codiert werden können, in UTF-8 aber mehrere Millionen vorkommen können.

Funktioniert also nur dann prima, wenn auch in UTF-8 nur die Zeichen vorkommen, die es in ISO gibt.

Das Eurozeichen beispielsweise geht bei dieser Konvertierung drauf!

Deshalb dann doch lieber auf htmlentities() verzichten, und ebenso auf utf8_decode(), und nur ganz schlicht htmlspecialchars() einsetzen.

- Sven Rautenberg

[Dennis]

Hi illcp,

htmlentities(utf8_decode(mysql_result($result, $i,0)));

Wie Sven schon gesagt hat - ganz ganz schlechte Idee. Dass htmlentities auf den Müll gehört, würde ich aber trotzdem nicht so direkt sagen, schließlich kann man htmlentities ja noch einen Charset übermitteln:

echo htmlentities($string, ENT_QUOTES, "UTF-8");

Viele Grüße,
  ~ Dennis.

[Sven Rautenberg]

Moin!

Dass htmlentities auf den Müll gehört, würde ich aber trotzdem nicht so direkt sagen, schließlich kann man htmlentities ja noch einen Charset übermitteln:

Aber warum würde man das wollen? Entweder der Browser kann mit UTF-8 umgehen (was jeder Browser ist, der heutzutage von Leuten in nennenswerter Verbreitung anzutreffen ist), oder er kann es nicht (uralte Museumsbrowser wie Netscape 4).

Wenn ein Browser mit UTF-8 nicht umgehen kann, wird er sowieso zum Problem, spätestens dann, wenn er Formulardaten zurückschickt.

- Sven Rautenberg

[Dennis]

Hi Sven,

Aber warum würde man das wollen?

Ok, einen wirklichen Sinn mag es im alltäglichen Betrieb nicht geben ;-) Ich verwende es allerdings schon mal, wenn ich mit PHP irgendwelche Archive (HTML bzw. XML) erstelle - einfach nur um sicher zu gehen, dass nicht jemand mit einem „dummen Editor”™ die Datei öffnet und mir so die ganzen Sonderzeichen zerstört.

Viele Grüße,
  ~ Dennis.

[illcp]

Hallo,

ich kann das Problem reproduzieren. Ich bin mir nicht 100% sicher, aber anscheinend läuft die Kommunikation zwischen PHP und MySQL per Default mit ISO-8859-1. Gibst du nun einen Umlaut in einem Editor ein, der das Dokument in ISO-8859-1 speichert, wird es auch korrekt an MySQL übertragen.

Postest du es, wird es scheinbar (entsprechend der Dokument-Charset-Definition) UTF-8-Codiert geschickt, d.h. Umlaute kommen in der DB als Schrott an.

Gerade nochmal getestet:

mysql_query('SET NAMES 'utf8'');

vor deinem Abfragestring sollte das Problem lösen - tut es zumindest hier bei mir.

[Martin Hein]

Hi,

die Lösung funktioniert ja nun. Tausend Dank!

ich kann das Problem reproduzieren. Ich bin mir nicht 100% sicher, aber anscheinend läuft die Kommunikation zwischen PHP und MySQL per Default mit ISO-8859-1. Gibst du nun einen Umlaut in einem Editor ein, der das Dokument in ISO-8859-1 speichert, wird es auch korrekt an MySQL übertragen.

Das eigentliche Problem an dem ganzen Jungel ist ja, dass die
vermeintlichen "Fehler" oft garnicht sichtbar werden. In diesem
Fall kommen in meine Kommunikation zwischen php und mysql in den
meisten Fällen glücklicherweise Integers zum Tragen.

beste gruesse,
martin hein