ISO-UTF8 in verkorkster Datenbank korrigieren

Exportieren, iconv über den SQL-Dump, wieder importieren ;D

Backup zurückspielen, und die ganze Migration nochmal mit richtigen 
Codepagesetings machen.

Allerdings: ä ist bei normalen ASCII Codepages 0xC3A4:

ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP008 
19.pdf

In UTF8 ist 0xC3A4 aber auch ein ganz normales ä.
Offensichtlich ist also wohl nur Dein Anzeigeprogramm Kacke (falsche 
Codepageeinstellung), und nicht die Daten selbst.

Die Sache hinterher reparieren ist nie gut, Besser wäre das von vorn 
herein richtig zu machen.
Geb uns doch ein Paar Stichpunkte, dann können wir dir ggf. helfen das 
beim Nächsten man besser zu machen.

So z.b.
Was für eine Datenbank verwendest du, in welcher Sprache ist die 
Software die du benutzt, Hast du die Möglichkeit die 
Datenbank-Verbindungseinstellungen zu der Software anzupassen?
Und was für software ist das überhaupt? :)

matthias_saihttam schrieb:
> und das dann
> Fehler in Umlauten automatisch erkennt

Was ist ein "Fehler in Umlauten" und wie würde bei Dir die "korrigierte" 
Version aussehen? Das müsstest Du erstmal genau definieren, dann könnte 
jemand speziell für Deinen Fall ein Tool schreiben.

matthias_saihttam schrieb:
> Da ich bisher aber keine positive Antwort bekommen habe,

iconv wurde schon genannt.

>Mit positiver Antwort meinte ich eine Antwort auf die Frage, ob es ein
>Tool gibt, das eine Datenbank online prüft und korrigiert.

Sowas kann es nicht geben, denn woher weis denn das Tool, was richtig 
und falsch sein soll. Da müsste man das Tool ja erstmal "anlernen" durch 
entsprechende Konfiguration.

Aber wie ich oben schon schrieb, ist zumindest das beanstandete ä 
offensichtlich richtig in der db drin, denn 0xC3A4 ergibt in utf8 ein ä.

Exportier' es doch einfach als Text und lass iconv laufen. Hab ich schon 
gemacht, funktioniert prima und dauert fünf Sekunden. Aber gut, wenn du 
das nicht willst ...

Mit "prüfen" ist da nix, du musst manuell Quell- und Zielkodierung 
angeben.

Kaputt ist m.E. bei dem was du da zeigst auch nichts. Das sind nur 
(korrekte) Daten, die im falschen Encoding interpretiert werden.

Das Problem mit UTF8 vs ISO kann aber recht kompliziert werden, 
schliesslich kann man neben der Speicherart der Tabelle an sich auch den 
Modus der Datenbankverbindung auch (falsch) setzen. Ob es richtig in der 
DB steht, sollte man mit einem über alle Zweifel erhabenen Tool prüfen 
(z.B. phpmyadmin by MySQL). Daneben gibts dann noch Oracle, dass für 
UTF8 eine ganz eigene Codierung will.

Und wenn Perl mitspielt, hat man eh viel Arbeit vor sich... Perl ist 
toll, aber die Automatismen für UTF8/ISO sind eine einzige Katastrophe. 
Und zwar dann, wenn die Strings aus verschiedenen Quellen kommen (DB, 
Ausgaben von Programmen, aus XML-Daten via XMLin, aus CGI-Parametern, 
etc.). Das kann soweit gehen, dass mit dem DB-Handling alles in Ordnung 
ist, aber die Ausgabe eines echten UTF8-Zeichens via print() auf eine 
UTF8-Konsole nur Schrott ergibt. Oder andersrum mit print-Debugging 
alles gut ist, aber in der DB Müll landet, obwohl da auch alles auf UTF8 
steht. Der Knaller sind dann via print identisch aussehende Strings mit 
korrekten Umlauten, die in der DB einmal richtig und einmal falsch 
landen. Da helfen dann nur noch Data::Dumper und Data::Hexdumper...

>(z.B. phpmyadmin by MySQL). Daneben gibts dann noch Oracle, dass für
>TF8 eine ganz eigene Codierung will.

Eine ganz eigene Codierung? Wie das? UTF8 ist UTF8, und wird auf 
www.unicode.org definiert.

> UTF8 ist UTF8

He, das ist Oracle, die sind bei MS ihr eigener Standard, ist ja auch 
bei SQL so... Google mal nach AL32UTF8 vs. UTF8.

@ Georg A. (georga)

>> UTF8 ist UTF8

>He, das ist Oracle, die sind bei MS ihr eigener Standard, ist ja auch
>bei SQL so... Google mal nach AL32UTF8 vs. UTF8.

http://www.oracle.com/technetwork/products/globalization/twp-appdev-unicode-10gr2-129234.pdf

Auch wenn es AL32UTF8 heist, ist nur der Name eine Erfindung von Oracle. 
Der Inhalt dagegen entspricht ganz einfach dem Unicodestandard einer 
bestiommten Version.

Die "subtle" Unterschiede sind aber so, dass es bei mir nur mit dem AL32 
geht und ich habe keine asiatischen Zeichen... Aber egal, wird OT. Es 
ist jedenfalls überall ein grosses Mienenfeld ;)

Oops, bin erkältet.