MySQL 5.x und Umstellung auf UTF-8
0 0 
dedlfix
MySQL 5.x und Umstellung auf UTF-8
Hello,
jetzt habe ich mir leider auch mal ein kleines UTF-8-Problem gebaut:
MySQL-Datenbank (5.0.51a-24+lenny2-log) angelegt, aber leider nur mit Default Character Set Latin1. Das ist die Voreinstellung des Servers. Ich habe also vergessen, das Character Set gezielt mit utf-8 anzugeben.
Die darauf aufsetzende Anwendung verwendet durchgängig utf-8, gibt das aber beim Anlegen ihrer Tabellen noch nicht diskret an, sondern verlässt sich hier auf die Default-Einstellung des Servers. Wenn die auf utf-8 steht, bzw. die DB vorher mit utf-8 als Default angelegt wurde, klappt das auch.
Nur diesmal habe ich es eben vergessen, und es wurden schon fleißig Daten eingegeben.
Kann ich nun trotzdem mittels
ALTER database datenbankname
CHARACTER SET utf-8;
die gesamte Datenbank umstellen, ohne die Daten zu gefährden?
Werden die Tabellen dann mit umgestellt?
Nach meinem Verständnis dürfte die Umstellung ja auch nur Auswirkung auf die Collation haben, da die Bytes vom Client ja 1:1 an die DB eitergegeben wurden und ob die nun als UTF-8 oder als irgendeine Dödel-Codierung interpretiert werden, müsste ja keinen Unterschied machen, oder?
Aber weil ich mir nun überhaupt nicht sicher bin, frage ich lieber, was denn passieren wird.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Kann ich nun trotzdem mittels
ALTER database
datenbankname
CHARACTER SET utf-8;die gesamte Datenbank umstellen, ohne die Daten zu gefährden?
Werden die Tabellen dann mit umgestellt?
Afaik geht das nicht, da du ja nur die (default) Zeichenkodierung der Datenbank änderst, nicht aber die der Tabellen und der Daten selbst - sämtliche Zeichen > 7 Bit (und ggf. daruffolgende) wären damit dann nicht mehr brauchbar.
Nach meinem Verständnis dürfte die Umstellung ja auch nur Auswirkung auf die Collation haben, da die Bytes vom Client ja 1:1 an die DB eitergegeben wurden und ob die nun als UTF-8 oder als irgendeine Dödel-Codierung interpretiert werden, müsste ja keinen Unterschied machen, oder?
Dafür sollte COLLATE zuständig sein
Aber weil ich mir nun überhaupt nicht sicher bin, frage ich lieber, was denn passieren wird.
CONVERT TO CHARACTER SET nicht vergessen, dann klappt's auch mit dem Nachbarn.
Also: "ALTER TABLE tablle CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
Aber auch hierzu spuckt die MySQL-Doku eine Warnung aus, die ich aber leider nicht ganz verstehe bzw. nicht nachvollziehen kann:
http://dev.mysql.com/doc/refman/5.1/de/alter-table.html#id580951-
Hello,
Kann ich nun trotzdem mittels
ALTER database
datenbankname
CHARACTER SET utf-8;die gesamte Datenbank umstellen, ohne die Daten zu gefährden?
Werden die Tabellen dann mit umgestellt?
CONVERT TO CHARACTER SET nicht vergessen, dann klappt's auch mit dem Nachbarn.
Also: "ALTER TABLE tablle CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
Das sieht nach Arbeit aus. Ich werde mich wohl doch erstmal einlesen müssen und lieber ein paar Versuche mit einer Dummy-DB machen. Mir ist nämlich noch nicht klar, wie ich das Login verhindere, solange ich die Umstellung durchführe. Es dürfen schließlich keine (partiellen) Datenveränderungen stattfinden währenddessen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
Hi!
Kann ich nun trotzdem mittels
ALTER database
datenbankname
CHARACTER SET utf-8;die gesamte Datenbank umstellen, ohne die Daten zu gefährden?
Damit stellst du nur den Default-Wert für die Datenbank um, der beim Anlegen neuer Tabellen verwendet wird (und außerdem, wenn man mit SET CHARACTER SET spielt, was man aber üblicherweise zugunsten von SET NAMES nicht braucht - Connection Character Sets and Collations).
Werden die Tabellen dann mit umgestellt?
Nein, die müssen mit ALTER TABLE angepasst werden. Auch der Tabellenwert ist wieder nur ein Default-Wert für neue Spalten. Die Tabellenkodierung umzustellen bringt es noch nicht, weil dann noch die Spalten fehlen. Aber es gibt das von suit verlinkte ALTER TABLE ... CONVERT TO CHARACTER SET ..., das die Spalten mit berücksichtigt. Zu der angesprochenen Warnung sage ich gleich noch was.
Nach meinem Verständnis dürfte die Umstellung ja auch nur Auswirkung auf die Collation haben, da die Bytes vom Client ja 1:1 an die DB eitergegeben wurden und ob die nun als UTF-8 oder als irgendeine Dödel-Codierung interpretiert werden, müsste ja keinen Unterschied machen, oder?
Die Kollation spielt bei der Zeichenkodierung(sänderung) keine Rolle, weil diese erst bei Stringvergleichen herangezogen wird. Wichtig für die Zeichenkodierung ist die Angabe zum CHARACTER SET.
Wie MySQL den ankommenden Bytestrom interpretiert hängt von der jeweiligen Verbindungskodierung ab. Da wird keinesfalls einfach nur 1:1 durchgereicht, sondern gegebenenfalls konvertiert wenn die Verbindungskodierung (oder deren Defaultwert) nicht zur Kodierung des jeweiligen Feldes passt. Jedes Feld kann übrigens seine eigenen Kodierung haben, es wird dann individuell behandelt. Wenn du immer schön nach dem Verbindungsaufbau die Zeichenkodierung ausgehandelt hast, können dir lediglich Zeichen jenseits von Latin1 (MySQL versteht darunter Windows-1252) verlorengegangen sein. MySQL hat dann nämlich alle Bytesequenzen gemäß deiner ausgehandelten Kodierungsangabe interpretiert und in Latin1 konvertiert. Die Daten sind dann aber passend zur angegebenene Kodierung in den Feldern abgelegt. Das kann man prüfen, indem man sie sich mit dem phpMyAdmin oder der Workbench anzeigen lässt - die Umlaute etc. müssen damit ordentlich zu sehen sein. Du kannst dann die Konvertierung mit obigem Statement oder auch spaltenweise vornehmen.
Wenn du allerdings auf die Kodierungsaushandlung nach dem Verbindungsaufbau verzichtet hast, war das nicht gut. In dem Fall hat MySQL die Default-Kodierung Latin1 angenommen und die Bytesequenzen als Einzelbytes gelesen und so abgelegt. Ein UTF-8-ä von dir wird als die beiden Zeichen à und ¤ abgelegt. Ein Konvertieren nach UTF-8 würde dann weiterhin diese beiden Zeichen ergeben. Das kann man wiederum mit dem PMA etc. sehen.
Die einfachste Weise das Dilemma zu beheben, ist ein Dump/Export mit Zeichenkodierung ISO-8859-1 und ein anschließendes Einlesen als UTF-8. Der Erfolg lässt sich wieder mit dem PMA nachweisen. Diese Tools sind deshalb geeignet, weil sie zum einen die Verbindungskodierung korrekt aushandeln und zum anderen UTF-8 verwenden. Es gibt dann keinen Datenverlust wie wenn er entstünde, wenn (richtig ausgezeichnete und "beeinhaltete") UTF-8-Spalten mit einer Latin1-Verbindung ausgelesen werden würden. Man sieht also im Prinzip das was MySQL in den gespiecherten Daten sieht.
Aber weil ich mir nun überhaupt nicht sicher bin, frage ich lieber, was denn passieren wird.
Erst Datensicherung anlegen, dann experimentieren! Es reicht ein Kopieren der Tabelle(n) oder Datenbank mit einem der vorhandenen Tools (phpMyAdmin, Workbench). Bereits in den Tabellen enthaltene Unstimmigkeiten gehen dabei nicht verloren.
Lo!