Moin!

Nein, da meine Scripte alle in UTF-8 gespeichert sind.

Siehst du, das ist genau das Problem.

Die Datenbankverbindung hat nämlich auch ein Encoding. Das ist standardmäßig aber auf ISO-8859-1 gesetzt. Und dann paßt es nämlich nicht.

Die Datenbank kriegt von deinem Skript die Bytes, die in UTF-8 z.B. einen Umlaut darstellen. Aber aufgrund der vereinbarten (oder eben nicht vereinbarten) Encoding-Definition der DB-Verbindung interpretiert die Datenbank diese Bytes so, als ob sie ISO-8859-1 sind. Ein Umlaut besteht aus zwei Bytes, das macht zwei ISO-8859-1-Zeichen, die werden von ISO nach UTF-8 gewandelt und in der DB abgespeichert. Im DB-Feld steht dann z.B. "A-Tilde Currency" - UTF-8-codiert, d.h. man kann innerhalb der Datenbank damit gar nichts anfangen als Umlaut, weil es ja kein Umlaut ist.

Das stört innerhalb deiner Verarbeitungskette skriptseitig aber nicht, denn der Rückweg läuft genauso ab: "A-Tilde Currency" wird aus der DB ausgelesen, gewandelt in ISO-8859-1, und das ergibt dann wieder genau die Bytes, die du skriptseitig als UTF-8 interpretierst, die dann einen Umlaut ergeben.

Da PHPMyAdmin aber das Umlauthandling korrekt vornimmt, siehst du natürlich den Mist, den dein Skript in die DB reingeschrieben hat, und kannst Texte darin auch nicht ordentlich bearbeiten.

Liegt aber ausschließlich an deiner mangelhaften Anbindung der Datenbank, nicht an PhpMyAdmin.

- Sven Rautenberg

echo $begrüßung;

Nein, da meine Scripte alle in UTF-8 gespeichert sind.

Nun, wenn du zwar UTF-8-kodierte Daten zum MySQL-Server sendest, der aber für Clientverbindungen sehr wahrscheinlich in deinem Fall Latin1 als Default-Wert eingestellt hat, und du diesen nicht neu verhandelst (mysql_set_charset() oder zur Not SET NAMES), dann haben wir ja die Stoßstelle. Die von dir gesendeten UTF-8-kodierten Daten werden vom MySQL-Server als Latin1 interpretiert und auch so behandelt. Aus einem UTF-8-Umlaut werden nun 2 Latin1-Zeichen. Rückwärts bekommst du diese 2 Latin1-Zeichen genauso wieder zurück, du interpretierst sie aber als UTF-8. Somit sieht für dich die Welt in Ordnung aus. Wer jedoch wie der PMA korrekt ausgehandelt UTF-8 mit dem MySQL-Server spricht, bekommt die zwei Zeichen jedes einzeln in UTF-8 kodiert präsentiert. Du siehst keinen Umlaut und denkst, dass das ein Fehler ist. Du schreibst mit dem PMA einen Umlaut. Wenn du ihn wieder mit dem PMA abfragst, solltest du ihn richtig angezeigt bekommen. Wenn du diesen nun mit deinem Client abfragst, kodiert MySQL ihn gemäß Default-Verbindungskodierung (= Latin1) um, du denkst aber, es wäre UTF-8 und siehst nur einen ungültigen Code.

Nun hast du aber ein Problem. Wenn du denkst, einfach mysql_set_charset("utf8") oder SET NAMES utf8 in dein Script einzubauen, beseitigt das Problem, das du mit dem PMA hast, dann irrst du dich leider. Denn in deiner Datenbank stehen bereits jede Menge falsch interpretierte Zeichen. die erstmal in eine richtige Kodierung gebracht werden müssen. Eine Möglichkeit wäre:

• Sicherungskopie der Datenbank erstellen; umkopieren in eine neue Datenbank reicht
• Export der Daten mit dem PMA [1]
• Umkodieren der Export-Datei mit einem Editor von UTF-8 nach Latin1 [2]
• Importieren mit dem PMA, dabei aber UTF-8 als Kodierung einstellen [3]
• Wenn der PMA nun alle Umlaute richtig anzeigt, deine Applikation mit mysql_set_charset("utf8") oder SET NAMES utf8 ebenfalls, dann ist alles gut gelaufen.

[1] Deine UTF-8 gesendeten aber als Latin1 interpretierten Daten werden dabei doppelt UTF-8-kodiert ausgegeben.
[2] Die doppelte UTF-8-Kodierung ist nun nur noch eine einfache.
[3] Deswegen kann man sie nun als UTF-8 einlesen.

echo "$verabschiedung $name";