Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Ich zitiere im folgenden mal mein Posting von gestern aus
de.comp.lang.php.misc. Bisher habe ich dort eine Rückmeldung, die das
"Ü/ß"-Problem bestätigt, keine Lösung. Das Problem scheint nicht rein bei
MySQL zu liegen, aber dort liegt wohl die Hauptursache.

Ich steige z.Z. auf neuere Software um und sehe auf einmal arge Probleme
mit Daten, die vorher in UTF-8 eingegeben wurden (Daten sind in allen
Sprachen, daher UTF-8). In PHPMyAdmin werden diese jetzt durchweg so
angezeigt, wie bei der erzwungenen Anzeige in latin1 von UTF-8-Zeichen,
also z.B. "ö" -> "ö" (keine Ahnung wie das jetzt dargestellt werden
wird). Interessanterweise tritt dieses Problem in der PHP-Anwendung, in
der diese Daten ursprünglich eingegeben wurden, (fast) nicht auf. D.h. im
Browser wird alles korrekt in UTF-8 angezeigt, außer dem großen Ü und auch
dem ß (wie ich jetzt nachträglich bemerkt habe). Das
wird zumindest teilweise (nicht überall in der gleichen Applikation und
aus der gleichen Datenbank!) als türkisches kleines y (mit zwei Punkten
darüber) dargestellt. Wenn ich das in der Applikation überschreibe, wird
daraus ein "korrektes" Ü.
Bei Daten, die vorher wohl in latin1 eingegeben wurden, gibt es keinen
Unterschied. Hier werden überall die korrekten Umlaute angezeigt.
Ich gehe davon aus, daß dies in erster Linie mit der MySQL-Version zu tun
hat, aber da es sich so unterschiedlich in PHPMyAdmin und in der
PHP-Applikation selbst äußert, dachte ich, diese Gruppe wäre ein
sinnvoller erster Ort für dieses Problem, da es vielleicht nicht nur mit
MySQL zusammenhängt. Momentan stehe ich etwas auf dem Schlauch, wie und wo
ich das am besten anpacke.
Was ich im Prinzip erreichen möchte, ist, daß die Anzeige und Eingabe von
UTF-8-Zeichen wieder so wie vorher stattfindet.
An Information habe ich u.a. folgendes gefunden:
http://dev.mysql.com/doc/refman/4.1/en/charset-conversion.ht ml
http://dev.mysql.com/doc/refman/4.1/en/charset-upgrading.htm l

Jedoch scheint mir nicht viel Raum für Konversionen zu bestehen, denn
diese Werte scheinen schon automatisch so vom Server eingestellt zu
werden. Also die Kollation "latin1_swedish_ci" wird sowieso für alle
Datenbanken und Spalten angezeigt und die Character-Set-Werte des Servers
scheinen auch latin1 zu sein, so daß auch hier keine Einstellung des
Character-Sets beim Start nötig sein sollte. Das würde auch erklären,
warum in der PHP-Applikation selbst alles okay zu sein scheint - außer dem
Ü. Jedoch scheint PHPMyAdmin UTF-8 als festen Wert für diese Verbindung
client-seitig zu erzwingen, was diese Abweichung erklären würde. Das
versuchsweise Konvertieren von Spalten in diverse latin1- und
utf-8/ucs2-Varianten hat aber absolut nichts am angezeigten Ergebnis
geändert. Da ich allerdings keinen in-place-Upgrade vorgenommen habe,
sondern die Datenbanken komplett von der einen MySQL-Version in die andere
geschoben habe, mag das gar nicht mehr möglich sein.

Einige Daten:

alte Software: Suse 9.0, PHP 4.2.irgendwas, MySQL 4.0.15, PHPMyAdmin 2.6.1
neue Software: CentOS 4.2, PHP 4.3.9, MySQL 4.1.12, PHPMyAdmin 2.6.1

alte Variablen laut PHPMyAdmin: (1. Wert: Sitzung, 2. Wert: global)
character set latin1 latin1

neue Variablen laut PHPMyAdmin: (1. Wert: Sitzung, 2. Wert: global)
character set client utf8 latin1
character set connection latin1 latin1
character set database latin1 latin1
character set results utf8 latin1
character set server latin1 latin1
character set system utf8 utf8
character sets dir /usr/share/mysql/charsets/ /usr/share/mysql/charsets/

collation connection latin1_swedish_ci latin1_swedish_ci
collation database latin1_swedish_ci latin1_swedish_ci
collation server latin1_swedish_ci latin1_swedish_ci

Wie ich anhand der Demo von PHPMyAdmin 2.8.1 sehe, ist der
MySQL-Zeichensatz auch weiterhin nicht verstellbar. Und ich nehme an, daß
das hier genau das bzw. eines der Probleme darstellt.

Vielen Dank für jeden weiterführenden Tip.


Kai

Re: Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Kai Schaetzl wrote:

> Das Problem scheint nicht rein bei
> MySQL zu liegen, aber dort liegt wohl die Hauptursache.



"Das Problem" ist, daß du upgradest, ohne *vorher* das Handbuch zu
lesen.

> Ich gehe davon aus, daß dies in erster Linie mit der MySQL-Version zu tun
> hat, aber da es sich so unterschiedlich in PHPMyAdmin und in der
> PHP-Applikation selbst äußert, dachte ich, diese Gruppe wäre ein
> sinnvoller erster Ort für dieses Problem, da es vielleicht nicht nur mit
> MySQL zusammenhängt.

Die korrekte Newsgroup wäre de.comp.lang.php.datenbanken

Abgesehen davon wurde das Problem sowohl dort als auch hier bereits
mehrfach ausführlichst durchgekaut. Google Groups ist dein Freund.

> Momentan stehe ich etwas auf dem Schlauch, wie und wo
> ich das am besten anpacke.

Zuerst mal mußt du deine Daten mit der richtigen Encoding-Deklaration
versehen. Wenn du UTF8 in einem pre-4.1 MySQL gespeichert hattest, ist
das per Default gar nicht möglich, weil pre-4.1 MySQL lediglich 8-bit
Encodings kennt.

Wenn du die Daten mit einem pre-4.1 mysqldump exportierst, werden sie
zwar als UTF8 im Dump stehen, aber als (z.B.) latin1 deklariert sein.
Wenn du mit einem 4.1er mysqldump exportierst, werden sie als (z.B.)
latin1 angesehen (schließlich behauptet die Charset-Einstellung deines
pre-4.1 MySQL-Servers das) und fälschlich nach UTF8 umgewandelt.

Ein Weg wäre also, die UTF8 Daten mit einem pre-4.1 mysqldump zu expor-
tieren und dann im Dump die CHARSET Parameter für die entsprechenden
Tabellen / Spalten auf den korrekten Wert zu setzen. Außerdem ein USE
UTF8 an den Anfang, das den Rest des Files als UTF8 deklariert (schau
dir für die korrekte Syntax einen Dump von 4.1.x an). Das dann in das
4.1er MySQL laden.

> http://dev.mysql.com/doc/refman/4.1/en/charset-conversion.ht ml

Das würde helfen, wenn du die Datenfiles des alten MySQL verwendet
hättest. Leider ist "Da ich allerdings keinen in-place-Upgrade
vorgenommen habe, sondern die Datenbanken komplett von der einen
MySQL-Version in die andere geschoben habe" nicht eindeutig.

Aber wahrscheinlich geht das auch, wenn du mysqldump benutzt. Also
Alternativprogramm: alle Spalten, die nicht-latin1 Daten enthalten,
als BINARY markieren. Dumpen, in 4.1 laden und dann per ALTER TABLE
auf den korrekten Zeichensatz umsetzen.

> http://dev.mysql.com/doc/refman/4.1/en/charset-upgrading.htm l

Das paßt nicht, weil du die Daten in einem anderen Encoding
geschrieben hast, als dein character_set aussagt.


XL

Re: Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Kai Schaetzl wrote:

> Ich steige z.Z. auf neuere Software um und sehe auf einmal arge Probleme
> mit Daten, die vorher in UTF-8 eingegeben wurden (Daten sind in allen
> Sprachen, daher UTF-8).

[...]

> Bei Daten, die vorher wohl in latin1 eingegeben wurden, gibt es keinen
> Unterschied. Hier werden überall die korrekten Umlaute angezeigt.

[...]

> Jedoch scheint mir nicht viel Raum für Konversionen zu bestehen, denn
> diese Werte scheinen schon automatisch so vom Server eingestellt zu
> werden. Also die Kollation "latin1_swedish_ci" wird sowieso für alle
> Datenbanken und Spalten angezeigt und die Character-Set-Werte des Servers
> scheinen auch latin1 zu sein, so daß auch hier keine Einstellung des
> Character-Sets beim Start nötig sein sollte.

Warum erachtest Du latin1 als richtig, wenn die Daten in utf8 vorliegen?

Ansonsten hatte ich ebenfalls Probleme bei der Konvertierung auf eine
utf8-fähige MySQL-Version - ich hatte sie damals gelöst mit Konvertierung
per Hand, habe dann später den Befehl ALTER TABLE ... CONVERT TO CHARACTER
SET charset_name [COLLATE collation_name] gefunden.

Erstell Dir vielleicht mal eine kleine Testdatenbank, in der Du mit dem
Kommandozeilenclient etwas rumprobierst (in diesem vielleicht generell
default-character-set=utf8 setzen, bspw. über die ~/.my.cnf). Dann die
Probleme nach und nach eingrenzen - im Falle einer php-generierten
HTML-Seite auch am korrekte Characterset-Deklaration denken.

HTH ein bißchen,


Thomas

Re: Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Axel Schwenke schrieb am Tue, 21 Mar 2006 16:34:40 +0100:

> "Das Problem" ist, daß du upgradest, ohne *vorher* das Handbuch zu
> lesen.

No, das Problem ist, daß ein "winziges" Update von 4.0 auf 4.1 so
weitreichende Änderungen bringt. Und das Handbuch habe ich zumindest teilweise
gelesen, sonst wären mir kaum die genannten URLs bekannt gewesen. Wie auch
immer, das Problem ist so oder so vorhanden und einen klaren Lösungsweg gibt
es nicht. Daher meine Frage. Wenn ich die Wahl hätte, würde ich die Maschine
auch nicht wechseln.

> Die korrekte Newsgroup wäre de.comp.lang.php.datenbanken

Stimmt. Die habe ich nicht abonniert bzw. sie ist mir mental nicht präsent,
daher ist sie nicht in meine Überlegung, wohin damit, eingeflossen. Sorry.

>
> Abgesehen davon wurde das Problem sowohl dort als auch hier bereits
> mehrfach ausführlichst durchgekaut. Google Groups ist dein Freund.

Da schaue ich immer als erstes. Liefert nichts brauchbares bzw. nur
Riesenoutput. Womöglich mit den richtigen Suchbegriffen.

> Zuerst mal mußt du deine Daten mit der richtigen Encoding-Deklaration
> versehen. Wenn du UTF8 in einem pre-4.1 MySQL gespeichert hattest, ist
> das per Default gar nicht möglich, weil pre-4.1 MySQL lediglich 8-bit
> Encodings kennt.

Nun, gespeichert wurde als varchar über eine PHP-Seite, die mit Kodierung
utf-8 angezeigt wurde. Sowohl aus meiner Applikation wie aus PHPMyAdmin.
Beides war soweit okay und lieferte das gewünschte Ergebnis, d.h.
Speichermöglichkeit aller möglichen Sprachen und korrekte Anzeige. Das UTF-8
wurde hier sicherlich in zwei Bytes gespeichert, so habe ich das aber auch
erwartet. Der Output bei iso-8859-1 im Browser entsprach genau dem Output, den
man in einem nicht unicode-fähigen Texteditor sieht.


> > http://dev.mysql.com/doc/refman/4.1/en/charset-conversion.ht ml
>
> Das würde helfen, wenn du die Datenfiles des alten MySQL verwendet
> hättest.

Habe ich. Genau das meinte ich mit "geschoben". Tarball von hier nach da,
inkl. allem. Bei der Vielzahl der Datenbanken und Tabellen und womöglich sehr
unterschiedlichen Character-Sets bei der Eingabe wäre das Dumpen und
Konvertieren auch extrem aufwendig. So wie es jetzt ist, ist es überall
korrekt, wo in iso-8859-1 oder einem anderen 8bit-Zeichensatz gespeichert
wurde, nur nicht bei utf-8.

> Aber wahrscheinlich geht das auch, wenn du mysqldump benutzt. Also
> Alternativprogramm: alle Spalten, die nicht-latin1 Daten enthalten,
> als BINARY markieren. Dumpen, in 4.1 laden und dann per ALTER TABLE
> auf den korrekten Zeichensatz umsetzen.

Nach nochmaligem Lesen der Konvertierungsseite habe ich mich bemüht, das
nochmal genau zu befolgen, allerdings mit den schon übernommenen Datenbanken
auf dem neuen System. Wenn ich mit PHPMyAdmin Kollation: binary wähle, dann
wird von varchar auf varbinary gewandelt und der Output ist in PHPMyAdmin und
meiner Applikation okay (außer bei den Ü und ß). (var)binary ist neu mit 4.1
und gemäß Handbuch scheint (var)binary mehr doer weniger das gleiche zu sein
wie vorher (var)char. Verstehe ich das so richtig? Der Unterschied zu char in
entsprechender Kollation scheint von Nutzerseite her vor allem die Sortierung
zu sein. Wenn ich jetzt von varbinary wieder in varchar mit utf_irgendwas
Kollation wandele, bleibt es in PHPMyAdmin okay, aber meine Applikation zeigt
falsch an. Das wird daran liegen, daß PHPMyAdmin client-seitig utf-8 erzwingt,
während ich da gar nichts mache und den Standard, also latin1, mitbenutze. Da
müsste ich bei meinen Queries wohl entsprechend SET NAME benutzen, um wieder
Gleichstand herzustellen? Das habe ich mir noch nicht genau durchgelesen.

Was das Ü/ß-Problem betrifft, so habe ich den Eindruck, daß diese Buchstaben
in der alten Datenbank teilweise in vier Bytes abgespeichert wurden.
Jedenfalls werden 4 in PHPMyAdmin angezeigt, während es für die anderen
Sonderzeichen nur die "bekannten" 2er-Kombinationen sind. Das eine von mir
eingegebene Ü wird korrekt bzw. 2-bytig angezeigt. Die nicht korrekt
angezeigten Ü/ß wurden alle nicht von mir eingegeben. Ich nehme daher an, daß
sie evtl. in UTF-16 submitted wurden, entweder durch die Sprache des
Betriebssystems oder eine Browser-Einstellung erzwungen.

Danke für deine Hinweise. Hat weitergeholfen, wenn ich auch noch nicht
entschieden habe, wie das Endresultat aussehen wird. Momentan wandele ich
einfach in varbinary.


Kai

Re: Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Thomas Rachel schrieb am Tue, 21 Mar 2006 17:01:46 +0100:

> Warum erachtest Du latin1 als richtig, wenn die Daten in utf8 vorliegen?

Die Daten wurd als utf-8 submitted, was dann damit geschah, weiß ich nicht
;-) Als Character-Set wird im alten MySQL jedenfalls latin1 angezeigt und
global auf dem neuen ebenfalls. Dazu paßt die korrekte Darstellung in meiner
Applikation, die keine Änderung daran vornimmt.

>
> Ansonsten hatte ich ebenfalls Probleme bei der Konvertierung auf eine
> utf8-fähige MySQL-Version - ich hatte sie damals gelöst mit Konvertierung
> per Hand, habe dann später den Befehl ALTER TABLE ... CONVERT TO CHARACTER
> SET charset_name [COLLATE collation_name] gefunden.

Das geht soweit (siehe meine andere Antwort), gibt dann zwar in PHPMyAdmin
korrekten Output, in meiner Applikation aber nicht. Da müsste ich wohl erst
bei jeder Query Collation und/oder Character Set entsprechend setzen, damit
es auch dort richtig angezeigt wird. varbinary scheint die schnellste Lösung
zu sein, um direkt von altem varchar auf MySQL 4.1 zu springen. Danach kann
ich mir in Ruhe überlegen, ob ich das so lasse oder in utf8 (und welches)
konvertiere.

Danke für die Tips!


Kai

Re: Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Kai Schaetzl wrote:
> Axel Schwenke schrieb am Tue, 21 Mar 2006 16:34:40 +0100:
>
>> "Das Problem" ist, daß du upgradest, ohne *vorher* das Handbuch zu
>> lesen.
>
> No, das Problem ist, daß ein "winziges" Update von 4.0 auf 4.1 so
> weitreichende Änderungen bringt.

Ähem. 4.1 ist ein "major release". Da sind *sehr* viele Änderungen
drin. Tatsächlich sind von 4.0 auf 4.1 die clientseitig größten
Änderungen überhaupt passiert (in 5.0 kamen zwar mehr Features dazu,
die betreffen aber vor allem die Serverseite; der Client sieht die
neuen Features nicht, solange er sie nicht benutzt).

>> Zuerst mal mußt du deine Daten mit der richtigen Encoding-Deklaration
>> versehen. Wenn du UTF8 in einem pre-4.1 MySQL gespeichert hattest, ist
>> das per Default gar nicht möglich, weil pre-4.1 MySQL lediglich 8-bit
>> Encodings kennt.
>
> Nun, gespeichert wurde als varchar über eine PHP-Seite, die mit Kodierung
> utf-8 angezeigt wurde.

Das ist Wischiwaschi. Aber für gewöhnlich kann man davon ausgehen, daß
Browser Formulardaten im gleichen Encoding verschicken, das die Seite
hatte, auf der das Formular ist. Wenn *alle* deine HTML-Seiten mit
Formularen als UTF8 deklariert waren (per -> HTTP-Header) dann sollten
alle resultierenden Strings in der Datenbank auch UTF8 sein.

> Beides war soweit okay und lieferte das gewünschte Ergebnis

Das ist so, weil MySQL vor Version 4.1 keinerlei Interpretation der
übergebenen Strings betrieben hat. Solange deine Applikation konsistent
war, also für Ein- und Ausgabe das gleiche Encoding verwendet hat,
stimmte auch alles. Ausnahme: Sortierung und String-Vergleiche liefern
"merkwürdige" Resultate, wenn der eingestellte Zeichensatz vom tatsäch-
lich verwendeten Zeichensatz abweicht.

>> > http://dev.mysql.com/doc/refman/4.1/en/charset-conversion.ht ml
>>
>> Das würde helfen, wenn du die Datenfiles des alten MySQL verwendet
>> hättest.
>
> Habe ich. Genau das meinte ich mit "geschoben". Tarball von hier nach da,
> inkl. allem. Bei der Vielzahl der Datenbanken und Tabellen und womöglich sehr
> unterschiedlichen Character-Sets bei der Eingabe wäre das Dumpen und
> Konvertieren auch extrem aufwendig. So wie es jetzt ist, ist es überall
> korrekt, wo in iso-8859-1 oder einem anderen 8bit-Zeichensatz gespeichert
> wurde, nur nicht bei utf-8.

Logisch, weil die Deklaration nicht stimmt. Der Default-Zeichensatz des
MySQL-Servers ist ja nach wie vor latin1. Deswegen interpretiert er
deine UTF8 Strings auch als latin1.

> Nach nochmaligem Lesen der Konvertierungsseite habe ich mich bemüht, das
> nochmal genau zu befolgen, allerdings mit den schon übernommenen Datenbanken
> auf dem neuen System.

Solange du nicht schon anderweitig in die Datenbank geschrieben hast,
kannst du das Encoding auf UTF8 umstellen, indem du die Deklaration(!)
erst nach BINARY und dann nach UTF8 änderst.

> Wenn ich mit PHPMyAdmin Kollation: binary wähle, dann
> wird von varchar auf varbinary gewandelt und der Output ist in PHPMyAdmin und
> meiner Applikation okay (außer bei den Ü und ß). (var)binary ist neu mit 4.1
> und gemäß Handbuch scheint (var)binary mehr doer weniger das gleiche zu sein
> wie vorher (var)char. Verstehe ich das so richtig?

VARBINARY ist VARCHAR mit Collation BINARY. Also sinngemäß das, was
das Handbuch für CHAR() -> BINARY() empfiehlt.

> Der Unterschied zu char in
> entsprechender Kollation scheint von Nutzerseite her vor allem die Sortierung
> zu sein. Wenn ich jetzt von varbinary wieder in varchar mit utf_irgendwas
> Kollation wandele, bleibt es in PHPMyAdmin okay, aber meine Applikation zeigt
> falsch an. Das wird daran liegen, daß PHPMyAdmin client-seitig utf-8 erzwingt,
> während ich da gar nichts mache und den Standard, also latin1, mitbenutze. Da
> müsste ich bei meinen Queries wohl entsprechend SET NAME benutzen, um wieder
> Gleichstand herzustellen?

Exaktomundo.

> Was das Ü/ß-Problem betrifft, so habe ich den Eindruck, daß diese Buchstaben
> in der alten Datenbank teilweise in vier Bytes abgespeichert wurden.

UTF8 in MySQL kann maximal drei Bytes lang werden.

> Jedenfalls werden 4 in PHPMyAdmin angezeigt, während es für die anderen
> Sonderzeichen nur die "bekannten" 2er-Kombinationen sind. Das eine von mir
> eingegebene Ü wird korrekt bzw. 2-bytig angezeigt. Die nicht korrekt
> angezeigten Ü/ß wurden alle nicht von mir eingegeben. Ich nehme daher an, daß
> sie evtl. in UTF-16 submitted wurden, entweder durch die Sprache des
> Betriebssystems oder eine Browser-Einstellung erzwungen.

UTF16 ist kaum verbreitet. Eine 4-Byte Sequenz für "Ü" könnte die
Kombination aus "U" und "combining diaeresis" (sozusagen: "zwei Punkte
über dem vorhergehenden Zeichen") sein. Für "ß" kann ich mir das eher
nicht vorstellen, bin aber kein Unicode-Experte.


XL

Re: Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Axel Schwenke wrote:

Noch ein Nachtrag zum besseren Verständnis:

> Das ist so, weil MySQL vor Version 4.1 keinerlei Interpretation der
> übergebenen Strings betrieben hat. Solange deine Applikation konsistent
> war, also für Ein- und Ausgabe das gleiche Encoding verwendet hat,
> stimmte auch alles.
....

>> So wie es jetzt ist, ist es überall
>> korrekt, wo in iso-8859-1 oder einem anderen 8bit-Zeichensatz gespeichert
>> wurde, nur nicht bei utf-8.
>
> Logisch, weil die Deklaration nicht stimmt. Der Default-Zeichensatz des
> MySQL-Servers ist ja nach wie vor latin1. Deswegen interpretiert er
> deine UTF8 Strings auch als latin1.

Genau genommen verhält sich MySQL 4.1+ genauso wie die vorigen
Versionen, solange der Client-Zeichensatz mit dem der Datenbank-
Objekte übereinstimmt: Strings werden genauso an den Client
weitergegeben, wie sie vom Storage gelesen werden. Der Client sagt
"Gib mir latin1" - MySQL sieht an den Daten ein Schild "latin1"
und weiß, daß es nichts konvertieren muß.

Kommt jetzt aber ein Client daher und sagt "Gib mir UTF8" (so wie
phpMyAdmin) dann wandelt MySQL die Daten - von denen es glaubt sie
wären latin1 (steht ja schließlich dran) - in UTF8 um. Und schon
sind die Umlaute kaputt.

Andererseits will man gerade diese automatische Umwandlung unbedingt
haben. Dann muß sich nämlich kein Client mehr darum kümmern, in
welchem Encoding die Daten gespeichert sind. Er sagt MySQL einfach
beim Connect (oder mittendrin) welches Encoding er haben will und
MySQL konvertiert das automagisch. Im Gegenzug muß man dafür das
Encoding der Daten korrekt deklarieren.


XL

Re: Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Axel Schwenke schrieb am Tue, 21 Mar 2006 21:59:56 +0100:

> Ähem. 4.1 ist ein "major release".

Per definitionem ;-) Allgemein erwarte ich von einem Sprung von x.1 nach x.2 keine
so erheblichen Änderungen. Wie auch immer, man muß damit leben ;-)

> Logisch, weil die Deklaration nicht stimmt. Der Default-Zeichensatz des
> MySQL-Servers ist ja nach wie vor latin1. Deswegen interpretiert er
> deine UTF8 Strings auch als latin1.

Das ist nachvollziehbar, aber mit 4.0 ging es m.E. nunmal nicht anders.

> Solange du nicht schon anderweitig in die Datenbank geschrieben hast,
> kannst du das Encoding auf UTF8 umstellen, indem du die Deklaration(!)
> erst nach BINARY und dann nach UTF8 änderst.

Bezieht sich Deklaration jetzt auf Character-Set als Unterscheidung zu Kollation?
Ich gebe zu, daß ich vor allem mit PHPMyAdmin aus Komfort-Gründen arbeite und nicht
direkt am mysql-Prompt. PHPMyAdmin zeigt nur Kollation an. Und damit *scheint* die
Änderung wie oben auch zu klappen. Ich nehme an, daß PHPMyAdmin dabei automatisch
auch das Character-Set ändert. Was halt bewirkt, daß in meiner Applikation falsche
Zeichen angezeigt werden, weil sie keine Zeichensatz bei der Abfrage vorgibt. War
ja bisher nicht nötig bzw. nicht möglich.

>
> > Wenn ich mit PHPMyAdmin Kollation: binary wähle, dann
> > wird von varchar auf varbinary gewandelt und der Output ist in PHPMyAdmin und
> > meiner Applikation okay (außer bei den Ü und ß). (var)binary ist neu mit 4.1
> > und gemäß Handbuch scheint (var)binary mehr doer weniger das gleiche zu sein
> > wie vorher (var)char. Verstehe ich das so richtig?
>
> VARBINARY ist VARCHAR mit Collation BINARY.

Das Character-Set muß sich dabei m.E. auch ändern. Wenn ich das richtig verstehe,
ist die Kollation die "Sortierung" und Vergleichbarkeit der Zeichen. Wenn ich jetzt
aber ganz andere Zeichen angezeigt bekomme, müsste sich doch auch das Character-Set
geändert haben?

> > müsste ich bei meinen Queries wohl entsprechend SET NAME benutzen, um wieder
> > Gleichstand herzustellen?
>
> Exaktomundo.

An anderer Stelle im Handbuch wird erwähnt, man könne statt SET NAMES auch
--default-character-set direkt in der Query setzen. Aber ohne Beispiel. Diese Art
Variablen zu setzen, ist mir nicht geläufig. Gebe ich das einfach z.B. am Ende oder
Anfang der Query an oder wie?

>
> > Was das Ü/ß-Problem betrifft, so habe ich den Eindruck, daß diese Buchstaben
> > in der alten Datenbank teilweise in vier Bytes abgespeichert wurden.
>
> UTF8 in MySQL kann maximal drei Bytes lang werden.

Ist ja auch streng genommen nicht UFT-8 ;-) Es werden für diese zwei Sonderzeichen
in PHPMyAdmin halt vier Buchstaben angezeigt, für die anderen Sonderzeichen nur
zwei. (Wenn die vorgegebene Kollation latin1_swedish_ci oder eine ähnliche benutzt
wird.) Für das von mir mal eingegebene Ü ebenfalls nur zwei. Auf dem
Ursprungssystem wird da überall nur "Ü" korrekt angezeigt.

Danke für deine Erläuterungen. Ich bin mir noch nicht ganz klar über die weitere
Vorgehensweise nach Wandlung in varbinary. Die Daten liegen so vor, daß in einer
Spalte immer nur Daten einer bestimmten Sprache liegen. Sehe ich das richtig, daß
das Character-Set "utf8" ist und eine mögliche Kollation dafür "utf_whatever"? Ich
ändere die einzelnen Spalten dann von varbinary auf varchar mit sinnvoll für die
Sprache passender Kollation und in den Queries in meiner Anwendung setze ich
--default-character-set=utf8 was dann für alle utf8-Kollationen paßt?


Kai
--
Conactive Internet Services, Berlin, Germany

Re: Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Kai Schaetzl wrote:
> Axel Schwenke schrieb am Tue, 21 Mar 2006 21:59:56 +0100:
>
>> Solange du nicht schon anderweitig in die Datenbank geschrieben hast,
>> kannst du das Encoding auf UTF8 umstellen, indem du die Deklaration(!)
>> erst nach BINARY und dann nach UTF8 änderst.
>
> Bezieht sich Deklaration jetzt auf Character-Set als Unterscheidung zu Kollation?

Sowohl als auch. Der Zeichensatz (Encoding) wird *DEKLARIERT*, damit
wird eine *EIGENSCHAFT* der Strings angezeigt. Anhand dieser Eigen-
schaft wählt MySQL die Konvertierungsroutine aus, wenn Datenquelle und
-Senke verschiedene Encodings verwenden.

Die COLLATION einer Spalte ist ein *HINWEIS* wie man Daten dieser
Spalte zu sortieren/vergleichen gedenkt. Die Collation kann man
jederzeit überschreiben (per COLLATE Clause im SQL-Statement).

Verbunden sind Zeichensatz und Collation dadurch, daß jede Collation
nur für genau einen Zeichensatz existiert.

>> VARBINARY ist VARCHAR mit Collation BINARY.
>
> Das Character-Set muß sich dabei m.E. auch ändern. Wenn ich das richtig verstehe,
> ist die Kollation die "Sortierung" und Vergleichbarkeit der Zeichen. Wenn ich jetzt
> aber ganz andere Zeichen angezeigt bekomme, müsste sich doch auch das Character-Set
> geändert haben?

Ein BINARY String hat weder Zeichensatz noch Collation. D.h. Zeichen
werden *niemals* umgewandelt und bei Vergleich/Sortierung werden die
numerischen Zeichencodes verwendet. Genau deswegen funktioniert es,
wenn man das Encoding einer Spalte z.B. latin1 -> BINARY -> utf8
wandelt. Die Konvertierung von/zu BINARY führt keine Umwandlung durch.
Wenn du direkt von latin1 nach utf8 ändern würdest, würde MySQL auch
die Inhalte der Strings umwandelsn, statt nur die Deklaration zu ändern.

> Sehe ich das richtig, daß
> das Character-Set "utf8" ist und eine mögliche Kollation dafür "utf_whatever"? Ich
> ändere die einzelnen Spalten dann von varbinary auf varchar mit sinnvoll für die
> Sprache passender Kollation

Ja.

> und in den Queries in meiner Anwendung setze ich
> --default-character-set=utf8 was dann für alle utf8-Kollationen paßt?

Nö. Das ist eine Option für den MySQL-Kommandozeilenclient. Wenn du
dich von PHP mit MySQL verbindest, muß du charset_connection & Co.
passend setzen. Oder gleich SET NAMES verwenden. Hier würde dann doch
noch mal auf das Handbuch verweisen!


XL

Re: Probleme mit UTF-8 in PHPMyAdmin und generell bei Umstieg auf neuere MySQL-Version

Axel Schwenke schrieb am Wed, 22 Mar 2006 21:30:02 +0100:

> Nö. Das ist eine Option für den MySQL-Kommandozeilenclient. Wenn du
> dich von PHP mit MySQL verbindest, muß du charset_connection & Co.
> passend setzen. Oder gleich SET NAMES verwenden. Hier würde dann doch
> noch mal auf das Handbuch verweisen!

Werde ich, danke.

Kai
--
Conactive Internet Services, Berlin, Germany