Hallo, immer wieder habe ich Probleme dass bei einem Webshop oder Forum nach einer Umstellung oder Migration die Daten falsch in der Datenbank sind. Also die Umlaute meine ich. Gibt es da kein Tool, das man einfach über eine Datenbank laufen lässt und es korrigiert dann alle Umlaute richtig? Also aus einem ä -> ä matthias
Warum stellst du den Zeichensatz nicht vorher mal richtig ein? Ich meine, wenn dir das offenbar öfter passiert, sollte doch irgendwann mal das Lämpchen im Kopf aufleuchten, bevor du deinen Import/deine Migration startest.
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.
:
Bearbeitet durch User
Was ist überhaupt richtig? Zu Zeiten des Internethypes hatten wir noch die diversen ISO und Microsoft Codes. Heutzutage machen wir alles in Unicode. Wenn du nun ein 10 Jahre altes System umstellst, musst du dich entscheiden, alte Codes beibehalten oder auf Unicode umstellen?
Noch einer schrieb: > Microsoft Codes Die waren nie richtig. Das hatte MS nur durch seine Dominanz in den Markt gedrückt (und noch vielen anderen Schrott dazu; das gute alte <marquee> etwa).
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? :)
Ich wollte wissen, ob es ein Tool gibt (zum Beispiel PHP), das man über eine bestehende Datenbank (oft mySQL) laufen lassen kann, und das dann Fehler in Umlauten automatisch erkennt und diese automatisch korrigiert. Bei Zweifel ggf. mit Nachfrage. Deshalb stelle ich diese Frage hier im Forum, weil ich gehofft habe, jemand kennt so eines. Da ich bisher aber keine positive Antwort bekommen habe, und das Forum ja recht gut besucht ist, gehe ich mal davon aus, es gibt keines. Also keines, das weit bekannt ist.
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.
>>Da ich bisher aber keine positive Antwort bekommen habe, >iconv wurde schon genannt. Ich kenn iconv. Mit positiver Antwort meinte ich eine Antwort auf die Frage, ob es ein Tool gibt, das eine Datenbank online prüft und korrigiert.
>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 ä.
>ist zumindest das beanstandete ä offensichtlich richtig
Würde ich erstmal auch so sehen. In Summe bekommt man am wenigsten
Probleme, wenn man alles in Unicode macht.
Aber hier scheint ja das Problem zu sein: Neue Datenbank wird in UTF8
angelegt, Datenimport konvertiert in UTF8, aber die Forensoftware kommt
damit nicht zurecht.
Was tun - Forensoftware umkonfigurieren oder Datenbank in ISO-Code
anlegen? Es gibt kein KI-Tool, was diese Frage entscheiden kann.
matthias_saihttam schrieb: > Mit positiver Antwort meinte ich eine Antwort auf die Frage, ob es ein > Tool gibt, das eine Datenbank online prüft und korrigiert. Ziemlich sicher nicht. Ich habe so eine Software mal geschrieben für Ligaturen (die ersetzt Zeichenfolgen oder fügt Zeichen ein, z.B. für Schulschriften, und wird durch entsprechende Definitionsdateien konfiguriert), aber die bearbeitet Text-Dateien, wie vermutlich alle solchen Tools. Es ist sinnlos sowas für alle in Frage kommenden Datenbanken schreiben zu wollen. Man muss ja nicht nur die DB-Software kennen, sondern auch noch den Aufbau der speziellen Datenbank, damit man nicht versehentlich falsche Felder korrigiert. Das gilt wohl auch für PHP (oder irgendeine andere Sprache). Georg
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 ;)
Georg A. schrieb: > ist jedenfalls überall ein grosses Mienenfeld ;) Da muss man halt gute Mine zum bösen Spiel machen... Georg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.