Hallo Lars, wie ich dir schon geschrieben habe, du hast doppelt utf8-kodierte Daten in der Datenbank.
> > Server characterset: latin1 > DB characterset: latin1 > Client characerset: latin1 > Conn. characterset: latin1 => das ist der Übeltäter. > > Ok. Lasse ich mir also den Status der Tabelle anzeigen. Hier steht dann: > tt_content utf8_general_ci => das ist belanglos, damit wird nur die Sortierung geregelt. > Wenn ich mir dann mit SELECT bodytext FROM tt_content; den Inhalt in der > Konsole anzeigen lasse, erhalte ich eine Ausgabe mit korrekter Darstellung > der Sonderzeichen. Sogar die chinesischen Zeichen werden korrekt > angezeigt. Das liegt daran, dass deine Datenverbindung über das Terminal ebenfalls über Conn. characterset: latin1 funktioniert. Und damit MySQL dir die doppelt-utf8-kodierten Daten einmal nach latin konvertiert, womit utf8 bei dir ankommt. Also genau der gleiche Ablauf wie in TYPO3. > > Gehe ich nun mit pypMyAdmin auf diese Datenbank bekomme ich zunächst > einmal angezeigt: > Server-Zeichensatz: UTF-8 Unicode (utf8) > > Steht ja schon einmal im Gegensatz zu dem, was mir der Status in der > Konsole sagt. > > Lasse ich mir dann die Daten von tt_content anzeigen, stehen auf dem > Bildschirm komische Sonderzeichen statt der Umlaute: > "... GmbH übernimmt ..." phpMyadmin setzt die Connection auf utf8 - macht also das gleiche wie setDBiniti = utf8 in TYPO3. Damit erhältst du doppelt utf8 kodierte Daten. Die sehen ganz genau so aus, wie dein Beispiel oben. Also genau das, was TYPO3 in Version 6.2 draus macht. > > TYPO3 ist wie folgt konfiguriert: > > [SYS][UTF8filesystem] = 1 > [BE][forceCharset] = utf-8 > [SYS][setDBinit] = => das ist der Übeltäter, damit steht die Connection auf latin. > Im TypoScript ist KEIN Charset definiert, in der HTML-Ausgabe steht aber: > < meta http-equiv="Content-Type" content="text/html; charset=utf-8" / > da muss nichts stehen, [BE][forceCharset] = utf-8 regelt das alles. Damit wird utf8 im HTML und im Backend erzwungen. Wenn gleichzeitig setDBinit nicht gesetzt wird - oder die Datanbank-Verbindung nicht anderweitig auf utf8 gesetzt wird - ist das Ergebnis doppelt utf8 in der DB. > In dieser Konstellation zeigt TYPO3 4.5.39 die Seite mit allen > Sonderzeichen (deutsch/chinesisch) korrekt an. Nach einem Update auf > TYPO3 6.2.9 sind alle Sonderzeichen "kaputt". Jepp. Weil TYPO3 in Version 6.2 setDBinit automatisch auf utf8 setzt. Und damit eine uft8-Verbindung erzwingt, was bedeutet, dass die Daten auf dem Weg von der DB zu TYPO3 nicht nach latin kodiert werden. Und damit kommen bei dir doppelt utf8 kodierte Daten an. Ganz im Gegensatz zu TYPO3 4.5 ohne setDBinit: hier steht die Verbindung auf latin, und damit konvertiert MySQL die Daten _bevor_ es sie an TYPO3 schickt einmal nach latin. Doppelt utf8 wird so zu einfach utf8 und die Umlaute stimmen. > > Ich frage mich nun, wo erst einmal der grundlegende Fehler zu suchen ist? > Sind die Daten schon in der Datenbank falsch gespeichert? JA. Sie sind doppelt utf-8 kodiert. Und TYPO3 6.2 schaltet ausschließlich die Datenverbindung um. Und damit sendet MySQL andere Daten. > Aber warum > kann ich sie mir dann in der Konsole korrekt anzeigen lassen? Weil einzig und allein die Verbindung zur DB eine Rolle spielt. Und die ist die gleiche wie in TYPO3 4.5 - aber nicht wie in TYPo3 6.2, weil dort setDBinit die Verbindung umsetzt. > Und > warum kann 4.5 sie korrekt zeigen, 6.2 aber nicht? Unterschiedliche setDBinit-Einstellungen und damit unterschiedliche Datenverbindungen. Abhilfe: http://www.skom.de/Doppelt-UTF-8-kodierte-Daten-i.191.0.html Fall 6 ist dein Fall. 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
