dedlfix: utf8_unicode_ci oder utf8_general_ci

Beitrag lesen

echo $begrüßung;

  1. Welche Einstellung sollte ich nehmen, um Daten als UTF-8 in MySQL zu speichern? Unter "Zeichensatz / Kollation der MySQL-Verbindung:" steht utf8_unicode_ci.

Für das Speichern ist allein die Enstellung des jeweiligen Feldes verantwortlich. Tabellen-, Datenbank- und System-Einstellungen sind nur Defaultwerte, wenn beim Anlegen keine explziten Angaben gemacht werden.

  1. Ist case-insensitive eigentlich sinnvoll bei Vergleichen oder käme auch utf8_bin in Frage?

Diese Frage musst du dir selbst beantworten. Das kommt ganz drauf an, was du für Ergebnisse beim Suchen und Vergleichen haben möchtest.

Die Frage aus dem Thema beantwortet dir das MySQL-Handbuch im Kapitel Unicode Character Sets.

  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.

Sowohl für die Verbindung wie für die Datenbank wie auch für die Tabellen und die enstprechenden Felder ist utf8_unicode_ci eingestellt,

Das ist alles schön und gut, auch wenn letzlich nur die Feldkodierung interessiert.

es wird per <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> UTF-8 eingestellt, eine Zeichensatzwahl durch Senden eines UTF-8-Header habe ich nicht, da es auch mit meta funktioniert (bzw. sogar ohne). Die Seiten sind mit UTF-8 ohne BOM gespeichert.

Das hingegen ist wichtig zwischen Webserver und Browser, aber aus der Sicht MySQLs uninteressant. Hauptsache du sendest die Kodierung, die ausgehandelt oder defaulteingestellt ist. Für Verbindungen ist das der Wert character set connection, der unter anderem über den PMA-Punkt Servervariablen und -Einstellungen abgefragt werden kann. Wenn die Antwort zwei Zeilen ist, dann ist es die für "Globaler Wert". Die andere ist die Einstellung für die aktuelle Verbindung. Die nützt dir in deinen Scripten nichts, denn du hast ja eigene Verbindungen.

Die Verbindungskodierung setzt man mit den PHP-Funktionen mysql_set_charset() oder mysqli_set_charset(). Steht beides nicht zur Verfügung, kann man ersatzweise SET NAMES verwenden.

  1. Sollte man <meta http-equiv="Charset" content="UTF-8" /> gleichzeitig mit
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> senden? Wenn ich header('Content-Type: text/html; charset=utf-8'); sende, kann im Prinzip auch beides entfallen!?

Die erste Meta-Element-Schreibweise ist mir noch nicht begegnet. http-equiv bedeutet HTTP-Äquivalent. Das hieße, ein solches Meta-Element überschriebe einen gleichnamigen HTTP-Header. Es ist jedoch in der für HTTP zuständigen RFC 2616 kein Header namens Charset definiert. Diese Angabe dürfte also nutzlos sein.

Die charset-Angabe aus dem Content-Type-Meta-Element wird dann herangezogen, wenn kein HTTP-Header das charset angibt. Das ist auch dann der Fall, wenn eine Webseite als Datei abgelegt ist.

echo "$verabschiedung $name";