Problem mit Eingabeformular, Umlauten und MySQL

[furam]

Hi!

Ich habe ein Problem, mit dessen Lösung ich nicht vorankomme.

Erstmal zum Grundsätzlichen: Es gut um einen Gutscheinblog. Ich habe in PHP eine Eingabemaske für Gutscheine gemacht, welche die Daten per $_POST an eine weite PHP-Datei schickt, welche diese Daten in eine MySQL-Datenbank einfügt. Das ganze funktioniert bis auf die Umlaute und Sonderzeichen auch sehr gut.
Sowohl die Eingabemaske als auch die verarbeitende PHP-Datei sind UTF-8 kodiert.
Lasse ich von der verabeitenden Datei die POST-Daten ausgeben, stimmt noch alles. Ich habe die Daten dann immer per htmlentities umformen lassen. Allerdings wird bspw. aus "Ä" nicht Ä sondern Ã,, . Ich vermute, dass der Fehler bei der Weitergabe der Daten via POST geschieht.
Hat vielleicht jemand eine Idee?

Zusammengefasst: ich schaffe es nicht, dass in der MySQL Datenbank die Umlaute richtig oder zumindest richtig konvertiert angezeigt werden. Dort hab ich auch schon mit den Kollationen rumprobiert, aber keine funktionierende gefunden.
Für Hilfen oder Anregungen wäre ich sehr dankbar!

MfG,

furam.

[Vinzenz Mai]

Hallo

Erstmal zum Grundsätzlichen: Es gut um einen Gutscheinblog. Ich habe in PHP eine Eingabemaske für Gutscheine gemacht, welche die Daten per $_POST an eine weite PHP-Datei schickt, welche diese Daten in eine MySQL-Datenbank einfügt. Das ganze funktioniert bis auf die Umlaute und Sonderzeichen auch sehr gut.
Sowohl die Eingabemaske als auch die verarbeitende PHP-Datei sind UTF-8 kodiert.

schon mal gut.

Lasse ich von der verabeitenden Datei die POST-Daten ausgeben, stimmt noch alles. Ich habe die Daten dann immer per htmlentities umformen lassen.

Diese Umformung ist im SQL-Kontext völlig überflüssig, ja sogar schädlich.
Speichere Rohdaten.

Allerdings wird bspw. aus "Ä" nicht Ä sondern Ã,, . Ich vermute, dass der Fehler bei der Weitergabe der Daten via POST geschieht.

Ich kann überhaupt nicht verstehen, warum man sowas speichern will. UTF-8 ist doch wunderbar. Wenn ein Ä eingegeben wird, dann speichere ein Ä - und nichts anders.

Hat vielleicht jemand eine Idee?

Entsorge htmlentities beim Abspeichern in der Datenbank, sorge dafür, dass der Client UTF-8 mit dem Server spricht, sowohl beim Einlesen als auch beim Ausgeben. Sorge dafür, dass die Eingabedaten im SQL-Kontext keinen Schaden anrichten können, nutze z.B. mysqli und Prepared Statements oder halt eben altherkömmlich die mysql*_real_escape()-Funktionen.

Bei der Ausgabe der Daten in einem HTML-Kontext solltest Du die Daten aus der Datenbank mit htmlspecialchars() behandeln, eben dem Kontext angemessen :-)

Freundliche Grüße

Vinzenz

[dedlfix]

echo $begrüßung;

Lasse ich von der verabeitenden Datei die POST-Daten ausgeben, stimmt noch alles. Ich habe die Daten dann immer per htmlentities umformen lassen.

Diese Umformung ist im SQL-Kontext völlig überflüssig, ja sogar schädlich.
Speichere Rohdaten.

Ah, jetzt. Er verwendet das schon beim Eintragen in die Datenbank. Ich ging davon aus, dass das bei der Ausgabe verwendet wird. Jetzt ist mir klar, warum da ...

Allerdings wird bspw. aus "Ä" nicht Ä sondern Ã,, .

... passiert. htmlentities() geht im Normalfall (sprich: ohne den dritten Parameter) von ISO-8859-1 aus, nicht von UTF-8, und dann macht es natürlich solchen Mist.

echo "$verabschiedung $name";

[EKKi]

Mahlzeit furam,

Lasse ich von der verabeitenden Datei die POST-Daten ausgeben, stimmt noch alles. Ich habe die Daten dann immer per htmlentities umformen lassen.

Warum? Ich dachte, die Datenbank unterstützt UTF-8? Wieso speicherst Du die Zeichen dann nicht einfach so, wie sie sind?

htmlentities() hat an dieser Stelle überhaupt gar nix verloren ... allerhöchstens bei der späteren Ausgabe der Inhalte als HTML - wobei ich dort htmlspecialchars() vorziehen würde.

Zusammengefasst: ich schaffe es nicht, dass in der MySQL Datenbank die Umlaute richtig oder zumindest richtig konvertiert angezeigt werden.

In der MySQL-Datenbank wird nichts angezeigt. Und vor dem Reinschreiben konvertieren solltest Du erst recht nichts. Speichere die Inhalte dort, wie sie sind. Überprüfe, ob Deine Verbindung (SET NAMES) auch tatsächlich UFT-8 unterstützt.

Nach dem Auslesen aus der Datenbank und vor dem Ausgeben als HTML hingegen solltest Du die Werte dem Kontext entsprechend maskieren.

MfG,
EKKi

[dedlfix]

echo $begrüßung;

Sowohl die Eingabemaske als auch die verarbeitende PHP-Datei sind UTF-8 kodiert.
Lasse ich von der verabeitenden Datei die POST-Daten ausgeben, stimmt noch alles. Ich habe die Daten dann immer per htmlentities umformen lassen.

Warum das? Wenn du UTF-8 als Kodierung verwendest, kannst du doch quasi alle Zeichen dieser Welt direkt notieren. Im HTML-Kontext benötigst du nur htmlspecialchars(), um die HTML-eigenen Zeichen HTML-gerecht umzuwandeln.

Allerdings wird bspw. aus "Ä" nicht Ä sondern Ã,, . Ich vermute, dass der Fehler bei der Weitergabe der Daten via POST geschieht.

Hast du das überprüft? Lass dir die Daten ausgeben. var_dump() eignet sich für eine erste Überprüfung, weil es auch die Stringlänge in Bytes anzeigt. Ein Umlaut belegt in UTF-8 zwei Bytes. Als weiteres wäre eine Anzeige der Bytewerte sinnvoll, die man mit bin2hex() hinbekommt.
echo chunk_split(bin2hex($delinquent), 2, ' '); zeigt die Bytes gut lesbar einzeln an.

Hat vielleicht jemand eine Idee?
Zusammengefasst: ich schaffe es nicht, dass in der MySQL Datenbank die Umlaute richtig oder zumindest richtig konvertiert angezeigt werden.

Der häufigste Fehler ist, dass dem MySQL-Server nicht mitgeteilt wird, in welcher Kodierung man die Daten zu senden gedenkt und das Abfrageergebnisse haben möchte, sprich: die Verbindungskodierung wird nicht eingestellt. MySQL nimmt dann seine Default-Einstellung. In aktuellen PHP-Versionen gibt es mysql_set_charset(), ansonsten hilft das Absetzen eines SET NAMES-Statements zumindest für die hierzulande üblichen Kodierungen der Latin-Serie und UTF-8.

Dort hab ich auch schon mit den Kollationen rumprobiert, aber keine funktionierende gefunden.

An welcher Stelle? Für die Kodierung der Daten in den Feldern ist die für das jeweilige Feld eingestellte Kodierung zuständig. Die Kollation ist nur ein Sortierkriterium. Allerdings hängt Kodierung und Kollation voneinander ab. Die Kodierung der Tabelle oder Datenbank ist nur ein Default-Wert für neu angelegte Felder bzw. Tabellen, wenn diesen keine explizite Kodierungsangabe mitgegeben wurde.

Zwischen der Verbindungskodierung und der Feldkodierung nimmt MySQL Umkodierungen vor, wenn diese unterschiedlich sind. Wobei technisch bedingt nicht alles in jede Richtung umkodiert werden kann.

Wenn du mit diesen Hinweisen nicht zurecht kommst, müsstest du genauer beschreiben, wo genau was auf welche Weise falsch ist.

echo "$verabschiedung $name";

[goldjunge2007]

Hi,

also mit MySQL hab ich noch nicht so viel gemacht... aber wenn ich den Inhalt eines Formulars mittels PHP per E-Mail versende dan kodiere ich sowohl das Formular als auch die verarbeitende Datei in charset=iso-8859-1. Darüber bin ich zwar auch nicht ganz glücklich aber es geht problemlos auch mit Umlauten.

Freut mich wenn ich helfen konnte :)

[dedlfix]

echo $begrüßung;

[...] wenn ich den Inhalt eines Formulars mittels PHP per E-Mail versende dan kodiere ich sowohl das Formular als auch die verarbeitende Datei in charset=iso-8859-1. Darüber bin ich zwar auch nicht ganz glücklich aber es geht problemlos auch mit Umlauten.

Und warum nimmst du dann nicht UTF-8 oder etwas, mit dem du glücklich bist und die Umlaute problemlos darstellbar sind?

echo "$verabschiedung $name";

[furam]

hi!

oh man.. ab und zu sieht man wald vor bäumen nicht. :)

keine ahnung, was ich mir bei der nutzung von htmlentities VOR der speicherung der Daten gedacht habe. :) Danke für den Hinweis darauf!

Und ja.. SET NAMES hat alle meine Probleme behoben. :) Jetzt geht alles so wie es gedacht war. Peinlich, peinlich...

Danke nochmal an alle Helfer! ;)