nicht angemeldet
Hi!
MySQL ists egal, wie die Zeichen kodiert sind. Es gibt mW auch keine MySQL-proprietären Funktionen, die die Kodierung der Zeichen einer Tabelle verändern. Daher meine Frage nach der DB (Engine).
Es ist MySQL ganz und gar nicht egal, welche Kodierung die Daten haben.
In MySQL ists jedoch so, dass eine Tabelle als Latin oder utf-x oder sonstwie getaggt (deklariert) werden kann. Das sagt jedoch nichts über die Kodierung der Zeichen aus, die drin stehen. Also wo Latin1 draufsteht kann auch utf-8 drin sein (zeichenkodierungsmäßig).
Natürlich sagt die konfigurierte Angabe aus, wie die Daten darin abgelegt sind. Jedenfalls geht MySQL davon aus, dass das so ist. Darauf muss es sich verlassen können, um die Daten richtig behandeln zu können, beispielsweise beim Sortieren, beim Zeichenzählen mit der Funktion CHAR_LENGTH() oder beim Umkodieren. Wenn der Inhalt aus welchem Grund auch immer nicht mit der Deklaration übereinstimmt, gibt es natürlich Fehler oder Datenverlust.
Wenn MySQL die Daten nicht interpretieren muss (keine Sortierung oder Stringverarbeitung machen muss), dann kann es jedoch unter Umständen egal sein, wie die Daten ankommen, intern abgelegt werden und wieder rausgehen. Doch darauf sollte man nicht bauen.
Und weil das so ist, kann es schon sein, dass bei unachtsamen Umgang mit Kodierungsgeschichten (Pfusch in PHP, Perl u.a.) in einer Tabelle sowohl iso- als auch utf-kodierte Zeichen drin stehen. Daher meine Frage weiter oben v. gestern abend.
Pfusch ist und bleibt Pfusch. MySQL kann nicht die vorliegende Kodierung erraten und sie selbständig korrigieren. Für die korrekte Ausführung der eingebauten Mechanismen müssen schon klare Verhältnisse vorliegen.
Ein "alter table ..." übrigens würde an solchem Zeichensalat auch nichts ändern. Sowas zu bereinigen ist meistens Handarbeit, zumindest da, wo mit einer entsprechenden Klausel es nicht mehr möglich ist, die Records nach Zeichenkodierung rauszufischen.
Wenn man jedoch nur einen Fehler und den durchgängig gemacht hat, besteht oftmals noch Hoffnung, mit wenig Mühen die Daten zu korrigieren. Dazu gibt es diverse Möglichkeiten, auch ALTER TABLE. Jedoch ist das im Einzelfall zu betrachten. Der Möglichkeiten, seine Daten falsch abzulegen gibt es ja mehrere.
Auf alle Fälle ist es ratsam, im Schadenfall eine Kopie der betroffenen Tabelle(n) anzulegen, um bei Fehlversuchen neu anfangen zu können. Die Kopie sollte im DBMS angelegt werden. Ein Export kann zwar Teil eines Korrekturversuch sein, jedoch ist er hier nicht (in jedem Fall) als Datensicherung geeignet, weil beim Ausgeben eventuell eine Umkodierung vorgenommen wird, die die Daten unbrauchbar machen kann.
Lo!