Jürgen Trapp: utf8_unicode_ci oder utf8_general_ci

Beitrag lesen

  1. Nach Umstellung eines Projekts auf UTF-8 kommen Eingaben zwar als UTF-8 in den Tabellen an, im PMA werden Umlaute aber nicht richtig dargestellt. Aus einem "ä" wird dann "ä", auf der Website wird es aber richtig als "ä" ausgegeben. Umgekehrt werden direkte Umlauteingaben mit PMA zwar im PMA richtig, dafür aber auf der Website falsch dargestellt.

Nein, sie werden vielleicht vom Client als UTF-8 gesendet und erwartet, jedoch ist keine Verbindungskodierung ausgehandelt worden, weswegen der Systemdefaultwert Latin1 herangezogen wird. Der PMA hat seine Hausaufgaben gemacht und sendet und erwartet UTF-8, und hat dies für sich auch so ausgehandelt. Bei deinen unausgehandelten Verbindungen interpretiert MySQL die beiden Bytes eines UTF-8-kodierten ä als einzelne Latin1-Zeichen.

Hat fuktioniert mit mysql_set_charset(). Umlaute werden jetzt in der Applikation wie auch im PMA richtig dargestellt. Die zuvor vermeintlich auf der Website richtig ausgegebenen Umlaute kommen jetzt erwartungsgemäß verstümmelt an. Nur zu meinem Verständnis: Wie ist das vor mysql_set_charset() gelaufen? Die Daten kamen vom Benutzer bzw. Browser als UTF-8. In die DB wurden sie als Latin1 geschrieben, weswegen sie vom PMA zerschossen wurden, das ist mir soweit klar. Von MySQL kamen sie als Latin1 zurück an den PHP-Interpreter. Doch was ist jetzt passiert? Wieso hat die Applikation die Latin1-Daten trotz des UTF-8-Metas die Umlaute "richtig" dargestellt? Wurden die falschen "Multibyte"-Latin1-Zeichen, die im Prinzip statt einzelner Umlaute einfach mehrere Zeichen waren, vom Browser durch das UTF-8-Meta als einzelne richtige Multibyte-UTF-8-Zeichen interpretiert, oder wie muß ich mir das vorstellen?

Noch mal zur ersten Frage:

utf8_unicode_ci oder utf8_general_ci? Oder ist es sinnvoller, wenn ich mir versuche die Frage selbst mit http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html zu beantworten?