folgendes Proiblem plagt mich!
Ich habe eine htm-Datei mit einem Textfeld für die Ortseingabe.
Wenn ich als Suchbegriff „mün“, für münchen z.B., eingebe wird in der mysql-db kein datensatz gefunden. Gebe ich aber „mün“ werden alle Datensätze wo „mün“ drin vorkommt aufgelistet.
Die mysql-db habe ich unter Koallition: utf8_unicode_ci gespeichert.
Der Datensatz München steht in der DB als Müchen. Ich vermute mal das dies das Problem ist. Wenn ich aber München in die DB schreibe bekomme ich als ausgabe immer M?nchen.
In der Datenbank sollten „unformatierte“ Daten stehen. Also „München“ statt „München“. Was die Ausgabe anbelangt, kannst du entweder
das Encoding der Seite auf UTF-8 setzen oder
die Daten aus der DB vor Ausgabe durch htmlentities() schicken.
Üblicherweise ist der erste Weg in Verbindung mit htmlspecialchars() zu empfehlen (siehe Doku):
[php]<?php
header(‚Content-Type: text/html; charset=UTF-8‘);
$dbDaten = ‚
ÄÖÜ
‘;
echo htmlspecialchars($dbDaten);[/php]
Edit: Eventuell zu beachten: Das Encoding der Quellcode-Seiten (.html, .php) sollte nach Möglichkeit ebenfalls UTF-8 sein (müsste sich im Editor einstellen lassen). Dann können im HTML-Code problemlos Umlaute eingesetzt werden, ohne auf ä und Co. ausweichen zu müssen.
interessant wäre das speichern der daten, ob da die werte durch eine funktion geschickt werden, die das umformatieren vornimmt. wenn ja, kannst du suchbegriffe ebenfalls durch diese funktion leiten.
genau genommen macht imho deine datenbank das eigentlich richtig und wandelt spezial-zeichen in gängige html zeichen um.
Ich danke für für Deine Hilfe, kriegs aber nicht gebacken.
Habe in der htm-, php Seite im head
drinstehen.
Die Seiten und die DB sind auch im Format utf-8 gespeichert.
Die Daten sind geändert, ohne ü .
Gebe ich als Suche -groß- ein = 0 Datensätze, bei Suche -gro-= viele DS aber wenn im DS ein ß vorkommt schreibt er nicht weiter, also anstatt Groß Kugel steht nur Gro da.
Ich wei0 auch nicht wo das htmlspecialchars() im Code hinkommt.
In die $daten kommt dort die Abfrage rein???
[PHP]$liste = mysql_query(„select ort, plz, vorwahl, bundesland from plzvw WHERE ort LIKE '%“ . $_POST[„ort“] . „%’ order by id“);[/PHP]
in
[PHP]$liste = mysql_query(„select ort, plz, vorwahl, bundesland from plzvw WHERE ort LIKE '%“ . htmlspecialchars($_POST[„ort“]) . „%’ order by id“);[/PHP]
Danke für die schnelle Antwort.
Soweit funzt es, wenn ich aber als Suchbegriff „mü“ oder „groß“ eingebe bekomme ich keine Datensätze zurück geliefert.
Ist aber egal jetzt. Ich danke Euch herzlich für die Hilfe und will nicht Eure Zeit verplembern.
Im Prinzip ist das alles völlig unproblematisch, wenn alle Bestandteile auf UTF-8 basieren:
Datenbank
Datenbankverbindung
Browserausgabe
Edit: Und besser auch die Quelltextdateien selbst
Datenbank ist wohl passend eingestellt, Datenbankverbindung:
[php]<?php
mysql_set_charset('utf8'); // mysql ab PHP5.2.3
$mysqli->set_charset('utf8'); //mysqli ab PHP5.2.3
mysql_query("SET NAMES `utf8`"); // veraltet
?>[/php]
Ausgabe im Browser:
[php]<?php
header(‚Content-type: text/html; charset=utf-8‘);[/php]
Die Header-Angabe ist bei vielen Servern auf ISO-8859-1 eingestellt und überschreibt leider gerne eventuell gesetzte -Tags. Deshalb geht es häufig nur explizit mit diesem Befehl.
Jede Benutzereingabe, die in einen SQL-String eingesetzt werden soll, muss escaped werden, um SQL Injection zu verhindern. Hierzu dient die Funktion mysql_real_escape_string.
Jede PHP-Variable, die als HTML-Code ausgegeben wird, sollte ebenfalls escaped werden, falls sie reservierte HTML-Syntaxzeichen (maßgeblich „<“ und „>“) enthalten könnte (-> XSS). Hierzu dient die Funktion htmlspecialchars.
Zusatz zu 2) Wird der HTML-Code nicht als UTF-8 ausgegeben (also, wenn etwa Umlaute auch escaped werden müssen, „ä“ → „ä“), sollte jede PHP-Variable escaped werden, die Umlaute oder reservierte HTML-Syntaxzeichen enthalten könnte. In diesem Fall per htmlentities.
Ich hab’s hier im Sinne von „oberflächliche Lösung“ gebraucht. Man wählt den zu einem Zeitpunkt einfachsten Weg, um ein akutes Problem erstmal zu beheben.
Das ist nicht unbedingt negativ gemeint. Zum Beispiel bei so einer Forensoftware gibt es häufig Kleinigkeiten, die man gerne angepasst hätte, die der ursprüngliche Entwickler aber aus verschiedenen Gründen nicht „einfach anpassbar“ programmiert hat oder die er nicht ändern will. In dem Fall versucht man nicht, den Entwickler dazu zu bringen, die Änderungen doch bitte irgendwie zu integrieren, sondern fügt schnell zwei drei Codezeilen im Originalcode des Forums hinzu. Diese Änderungen werden bei späteren Updates der Originalsoftware gerne wieder mit der neuen Originaldatei überschrieben, was den Update-Vorgang ganz schön kompliziert machen kann. Das wäre in diesem Fall der Nachteil einer simplen Lösung. (Nur hat man hier meist nicht die Wahl und muss den Originalcode „hacken“.)
Für den Fall in diesem Thread würde dein Code zwar unter Umständen die Sache für Umlaute regeln, aber irgendwann kommt ein Ort mit einem „ß“ oder einem „é“ hinzu oder die Abfrage soll auf polnische Ortsnamen erweitert werden, die völlig andere Zeichen enthalten… Dann muss ewig diese Ersetzungsliste aktualisiert werden und die Gefahr bleibt bestehen, immer irgendwelche Zeichen zu übersehen – wie du das „ß“. Deshalb ist es meist sinnvoller, eine nachhaltigere Lösung zu nutzen, wenn eine existiert.
Deshalb ist es meist sinnvoller, eine nachhaltigere Lösung zu nutzen, wenn eine existiert.