nicht angemeldet
Tach!
Du kannst die Kodierung jederzeit mit den dokumentierten ALTER-TABLE-Statements ändern. Die Daten werden dabei intern umkodiert. Und das funktioniert auch problemlos, solange der Inhalt mit der Kodierungsangabe übereinstimmt.
Das ist für mich jetzt verwirrend. Gilt der letzte Satz, solange die vorhandenen Inhalte mit der *alten* oder mit der *neuen* Kodierung abgelegt wurden?
Die Kodierung der Felder spielt beim Punkt korrekter Speicherung keine Rolle, solange die Anwendungen auf der Verbindung aushandeln, welche Kodierung sie sprechen und dies dann auch korrekt tun. Alternativ können sie auch die Default-Verbindungskodierung verwenden. MySQL nimmt nun gegebenenfalls Umkodierungen zwischen der Verbindungskodierung und der Feldkodierung vor - sowohl reinzu als auch rauszu. Solange die Verbindungskodierung eingehalten wird, gibt es prinzipbedingt Datenverlust nur wenn von einem "größeren" in eine "kleineren" Zeichensatz gewechselt wird. Also wenn UTF-8 auf der Verbindung gesprochen wird (Zeichensatz ist dann Unicode) und die Felder nur auf Latin1 (Zeichensatz ist hier gleich Zeichenkodierung) stehen, gehen alle Nicht-Latin1-Zeichen flöten. Und beim Auslesen wenn die Felder UTF-8 sind, beim Beschreiben zwar alles gepasst hat, aber beim Auslesen die Verbindungskodierung auf Latin1 steht.
Ich meine, Kollation hin oder her, typischerweise werden, gerade in kleinen MySQL-gestützten Webanwendungen, die Daten in der Standardkodierung der DB abgelegt und das ist latin1_swedish oder bestenfalls latin1_general.
Kollation ist nicht Kodierung. Latin1 ist Latin1 (Kodierung), ob Schwedisch oder anderswie sortiert und verglichen wird (Kollation), spielt für die Kodierung keine Rolle.
In dieser Kodierung liegen die Texte dann in der Datenbank. Wenn nun z.B. UTF-8 für die Felder vorgegeben wird und die vorhandenen Inhalte umgerechnet werden, kommt doch schon hier Murks raus, oder?
Nur wenn man es falsch macht. Was MySQL intern umkodiert, muss einen nicht direkt interessieren. Wichtig ist die korrekt ausgehandelte Verbindungskodierung. Und dass die Kodierung der Felder alle Zeichen darstellen kann.
Wenn dann noch die Verbindung auf UTF-8 setzt, kann doch auch hier nur noch Murks rauskommen (quasi Murks²).
Also wenn Latin1 auf der Verbindung ausgehandelt wird (oder per Default so steht) und man sendet stattdessen dann UTF-8, ist das erstmal scheinbar kein Problem, solange beim Auslesen derselbe Fehler andersrum gemacht wird. Intern jedoch behandelt MySQL die Bytes der UTF-8-Sequenzen als einzelne Latin1-Zeichen. Das gibt dann Murks beim Sortieren oder Zeichenzählen und wenn man an die Feldlängenbeschränkung stößt.
dedlfix.
Auge