dedlfix: (MYSQL) UTF8-, bzw Umlaut-Problem

Beitrag lesen

echo $begrüßung;

Übrigens, ich frage mich wieso das Auslesen genau dieser Daten dann wieder als richtig angezeigt werden?

Wenn du beim Auslesen den gleichen Fehler wie beim Eintragen gemacht hast, kann es gut sein, dass sich dessen Auswirkungen gegenseitig aufheben. Beispielsweise wenn die Verbindungskodierung auf Latin1 steht, du aber UTF-8-kodierte Daten sendest, stehen die Bytes des Datenstrom als Zeichen nach Latin1 interpretiert in dem Feld. Funktionen wie CHAR_LENGTH() oder eine Sortierung liefern dir falsche Ergebnisse, aber beim Auslesen bekommst du wieder Latin1-Daten zurück, die du jedoch als UTF-8 interpretierst und damit die Bytes zweier Latin1-Zeichen wieder als Bytesequenz eines UTF-8-Zeichens ansehen wirst.

Die Daten sind als nicht zerstört, sondern werden in der Datenbank aus irgend einem Grund nicht richtig gespeichert/angezeigt.

"In der Datenbank angezeigt" geht im Prinzip nicht, da sich MySQL gemeinhin als Blackbox darstellt. Du brauchst immer eine Verbindung zu ihr, um den Inhalt abzuholen, und ihn dann irgendwo irgendwie darstellen zu können. Die Verbindung ist eine der 10 verschiedenartigen Stellen in einem MySQL-Server, an denen eine Kodierung individuell eingestellt werden kann. Und dann hast du ja noch eine weitere Schnittstelle zum anzeigenden Terminal oder zum Browser, bei der ebenfalls bei fehlerhafter Deklaration die Zeichenkodierung fehlinterpretiert werden kann.

Da der phpMyAdmin ein beliebtes Werkzeug ist und außerdem seine Hausaufgaben im Bereich der Kodierung gemacht hat, kann man ihn aber durchaus als Referenz verwenden, um die Richtigkeit der in der Blackbox gespeicherten Daten zu prüfen. Er kann aber auch nicht zaubern und eine als UTF-8-deklarierte aber ungültige Sequenz besser darstellen.

Wenn du kannst, schalte mal das Query-Log ein (ausschalten hinterher nicht vergessen, das müllt dir sonst (ohne logrotate) nur die Festplatte voll). Du siehst darin alle Verbindungsstarts und -enden sowie alle Querys. Ein mysql_set_character_set()-Aufruf ist da auch als SET NAMES-Query zu sehen. Siehst du kein SET NAMES, gelten die Werte der Systemvariablen character_set_client und character_set_connection sowie character_set_results für den Rückweg. Wenn du diese Variablen mit dem PMA abfragst, und der für diese Werte eine Zeile "Globaler Wert" anzeigt, gilt das für dich, und der andere Wert speziell nur für die aktuelle PMA-Verbindung. Die Bedeutung der drei Konfigurationsvariablen sind im Kapitel Connection Character Sets and Collations erläutert. (Der Teilbereich Kollation ist für das Zeichenkodierungproblem nicht von Bedeutung.) Mit aktiviertem Query-Log (MySQL-Server neu starten, nach Ändern der Konfigurationsdatei) solltest du nun erkennen, welche Kodierung ausgehandelt wird oder auch wenn das nicht passiert. Jetzt müsstest du das nur noch mit dem vergleichen, was du an Daten hinsendest und gegebenenfalls Differenzen in der Kodierung(sangabe) beseitigen. Dann sollte zumindest der Teil Datenbank problemlos funktionieren, was du mit dem PMA überprüfen kannst. Wenn zwischen Browser und Server noch Probleme sind, ist das eine andere Baustelle, die sich mit passenden charset-Angaben im Content-Type-HTTP-Header, im gleichnamigen Meta-Element und im accept-charset-Attribut von Formularen lösen lassen sollte.

echo "$verabschiedung $name";