nicht angemeldet
Spalte von ISO nach UTF-8 bringen
Hallo, nachdem ich ja grad schon bei utf-8 war, schieb ich nochmal ne Frage nach.
Ich hab eine MySql Datenbank, die Text als ISO speichert (halt das übliche).
Die will ich schon länger auf UTF-8 umstellen, aber ich finde dazu nur Lösungen mit extra php-Scripten, die ich mir dazu laden müsste. Ich glaube allerdings immer noch an einen MySQL-Befehl der das kann.
Die Ein/Ausgabe der Daten im Browser habe ich alles schon angepasst. Neue Texte gehen richtig rein und kommen auch richtig wieder raus, was man an Umlauten sieht. Ein Problem hab ich nur noch mit den alten Texten, die sind jetzt (d.h. bei Ausgabe als utf-8) verhunzt.
Ich bräuchte also nur noch einen Befehl der Art
UPDATE Tabelle SET Spalte = machUtf8AusIso(Spalte)
Gibts da echt nix?
So wie CONVERT zum Beispiel. Den hab ich mal ausprobiert in der Art SELECT CONVERT(isoSpalte using uft8), aber da kommt dann auch nichts anderes raus als ohne CONVERT. Wie kann ich mir denn da behelfen?
-
Hi Encoder,
die wohl einfachste Möglichkeit dies ohne PHP zu bewerkstelligen ist wohl, einen Dump von der Datenbank zu machen und die Textdatei mit einem Editor aufzumachen und intern die Codierung umzustellen. (Beispielsweise Komodo). Dies geht aber natürlich nur wenn sich die Datenmengen in begrenztem Rahmen bewegen, über 20 MB wirds damit wohl nicht mehr so leicht gehen.
Danach wieder importieren und fertig.
LG,
Daniel -
Hallo,
Ich hab eine MySql Datenbank, die Text als ISO speichert (halt das übliche).
das find' ich nicht üblich :-)
Die will ich schon länger auf UTF-8 umstellen, aber ich finde dazu nur Lösungen mit extra php-Scripten, die ich mir dazu laden müsste. Ich glaube allerdings immer noch an einen MySQL-Befehl der das kann.
ALTER TABLE kann das. Beachte die Warnung im Kasten und vergiss nicht, vorher ein Backup Deiner Tabelle zu erstellen.
Freundliche Grüße
Vinzenz
-
Hi!
Die Ein/Ausgabe der Daten im Browser habe ich alles schon angepasst. Neue Texte gehen richtig rein und kommen auch richtig wieder raus, was man an Umlauten sieht. Ein Problem hab ich nur noch mit den alten Texten, die sind jetzt (d.h. bei Ausgabe als utf-8) verhunzt.
Bitte genauer beobachten und beschreiben. Wie sieht bei dir "geht rein - kommt raus" aus? mysql_set_charset() oder SET NAMES führst du aus? Wie zeigt der phpMyAdmin die alten und neuen Werte an. Bitte mit Beispiel und nicht nur als "verhunzt" beschrieben, sonst kann man nur allgemein antworten, dass du es "enthunzen" musst und nicht genau wie du da vorgehen musst.
Ich bräuchte also nur noch einen Befehl der Art
UPDATE Tabelle SET Spalte = machUtf8AusIso(Spalte)
Gibts da echt nix?Es gibt keine "mach-was-ich-meine"-Funktion. Je nach konkretem Zustand muss man konkret verfahren, um ein konkretes Ziel zu erreichen.
Lo!
-
hi,
[..] Ein Problem hab ich nur noch mit den alten Texten, die sind jetzt (d.h. bei Ausgabe als utf-8) verhunzt.
Hmm, hast Du jetzt da Zeichen mit verschiedenen Kodierungen in _einer_ Tabelle?
Hotte
--
Morgen gehts weiter.... -
Hallo ihr, auf eure Antworten hin ein paar weitere Infos.
Die Funktion mysql_set_charset() kannte ich bisher noch nicht. Die hat mir schrittweise die Augen geöffnet und ich glaube inzwischen hab ich auch tatsächlich kapiert, was da wie passiert und warum ich welche richtigen oder falschen Ausgaben erhalte.
In der Spalte war bisher schon alles korrekt in UFT8 eingetragen. Die scheint das selber konvertiert zu haben, die gelieferten Daten waren ja in ISO und die DB hat die Eingaben auch als solche interpretiert und korrekt nach UTF8 umgewandelt.
Was nicht funktioniert hatte waren meine neuen Tests, bei denen ich die Daten in UTF8 geliefert habe. Aber auch die sind jetzt wieder in Ordnung, nachdem ich mysql_set_charset() entdeckt habe und damit die DB wieder weiß was sie bekommt. Ich hatte also unwissend Glück :-)Vielen Dank an alle die was dazu wussten!
-
hi,
In der Spalte war bisher schon alles korrekt in UFT8 eingetragen. Die scheint das selber konvertiert zu haben, die gelieferten Daten waren ja in ISO und die DB hat die Eingaben auch als solche interpretiert und korrekt nach UTF8 umgewandelt.
Nur mal Interessehalber: Was ist das für eine DB, die Du da hast, die Zeichen mit ISO-Kodierung nach utf-8 umwandelt?
Hotte
-
Hi!
Nur mal Interessehalber: Was ist das für eine DB, die Du da hast, die Zeichen mit ISO-Kodierung nach utf-8 umwandelt?
Das ist MySQL. Was würdest du machen, wenn du Daten als Latin1 deklariert übergeben bekommst, die Felder zum Ablegen aber als UTF-8 konfiguriert sind?
Lo!
-
Hi!
Nur mal Interessehalber: Was ist das für eine DB, die Du da hast, die Zeichen mit ISO-Kodierung nach utf-8 umwandelt?
Das ist MySQL. Was würdest du machen, wenn du Daten als Latin1 deklariert übergeben bekommst, die Felder zum Ablegen aber als UTF-8 konfiguriert sind?
Erstmal den Unterschied zwischen Deklaration und Kodierung klären ;-)
Hotte
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Ja ich muss schon zugeben dass das vielleicht nicht so wirklich korrekt beschrieben war.
Aber ich erklärs mir inzwischen so: Die Spalte hatte schon immer UTF eingestellt. Mangels Umstellung der Connection auf UTF wurden die Daten zufällig in dem Format interpretiert, in dem sie auch vorlagen. Deswegen steht schon die ganze Zeit das richtige in meiner Spalte, nur war mir bisher nicht bewusst warum.Oder worauf wolltest du genau raus?
-
Hi!
Die Spalte hatte schon immer UTF eingestellt. Mangels Umstellung der Connection auf UTF wurden die Daten zufällig in dem Format interpretiert, in dem sie auch vorlagen. Deswegen steht schon die ganze Zeit das richtige in meiner Spalte, nur war mir bisher nicht bewusst warum.
Oder worauf wolltest du genau raus?Nun, hotti verwunderte es, dass die vom PHP-Script kommenden ISO-8859-1-kodierten Daten, die MySQL aufgrund einer individuellen Verhandlung oder in deinem Fall einem Defaultwert gemäß ebendieser Kodierung interpretiert und sie nun beim Ablegen in ein mit UTF-8-konfiguriertes Feld nach UTF-8 umkodiert. Dieses Verhalten ist zwar nicht unbedingt allen Anwendern bekannt, weswegen ich eine Verwunderung verstehen kann, aber im Grunde genommen ist das Verhalten logisch und alternativlos.
Lo!
-
Mich würde trotzdem noch interessieren ob es in MySql Funktionen gibt, mit denen ich zwischen Kodierungen wechseln kann. Also falls ich die Spalte von einer Kodierung in die andere bringen will, muss ich da dann wirklich mit Export/Import arbeiten, oder gibts da was elegantes?
-
Mich würde trotzdem noch interessieren ob es in MySql Funktionen gibt, mit denen ich zwischen Kodierungen wechseln kann. Also falls ich die Spalte von einer Kodierung in die andere bringen will, muss ich da dann wirklich mit Export/Import arbeiten, oder gibts da was elegantes?
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).
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).
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.
Ein "alter table ..." übrigens würde an solchem Zeichensalat auch nichts ändern. Sowas zu bereinigen ist meistens Handarbeit, zumindest da, wo mit einer entsprechenden Klause es nicht mehr möglich ist, die Records nach Zeichenkodierung rauszufischen. Und sofern es Zeichen gibt, die sowohl iso- als auch utf-kodiert sein können, was bei den deutschen Umlauten gegeben ist. äöüÄÖÜß kann ohne Informationsverluste von latin nach utf und umgekehrt kodiert werden. Es gibt aber auch (viele ) Zeichen bei denen das nicht geht.
Hotte
--
;-
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!
-
hi,
[..] Wenn der Inhalt aus welchem Grund auch immer nicht mit der Deklaration übereinstimmt, gibt es natürlich Fehler oder Datenverlust.
Genau darum gehts ja hier ;-)
Und so wies aussieht, isses gar kein Problem innerMySQl. Manchmal sitzt das Problem auch vor dem Rechner.
Viele Grüße,
Horst--
3;
-
-
-
Hi!
Mich würde trotzdem noch interessieren ob es in MySql Funktionen gibt, mit denen ich zwischen Kodierungen wechseln kann. Also falls ich die Spalte von einer Kodierung in die andere bringen will, muss ich da dann wirklich mit Export/Import arbeiten, oder gibts da was elegantes?
Ja, natürlich. Je nach Situation gibt es unterschiedliche Möglichkeiten. Wenn der Inhalt eines Feldes nur umkodiert werden soll, so gibt es entsprechende Syntax im "ALTER TABLE"-Statement (geht komfortabler mit dem phpMyAdmin, weswegen ich die Syntax nicht aus dem Hut weiß). Wenn der Inhalt beim Abfragen in einer anderen Kodierung benötigt wird, so gibt es die Funktionen CONVERT und CAST. Mit Abfragen meine ich jetzt nur das reine Abfragen mit einem SQL-Statement mit anschließender Weiterverarbeitung im MySQL-Server und nicht den Transport zum Client.
Das dürften die zwei wichtigsten Situationen sein, obwohl man mit denen auch selten in Berühung kommen wird.
Lo!
-
-
-
-
-
-
-