Hallo Peter, nun habe ich es anscheinend auch verstanden. Der Hinweis mit der doppelten UTF-8 Codierung hat mir dann die Augen geöffnet und Dank Deiner Links habe ich das Problem nun gelöst.
Ich habe nun zunächst mit diesem Befehl einen Dump gemacht: mysqldump -u[user] -p[pw] --default-character-set=latin1 [db] > dump.sql Diesen dann mit vi bearbeitet: vi dump.sql :%s/latin1/utf8/ :wq Nun in der TYPO3-Config gesetzt: setDBinit = SET NAMES utf8; In der MySQL-Konsole die Datenbank gelöscht: DROP DATABASE [db]; Zum Schluss den Dump wieder eingespielt: mysql -u[user] -p[pw] usr_web1683_1 < dump.sql Und - tada! phpMyAdmin zeigt mir korrekte Umlaute, Frontend- und Backend der Webseite funktioniert. Auf Deutsch und Chinesisch! Alle Zeichen werden korrekt angezeigt. Puh. Vielen Dank für Eure vielen Hinweise. Nun kann ich mich daran machen, das Update auf die 6.2 anzugehen ;-) Viele Grüße, Lars Brinkmann Am 11. Februar 2015 um 15:55 schrieb Peter Linzenkirchner <li...@lisardo.de>: > Hallo, > > das hier: > >> Bildschirm komische Sonderzeichen statt der Umlaute: >> "... GmbH übernimmt ..." > > ist absolut eindeutig: > https://www.liveconfig.com/de/kb/11 > Siehe in der Mitte: > > ö ö > ü ü > > das sind doppelt utf8-kodierte Daten, und die stehen so in der Datenbank. > Punkt. > > Hier ist eine Erläuterung, wie das Ganze entsteht: > > http://www.gerd-riesselmann.net/softwareentwicklung/php-und-utf-8-eine-anleitung-teil-1-mysql/ > > Ich zitiere: > > "Dröseln wir jetzt mal auf, was da genau passiert ist: > > • Wir sind auf einem Linux-System mit UTF-8 als Zeichensatz. Die > Eingabe „üüü“ wird daher in die ANSI-Zeichen „üüü“ umgesetzt. > • Der MySQL-Client erwartet Latin1, liest also nicht „üüü“, sondern > eben „üüü“. > • Und dies schickt er auch an den Server, und zwar mit der Anmerkung, > es handele sich hier um Daten im Format Latin1. > • Der Server wiederum weiß, dass die Tabelle UTF-8 benutzt und > konvertiert entsprechend die ankommenden Daten von Latin1 nach UTF-8. Er > speichert also nicht ein UTF-8-"ü", sondern UTF-8-„üüü“ > • Wir fragen die Tabelle ab und verlangen dabei das Format Latin1. > • Der Server gibt uns die Daten zurück, konvertiert aber vorher von > UTF-8 nach Latin1, weil der Client das so wollte. > • Der Client erhält „üüü“ als ANSI und druckt das aus. > • „üüü“ werden auf dem Bildschirm als „üüü“ angezeigt." > > wie in meiner letzten Mail beschrieben - habe ich mir also nicht ausgedacht. > Das ganze hat _nichts_ mit TYPO3 zu tun, entscheidend ist ausschließlich die > Konfiguration der Datenbank-Verbindung. Und: TYPO3 konvertiert nicht, an > keiner Stelle! Das macht ausschließlich die Datenbank, und zwar auf Basis der > Datenbank-Verbindung. > > Und so bekommt man diesen Fehler wieder raus: > > https://books.google.de/books?id=xayL0Ckq60kC&pg=PT89&lpg=PT89&dq=typo3+doppelt+utf8&source=bl&ots=pNrxO_ZbLB&sig=QuUdquSAoMHKsjHUKNhx6EcNp8E&hl=de&sa=X&ei=MWjbVLjDLpLmaIWzgugM&ved=0CCkQ6AEwAQ#v=onepage&q=typo3%20doppelt%20utf8&f=false > > https://ducrot.wordpress.com/2010/06/04/utf-8-umstellung-oder-reparatur-eines-vorhandenen-typo3-systems/ > > http://mainboarder.de/artikel/5096/typo3-utf-8-konvertierung-wenn-herkoemmliche-wege-fehlschlagen.html > > Und so weiter. Das ist ein übliches Problem bei älteren TYPO3 Installationen, > das automatisch und zwangsläufig durch forceCharset = utf-8 bei fehlendem > setDBinit = "set names utf8" entstanden ist, wenn die Datenbank-Verbindung > per Default auf latin ssteht, was früher immer der Fall war. > > Gruß > Peter > > > -- > Xing: http://www.xing.com/profile/Peter_Linzenkirchner > Web: http://www.typo3-lisardo.de > Facebook: http://tinyurl.com/lisardo-multimedia > > _______________________________________________ > TYPO3-german mailing list > TYPO3-german@lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german -- brinkmann.l...@gmail.com _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
