nicht angemeldet
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!