dedlfix: Umstellung auf UTF-8

Beitrag lesen

Tach!

ich muss das häppchenweise begreifen und versuche zusammenzufassen, was ich wie verstehe.

Im Wesentlichen scheint es mir, hast du es verstanden. Ich präzisiere nur noch einige Formulierungen.

  1. MySQL: (PHP holt sich die Daten, beeinflusst sie zunächst aber nicht)

Stimmt. Da PHP grundlegend (noch) auf 1-Byte-Kodierungen ausgelegt ist, gibt es da auch keine Probleme. Problematisch wird es erst dann, wenn PHP in der Lage sein wird, diverse Kodierungen entgegenzunehmen und diese in ein internes Format umkodieren muss. Dann kann es zum Beispiel bei gesendetem ISO-8859-1 und angenommenem UTF-8 wegen der nicht möglichen fehlerfreien Interpretation zu Konvertierverlusten kommen. Aber das ist noch keine Gegenwart.

a) Die Kodierungsangabe bezieht sich immer auf Tabellenfelder. Die Codierungsangabe einer Tabelle ist letztlich die Codierungsangabe der Felder in dieser Tabelle.

Die Kodierungsangabe bezieht sich immer auf das, wofür sie vorgesehen ist. Bei CREATE DATABASE foo CHARACTER SET ... bezieht sie sich auf die Datenbank, bei CREATE TABLE foo (field1 VARCHAR(50) CHARACTER SET ..., field2 VARCHAR(50)) CHARACTER SET ... bezieht sie sich einmal auf das Feld und einmal auf die Tabelle. Für field2 ist keine explizite Angabe gemacht worden, also wird die Angabe für die Tabelle verwendet.

b) Die Kodierungsangabe von Tabellenfeldern hat lediglich Einfluss darauf, welche Zeichen in ihr gespeichert werden können.

Ja. Dazu kommt üblicherweise auch noch eine Kollationsangabe, die mit der Kodierung zusammenhängt, aber die kommt erst beim Stringverarbeiten (Sortieren, Vergleichen etc.) zum Einsatz.

c) Einzig die Kodierung der Verbindung zwischen PHP und MySQL hat Einfluss darauf, wie die Daten, die aus der DB ausgelesen werden, (um-)kodiert werden.

Sie bestimmt, wie die Daten zwischen Client und Server ausgetauscht werden. Wie MySQL auf die Felder zugreift, ist aus der Sicht des Clients nicht weiter von Belang.

d) Die Codierung der Felder hat keinen Einfluss auf die Codierung der Daten, die PHP im Resultset eines (My)SQL-Statements zur Verfügung stehen.

Stimmt. (Dass inkompatible Angaben zwischen beiden "Welten" zu Datenverlust beim Umkodieren führen kann, muss ich sicher nicht erwähnen.)

e) sind z.B. die Tabellenfelder UTF-8-kodiert stehen sie im Resultset von PHP:mysql_query() in der Form kodiert zur Verfügung, wie die Verbindung zwischen MySQL und PHP kodiert ist.

Ja, auch bei jeder beliebigen anderen Feld-Kodierungsangabe ist für den Client lediglich die Verbindungskodierungsangabe relevant.

f) die Kodierung der Verbindung legt man mit mysql_set_charset() fest. Ohne diesen Befehl greift ein Default.

Ja, damit ist alles perfekt. Wie gesagt ist für ISO-8859-x und UTF-8 auch ein SET NAMES gefahrlos möglich. Die Default-Werte hören in der Server-Konfiguration auf die Namen character_set_client, character_set_connection und character_set_results. Deren Default-Wert ist character-set-server.

dedlfix.