Umlaute kaputt

UTF-8 ist sowieso die dümmste Erfindung aller Zeiten. Die Chinesen haben das schlauer angestellt, die haben ein UTF, das abwärtskompatibel mit ihrem alten Codepage-Standard ist. Aber Europa hat mal wieder verpennt, ein Latin1-kompatibles Encoding auf die Reihe zu bekommen.

Vollkommen OT: nach dem Streicheln aller Bytes empfehle ich einen Besuch bei Hedda Gabler. https://www.deutschestheater.de/spielplan/hedda_gabler
Ich war heute da, der Applaus der mehrheitlich anwesenden Frauen war eher spärlich. Ich fand es genial.

@Joe: Zu welcher Codepage moechtest du denn kompatibel sein? CP437, CP850, iso8859-1 oder doch lieber CP1251? Oder vielleicht die Euro-erweiterten, also CP858 oder iso8859-15? Oder die paar anderen komisch, die man fuer Deutsch auch noch benutzen koennte? (Oder MacRoman, IBM-EBDIC-Codepages oder oder oder…?)

Die Chinesen hatten nur einen uebergreifenden Standard, da war das einfacher. Und deren Unicode war auch nicht unbedingt beliebt, weil es “gleiche” Zeichen aus beiden chinesischen und der japanischen Kanji-Schreibweise (und evtl. aelteres Vietnamesisch?) vermischt, die dann je nach Font und Spracheinstellung unterschiedlich dargestellt werden.

Oder moechtest du lieber einen umschaltbaren Zeichensatz, wie Big5 ? UTF32 ist wenigstens stateless (UTF8 nicht, aber der state steht maximal drei Bytes vorher).

Ich würde es so lassen. 😀

Das ist das Binnen-I Equivalent für Nerds… 😉

…pardon: Nerds_Innen%Außen

^^

_Innen%Außen^^ lol …ich brauch nen Kaffee! X-D

@Joe

Es gibt Latin1..16, welche gleich codiert werden. Latin1 ist schon im Vorteil, denn es ist identisch mit den ersten 256 Zeichen des Unicode-Zeichensatzes.

Ich benutze seit Jahren für alles und jedes UTF-8 und bin sehr zufrieden damit. Warum ist das nun die “dümmste Erfindung aller Zeiten”?

Die Chinesen haben ein eigenes UTF? Das wußte ich nicht. UTF ist von 0 bis 127 mit ASCII kompatibel; über die 127 hinaus hatte doch früher jedes Land sein eigenes Süppchen gekocht. Warum jetzt jedes Land oder jeder Kontinent sein eigenes UTF haben soll, erschließt sich mir nicht. Das unterläuft doch das Vorhaben von UTF, universell zu sein – daher ja auch das U am Anfang.

Hübsch sieht das aus. Als würde man Mails von merkwürdigen Mac-Clients bekommen. Viel Spaß beim Reparieren! 😉

Regex, 2zeiler Perlskript und alles ist gut 🙂

@Joe
Wie willst du das denn besser machen?
UTF-8 ist zu ASCII(druckbare Zeichen) abwärzkompatibel – wie willst du Latin-1 (oder besser Latin-9) mit UTF-8 (variable Zeichenlänge) kompatibel machen?

@Joe

Und wieso gerade Latin-1? Latin-2 bis 16 ignorieren wir einfach? Mit mehreren zugleich abwärtskompatibel zu sein geht nicht.

@Joe:
Lass mich raten: Du hast exakt null Ahnung, wie Multibyte-Kodierungen, zu denen UTF-8 und die diversen CJK-Familien gehören, funktionieren. Aber schön, dass wir mal drüber geredet haben.

@Joe, dir ist schon klar, dass auch UTF-8 “abwärtskompatibel” zu ASCII ist? Das macht auch deutlich mehr Sinn, als sich an latin1, latin2, cpXXX oder sonsteiner anderen regionalen Codepage zu orientieren, denk ich. Sehe nicht, wie die Abschaffung/Vereinheitlichung der elenden regionalen Codepages die dümmste Erfindung aller Zeiten sein soll. Leider ist das Umwandeln, insbesondere wie hier mit einer wilden Mischung verschiedener Zeichensätze, immer noch ein abartiger Krampf.

@Danisch, was genau ist denn da passiert? Sollten die Dinge nicht in einer einheitlichen Kodierung zumindest in der DB vorliegen und sich relativ einfach (theoretisch …) konvertieren lassen? Dass es so nicht lief, sehe ich ja, mich würden aber Details interessieren 😉

@other joe:

> @Danisch, was genau ist denn da passiert?

Das habe ich gestern auch schon heftig überlegt.

Wir haben gestern einen heftigen Sprung von Ubuntu 10.04 LTS auf 14.04 LTS gemacht und dabei natürlich MySQL und PHP auf neuere Stände gebracht (WordPress aktualisiere ich direkt immer wieder). Dass das innerhalb weniger Minuten ging, lag daran, dass wir die neue (virtuelle) Maschine schon seit einiger Zeit aufbauen und die schon betriebsbereit herumstand, wir nur noch mal schnell die Daten aktualisiert haben.

Allerdings habe ich dabei einen erheblichen Fehler gemacht.

An sich habe ich die Migration vorher schon getestet und dachte deshalb, dass sie schnell über die Bühne geht. Ich hatte aber nicht genau genug getestet, weil ich in einem Skript eine Fehlerausgabe übersehen hatte.

Ich dachte zunächst, es genügt, die Daten einfach mit einem anderen Zeichensatz zu dumpen. Als das nicht funktioniert hat, dachte ich, ich könnte (wie von jemand anderem hier vorgeschlagen) den ganzen Kram einfach durch den Konverter jagen, was aber auch nicht ging, denn es sind von dem Problem nicht nur Umlaute betroffen, sondern auch noch andere Zeichen wie Hochkomma usw., und wenn man die einfügt, geht die ganze SQL-Syntax hops, dann kann man das nicht mehr reinladen.

Das Problem besteht eigentlich aus (mindestens) drei Teilen:

• Das Blog (und damit die Datebank) läuft ununterbrochen seit 2006. Zwar gab es in dieser Zeit viele Versionen von MySQL, PHP und WordPress, aber die waren nicht alle Zeichensatz-sauber, teils konnten die das auch nicht unterscheiden. Deshalb findet sich in der Datenbank beides, nämlich ISO-8859-1 und UTF-8. Man kann deshalb nicht einfach den ganzen Dump durch den Konverter jagen, weil manche ISO-8859-1-Zeichen als Teil von UTF-8-Zeichen vorkommen.
• Anscheinend ist da auch mal bei irgendwelchen WordPress-Upgrades (die ja oft die Datenbank umbauen und aktualisieren) einiges schief gegangen, ich habe nämlich mitunter sogar Worte gefunden, bei denen innerhalb eines Worts ISO-8859-1 und UTF-8-Zeichen vorkamen.
• Und als ob das noch nicht Mist genug ist, sind ja noch die Spam-Kommentare drin, und die enthalten jedweden Müll, auch japanische, russische, chinesische Zeichensätze, und das über eine ISO-8859-1-Konvertierung laufen zu lassen, geht ganz schief.

Ich dachte gestern abend noch, ich könne das mit einem Skript korrigieren, merkte dann aber, dass ich da vom Hundersten ins Tausendste komme, und immer mehr Sonderfälle habe. Hab mir gestern abend die Finger wundgescripted, und als ich dachte, jetzt hab ich’s halbwegs, stimmte die Syntax nicht mehr, und die Datenbank hat’s abgelehnt, weil durch irgendwelche Konvertierungen Hochkommas reingekommen sind.

Weil ich aber Zeitnot hatte und die Maschine auch nicht allzulange unten lassen konnte, habe ich mich für die peinliche Variante entschieden, und die Datenbank unverändert übertragen, um sie dann Montag oder Dienstag Artikel- und Kommentarweise durch eine Korrektur zu schieben, anstatt alles auf einmal und mit SQL-Syntax.

Der Grund, warum man derzeit falsche Zeichen sieht, ist verblüffend: Es sind keineswegs UTF-8-Zeichen, die als Latin dargestellt werden (auch wenn’s so aussieht), sondern die Datenbank enhält bereits weit überwiegend UTF-8 und damit die richtigen Zeichen, hält sich aber den Einstellungen nach für eine Latin1-Datenbank. Einfach umstellen geht nicht, weil die UTF-8-Syntaxprüfung dann blockiert.

Die Datebank enthält also UTF-8, hält es aber für LATIN1 und will es nochmal von LATIN1 nach UTF-8 wandeln. Aus einem Umlaut werden damit sogar 4 Byte, die zwei UTF-8-Zeichen zeigen, die dann so aussehen, als hätte man ein UTF-8-Zeichen als LATIN angezeigt, tatsächlich sind es aber wirklich zwei UTF-8-Zeichen.

Das „Problem” ist eben, dass das Blog jetzt erstmals auf einer MySQL- und PHP-Version läuft, die korrekt mit den Zeichensätzen umgehen, aber die Datenbank halt falsche Zeichentypen enthält, und die Software deshalb alles nach UTF-8 konvertiert, obwohl vieles bereits UTF-8 ist.

Da hab ich noch was zu tun, bis das alles sauber auf dem richtigen Stand ist.

Wo ist das Problem mit UTF-8? Ich find die Kodierung prima, da sie Weltweit zum Einsatz kommt.
Probleme mit Zeichenkodierung bekomme ich nur bei PHP Projekten mit. Woher die Probleme dort kommen weiß ich nicht, da ich mit PHP eigentlich nichts zu tun habe. Ich ärgere mich nur regelmäßig über neu erstellte Websiten auf Basis eines PHP CMS die mit ISO-8859-1 kodieren. Wundern braucht man sich dann nicht wenn dort dann etwas schief geht (€ Zeichen z.B.). Das man ein bestehendes System nicht umstellen möchte verstehe ich ja. Aber welchen Grund hat man heute noch die alte Kodierung einzusetzen?

Ist lange her, daß ich mal mit PHP gearbeitet habe. Um mal fix was zusammenzuhühnern, mag es eine feine Sache sein, für auch nur wenig komplexere Projekte, die man im Team bewältigt, ist es eine Katastrophe. Ich hasse dynamische Sprachen eh wie die Pest, will aber nicht abdriften.

Ich kann mich erinnern, daß wir seinerzeit auch erhebliche Probleme mit PHP und UTF-8 hatten, weil die String-Funktionen darauf überhaupt nicht vorbereitet waren. Möglicherweise ist das in neueren PHP-Versionen anders. Ich weiß es nicht.

Ich würde, glaube ich, einen Dump machen, irgendwas mit `sed’ versuchen, dabei auch Hochkomma verdoppeln, um das SQL nicht zu zerbröseln. Und natürlich den Output ordentlich testen.

Jetzt bin ich etwas verwirrt. Die DB steht also auf “Latin”, und das willst Du so lassen? Bist Du nicht Herrscher über die DB, daß Du das selbst einstellen kannst? Ich nehme erstmal alles zurück und behaupte das Gegenteil, nachdem Du ja, wie Du schreibst, den Skriptansatz schon hinter Dir hast.

@Schwärmgeist: Nein, natürlich will ich das nicht so lassen.

Mir hat nur gestern abend einfach noch die Zeit für Experimente gefehlt, weil ich 1,5 Stunden damit verplempert habe, die Datenbank am Stück konvertieren zu wollen und dadurch erst drauf gekommen bin, worin eigentlich das Problem liegt. Ich hatte aber gestern abend einfach noch ganz wichtige unaufschiebbare andere Sachen zu erledigen.

Das Problem ist, dass ich nicht einfach mal eben so die Datenbank umschalten kann, sondern das erst an einem anderen System testen muss. Ich hatte irrtümlich angenommen, dass ich einfach den mysqldump konvertieren kann, das ging aber nicht.

> Bist Du nicht Herrscher über die DB, daß Du das selbst einstellen kannst?

Klar bin ich. Aber es wird nicht richtiger, wenn die Datenbank noch mehr Fehler macht, indem sie Daten nicht nur ausgibt, sondern konvertiert. Wie gesagt, Herrschen braucht auch Zeit, und die hatte ich gestern und heute nicht mehr.

Bedenke bitte, dass ich noch andere Sachen zu tun habe.

Ja, die Zeichsätze. Was mich das immer ärgert. Auf jedem Computer anders. Ein paar Programme sind da sogar eigenwillig. Als ob man nicht einen Zeichensatz mit allen Unicodezeichen hinbekommen könnte.

Ich hätte da noch einen Vorschlag, was das Problem sein kann. Ubuntu 14.04. Ubuntu wird mit jeder Versionsnummer schlechter. Ich habe den Müll aus Zeitgründen auch noch und beim runterfahren kommen die Meldungen mal richtig, mal mit genau den selben Zeichenfehlern wie dein Blog im Moment.

Da hab ich noch was zu tun, bis das alles sauber auf dem richtigen Stand ist.

Bis es soweit ist darf sich FoxReplace ein wenig nützlich machen 🙂

{
“input”: “ü”,
“inputType”: “text”,
“output”: “ü”,
“caseSensitive”: true
}

Es sollte doch reichen, die wenigen UTF-8-Sequenzen zu reparieren, die zu den ehemaligen deutschen Umlauten korrespondieren. Der Rest kann doch ruhig kaputt bleiben, egal wie er entstanden sein mag.

Kein Problem. Leser dieses Blogs werden ihren Wortschatz dazu verwenden, ihre Kommentare in Zukunft umlautfrei zu verfassen. Der Blogchef selbst wird es, je nach Umfang der Texte, etwas schwerer haben; aber bekanntlich kommt das Wachstum mit den Aufgaben.

@Hadmut, wenn natürlich alles durcheinander ist, musst du da per Hand ran. Ansonsten kann ich dir nur diese Übersicht empfehlen.
http://wiki.typo3.org/UTF-8_support#Convert_an_already_existing_database_to_UTF-8

Das Problem taucht in LAMP Umgebungen immer wieder auf, weil die DB oft auf latin1 steht. Zusätzlich ist oft auch das Connection Charset falsch gesetzt (falscher Default in PHP).
Jetzt kann es passieren, dass die DB latin1 ist und die Connection utf-8. Dann konvertiert die DB die Daten nach utf-8. Dumm ist dann nur, wenn die Daten in der DB schon utf-8 sind und nicht latin1. Dann sind die Daten doppelt encodiert.
Katastrophal ist, wenn an einem der Werte zwischendurch gedreht wird, (meist das Connection Charset). Dann hat man gemixte Daten in der DB.
Ich vermute das genau dies hier passiert ist. WordPress hat irgendwann gesagt, wir machen nur noch UTF-8 und hat das Connection Charset umgestellt. Seitdem sind die Daten doppelt encodiert.

Ohje. Klingt fast, als sollte man lieber nochmal von vorne beginnen. Ich hätte ja keine Lust, da nun manuell artikelweise durchzugehen. Dachte mir gerade aber mal, das Problem kannst ja nicht nur du haben und fand diesen Blog-Eintrag: http://joemaller.com/1328/fixing-mixed-encoding-mysql-dumpfiles-with-wordpress/

das Thema “DB Dump regexen” zwecks Zeichensatzkonvertierung haben doch bestimmt schon 1500 andere Etnwickler gehabt und gelöst. Ich würde erwarten, das Gockel da ziemlich schnell entsprechende Code-Snippets liefert.

Leute, das ist kein Weltuntergang und ich brauch auch keine Hilfe oder fremden Code.

Ich brauche nur Zeit, um mich überhaupt mal dransetzen zu können.

dann sind wir ja beruhigt 😉 viel erfolg!

Ich würde das ganz pragmatisch sehen:

Hier lesen ja intelligente Leute mit – zumindest meistens. Die sollten die Codekonvertierung “on the fly” im Kopf beherrschen, so daß es für die meisten kein problem sein dürfte, die Artikel und Kommentare weiterhin zu verstehen. 🙂

Daher ist imho das “Umlauteproblem” nur ein recht geringes mit niedriger Priorität, auch wenn es unschön aussieht.

Alles kein Problem!
Alle Probleme mit codepages sind gelöst!

Letztens wurde doch 7- Bit ASCII zum Internetstandard erklärt!!1elf Ich weiss nicht was ihr alle für Probleme habt?

http://www.heise.de/ix/meldung/7-Bit-ASCII-ist-offizieller-Internet-Standard-2538085.html

Etwas ernsthafter: Gibt es dafür keine Tools? Du dürftest ja nicht der einzige sein, der eine alte wordpress Datenbank übersetzen muss, Hadmut.

Es ist doch ziemlich peinlich, daß die wordpress Macher nicht von Anfang am auf UTF-8 gesetzt haben. Sollte sich doch schon herumgesprochen haben, daß man nicht vom Rand der Erdscheibe fällt wenn man die US of A verlässt als die erste Version erschien?