[TYPO3-german] Falsche Umlaute in Datenbank und nach Update auf Webseite

Discussion:

Lars Brinkmann

2015-02-04 20:38:34 UTC

Hallo zusammen,

ich habe hier ein älteres Projekt, bei dem ich nicht mehr
nachvollziehen kann, wie die frühere Einrichtung bzw. Konfiguration
gewesen ist. Hier werden aber bei einem Update auf 6.2 falsche
Sonderzeichen/Umlaute angezeigt.

Ich beschreibe mal die Ausgangsposition.

Aktuell läuft die Seite auf TYPO3 4.5.39. Charset für Ausgabe steht
auf utf-8 und alle Texte werden korrekt ausgegeben, auch die Umlaute
bereiten keine Probleme.

Der Server-Zeichensatz lt. phpMyAdmin steht auf UTF-8, die Kollation
der Tabelle tt_content (und der anderen auch) steht auf
utf8_general_ci

Im Feld tt_content#bodytext zeigt mir phpMyAdmin aber die Texte schon
mit falschen Umlauten an:
"...QualitÃ¤tsanspruch..."

Ich gehe also mal davon aus, dass mein Problem schon besteht und nicht
erst durch das Update auf 6.2 entsteht. Die Frage ist nun, was kann
ich hier tun, um das Problem zu beseitigen?

TYPO3 ist wie folgt konfiguriert:

[SYS]setDBinit] = admin
[SYS]UTF8filesystem] = 1
[BE][forceCharset] = utf-8

--
***@gmail.com

Lars Brinkmann

2015-02-04 20:41:32 UTC

Permalink

Sorry, die Mail war noch nicht fertig....
setDBinit ist leer, da steht natürlich nicht admin drin.

Trage ich in setDBinit dieses hier ein: set names utf8;

Dann werden die falschen Umlaute auch im Frontend angezeigt.

Viele Grüße, Lars Brinkmann

Post by Lars Brinkmann
Hallo zusammen,
ich habe hier ein älteres Projekt, bei dem ich nicht mehr
nachvollziehen kann, wie die frühere Einrichtung bzw. Konfiguration
gewesen ist. Hier werden aber bei einem Update auf 6.2 falsche
Sonderzeichen/Umlaute angezeigt.
Ich beschreibe mal die Ausgangsposition.
Aktuell läuft die Seite auf TYPO3 4.5.39. Charset für Ausgabe steht
auf utf-8 und alle Texte werden korrekt ausgegeben, auch die Umlaute
bereiten keine Probleme.
Der Server-Zeichensatz lt. phpMyAdmin steht auf UTF-8, die Kollation
der Tabelle tt_content (und der anderen auch) steht auf
utf8_general_ci
Im Feld tt_content#bodytext zeigt mir phpMyAdmin aber die Texte schon
"...QualitÃ¤tsanspruch..."
Ich gehe also mal davon aus, dass mein Problem schon besteht und nicht
erst durch das Update auf 6.2 entsteht. Die Frage ist nun, was kann
ich hier tun, um das Problem zu beseitigen?
[SYS]setDBinit] = admin
[SYS]UTF8filesystem] = 1
[BE][forceCharset] = utf-8
--

--
***@gmail.com

Jost Baron

2015-02-04 21:07:26 UTC

Permalink

Hi Lars,

wahrscheinlich stehen in der DB tatsächlich die kaputten Zeichen drin,
als einzelne Zeichen. Statt dem Unicode-Zeichen ä stehen da also die
zwei Unicode-Zeichen 'Ã' und '¤'.

Ich hatte das Problem auch schonmal, die genaue Lösung weiß ich nicht
mehr. Die ging aber ungefähr so:

1. Hol dir einen Dump der Datenbank, latin1-codiert. Geht mit
`mysqldump -u <username> -p -r <outpufile>
- --default-character-set=latin1 <dbname>`

2. Lade den Dump in eine neue DB, aber interpretiere die Datei dabei
als UTF8. Es kann sein, dass dass du dafür den Dump modifizieren und
die eine oder andere "set charset" oder "set names"-Direktive dadrin
entfernen oder ändern muss.

Gruß Jost

Sorry, die Mail war noch nicht fertig.... setDBinit ist leer, da
steht natürlich nicht admin drin.
Trage ich in setDBinit dieses hier ein: set names utf8;
Dann werden die falschen Umlaute auch im Frontend angezeigt.
Viele Grüße, Lars Brinkmann
Am 4. Februar 2015 um 21:38 schrieb Lars Brinkmann

Post by Lars Brinkmann
Hallo zusammen,
ich habe hier ein älteres Projekt, bei dem ich nicht mehr
nachvollziehen kann, wie die frühere Einrichtung bzw.
Konfiguration gewesen ist. Hier werden aber bei einem Update auf
6.2 falsche Sonderzeichen/Umlaute angezeigt.
Ich beschreibe mal die Ausgangsposition.
Aktuell läuft die Seite auf TYPO3 4.5.39. Charset für Ausgabe
steht auf utf-8 und alle Texte werden korrekt ausgegeben, auch
die Umlaute bereiten keine Probleme.
Der Server-Zeichensatz lt. phpMyAdmin steht auf UTF-8, die
Kollation der Tabelle tt_content (und der anderen auch) steht
auf utf8_general_ci
Im Feld tt_content#bodytext zeigt mir phpMyAdmin aber die Texte
schon mit falschen Umlauten an: "...QualitÃ¤tsanspruch..."
Ich gehe also mal davon aus, dass mein Problem schon besteht und
nicht erst durch das Update auf 6.2 entsteht. Die Frage ist nun,
was kann ich hier tun, um das Problem zu beseitigen?
[SYS]setDBinit] = admin [SYS]UTF8filesystem] = 1
[BE][forceCharset] = utf-8

Peter Linzenkirchner

2015-02-05 10:06:19 UTC

Permalink

Hallo Jost, Lars,

ja, so funktioniert es. Der Fehler liegt in einer falschen Datenbank-Verbindung. Solange diese nicht explizit definiert wurde, war diese in älteren PHP Versionen automatisch latin (das entspricht setDBinit="set names latin"). Damit werden utf8-Datei über eine Latin-Verbindung gesendet. MySQL geht dann davon aus, dass es latin erhält und konvertiert nach utf8. Da die Daten aber bereits utf8 sind, sind sie danach doppelt utf8-kodiert. Auf dem Rückweg passiert das gleiche, deshalb stimmts in TYPO3 wieder ... Man musste deshalb in TYPO3 vor 4.6 immer setDBinit auf set names utf8 setzen, sonst hat man automatisch dieses Problem produziert. Leider ist das in der Regel nicht gemacht worden.

Die Lösung ist, wie von Jost beschrieben:

- Export in einen latin-Dump
- Dann im Dump charset=latin austauschen gegen charset=utf8
- und zurückspielen
- und dann setDBinit entfernen
- und als utf8 zurückspielen

Das hat bei mir bisher immer funktioniert.

Alternative bis 4.5 war übrigens, setDBinit auf "set names latin" zu setzen - dann wird die DB-Verbindung auf latin zurückgesetzt und die Umlaute stimmen wieder. Natürlich ist das nur ein Workaround, keine Lösung, die Inhalte der Datenbank bleiben ja doppelt utf8-kodiert; ausserdem funktioniert es nicht mehr in TYPO3 6.2.

Gruß
Peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Lars,
wahrscheinlich stehen in der DB tatsächlich die kaputten Zeichen drin,
als einzelne Zeichen. Statt dem Unicode-Zeichen ä stehen da also die
zwei Unicode-Zeichen 'Ã' und '¤'.
Ich hatte das Problem auch schonmal, die genaue Lösung weiß ich nicht
1. Hol dir einen Dump der Datenbank, latin1-codiert. Geht mit
`mysqldump -u <username> -p -r <outpufile>
- --default-character-set=latin1 <dbname>`
2. Lade den Dump in eine neue DB, aber interpretiere die Datei dabei
als UTF8. Es kann sein, dass dass du dafür den Dump modifizieren und
die eine oder andere "set charset" oder "set names"-Direktive dadrin
entfernen oder ändern muss.
Gruß Jost

Sorry, die Mail war noch nicht fertig.... setDBinit ist leer, da
steht natürlich nicht admin drin.
Trage ich in setDBinit dieses hier ein: set names utf8;
Dann werden die falschen Umlaute auch im Frontend angezeigt.
Viele Grüße, Lars Brinkmann
Am 4. Februar 2015 um 21:38 schrieb Lars Brinkmann

Post by Lars Brinkmann
Hallo zusammen,
ich habe hier ein älteres Projekt, bei dem ich nicht mehr
nachvollziehen kann, wie die frühere Einrichtung bzw.
Konfiguration gewesen ist. Hier werden aber bei einem Update auf
6.2 falsche Sonderzeichen/Umlaute angezeigt.
Ich beschreibe mal die Ausgangsposition.
Aktuell läuft die Seite auf TYPO3 4.5.39. Charset für Ausgabe
steht auf utf-8 und alle Texte werden korrekt ausgegeben, auch
die Umlaute bereiten keine Probleme.
Der Server-Zeichensatz lt. phpMyAdmin steht auf UTF-8, die
Kollation der Tabelle tt_content (und der anderen auch) steht
auf utf8_general_ci
Im Feld tt_content#bodytext zeigt mir phpMyAdmin aber die Texte
schon mit falschen Umlauten an: "...QualitÃ¤tsanspruch..."
Ich gehe also mal davon aus, dass mein Problem schon besteht und
nicht erst durch das Update auf 6.2 entsteht. Die Frage ist nun,
was kann ich hier tun, um das Problem zu beseitigen?
[SYS]setDBinit] = admin [SYS]UTF8filesystem] = 1
[BE][forceCharset] = utf-8

--
Xing: http://www.xing.com/profile/Peter_Linzenkirchner
Web: http://www.typo3-lisardo.de
Facebook: http://tinyurl.com/lisardo-multimedia

Lars Brinkmann

2015-02-05 14:18:14 UTC

Permalink

Hallo Peter und alle anderen,

vielen Dank erst einmal für die Hilfestellung. Zum Glück kann ich mir etwas
Zeit lassen und ein wenig testen. Shell-Zugriff und iconv habe ich bei diesem
Projekt auch, so dass mir wohl auch die richtigen Werkzeuge zur Verfügung
stehen sollten.

Durch Eure Antworten habe ich das Problem schon mal
richtig verstanden und kann es nun - hoffentlich - erfolgreich angehen.

Viele Grüße, Lars Brinkmann

Post by Peter Linzenkirchner
Hallo Jost, Lars,
ja, so funktioniert es. Der Fehler liegt in einer falschen Datenbank-Verbindung. Solange diese nicht explizit definiert wurde, war diese in älteren PHP Versionen automatisch latin (das entspricht setDBinit="set names latin"). Damit werden utf8-Datei über eine Latin-Verbindung gesendet. MySQL geht dann davon aus, dass es latin erhält und konvertiert nach utf8. Da die Daten aber bereits utf8 sind, sind sie danach doppelt utf8-kodiert. Auf dem Rückweg passiert das gleiche, deshalb stimmts in TYPO3 wieder ... Man musste deshalb in TYPO3 vor 4.6 immer setDBinit auf set names utf8 setzen, sonst hat man automatisch dieses Problem produziert. Leider ist das in der Regel nicht gemacht worden.
- Export in einen latin-Dump
- Dann im Dump charset=latin austauschen gegen charset=utf8
- und zurückspielen
- und dann setDBinit entfernen
- und als utf8 zurückspielen
Das hat bei mir bisher immer funktioniert.
Alternative bis 4.5 war übrigens, setDBinit auf "set names latin" zu setzen - dann wird die DB-Verbindung auf latin zurückgesetzt und die Umlaute stimmen wieder. Natürlich ist das nur ein Workaround, keine Lösung, die Inhalte der Datenbank bleiben ja doppelt utf8-kodiert; ausserdem funktioniert es nicht mehr in TYPO3 6.2.
Gruß
Peter

Sorry, die Mail war noch nicht fertig.... setDBinit ist leer, da
steht natürlich nicht admin drin.
Trage ich in setDBinit dieses hier ein: set names utf8;
Dann werden die falschen Umlaute auch im Frontend angezeigt.
Viele Grüße, Lars Brinkmann
Am 4. Februar 2015 um 21:38 schrieb Lars Brinkmann

Post by Lars Brinkmann
Hallo zusammen,
ich habe hier ein älteres Projekt, bei dem ich nicht mehr
nachvollziehen kann, wie die frühere Einrichtung bzw.
Konfiguration gewesen ist. Hier werden aber bei einem Update auf
6.2 falsche Sonderzeichen/Umlaute angezeigt.
Ich beschreibe mal die Ausgangsposition.
Aktuell läuft die Seite auf TYPO3 4.5.39. Charset für Ausgabe
steht auf utf-8 und alle Texte werden korrekt ausgegeben, auch
die Umlaute bereiten keine Probleme.
Der Server-Zeichensatz lt. phpMyAdmin steht auf UTF-8, die
Kollation der Tabelle tt_content (und der anderen auch) steht
auf utf8_general_ci
Im Feld tt_content#bodytext zeigt mir phpMyAdmin aber die Texte
schon mit falschen Umlauten an: "...QualitÃ¤tsanspruch..."
Ich gehe also mal davon aus, dass mein Problem schon besteht und
nicht erst durch das Update auf 6.2 entsteht. Die Frage ist nun,
was kann ich hier tun, um das Problem zu beseitigen?
[SYS]setDBinit] = admin [SYS]UTF8filesystem] = 1
[BE][forceCharset] = utf-8

--
Xing: http://www.xing.com/profile/Peter_Linzenkirchner
Web: http://www.typo3-lisardo.de
Facebook: http://tinyurl.com/lisardo-multimedia
_______________________________________________
TYPO3-german mailing list
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

--
***@gmail.com

Lars Brinkmann

2015-02-11 08:52:07 UTC

Permalink

Hallo zusammen,

leider bin ich mit meinem Problem immer noch nicht wirklich weiter gekommen.
Alle Konvertierungsversuche sind bislang fehlgeschlagen. Vielleicht bin ich
auch falsch an das Problem ran gegangen. Hier also ein neuer Versuch.

Ich habe mich per Shell mit der Datenbank verbunden und den Status
ausgeben lassen. Dort steht dann:

Server characterset: latin1
DB characterset: latin1
Client characerset: latin1
Conn. characterset: latin1

Ok. Lasse ich mir also den Status der Tabelle anzeigen. Hier steht dann:
tt_content utf8_general_ci

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.

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 ..."

TYPO3 ist wie folgt konfiguriert:

[SYS][UTF8filesystem] = 1
[BE][forceCharset] = utf-8
[SYS][setDBinit] =

Im TypoScript ist KEIN Charset definiert, in der HTML-Ausgabe steht aber:
< meta http-equiv="Content-Type" content="text/html; charset=utf-8" / >

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".

Ich frage mich nun, wo erst einmal der grundlegende Fehler zu suchen ist?
Sind die Daten schon in der Datenbank falsch gespeichert? Aber warum
kann ich sie mir dann in der Konsole korrekt anzeigen lassen? Und
warum kann 4.5 sie korrekt zeigen, 6.2 aber nicht?

Viele Grüße, Lars Brinkmann

Post by Lars Brinkmann
Hallo Peter und alle anderen,
vielen Dank erst einmal für die Hilfestellung. Zum Glück kann ich mir etwas
Zeit lassen und ein wenig testen. Shell-Zugriff und iconv habe ich bei diesem
Projekt auch, so dass mir wohl auch die richtigen Werkzeuge zur Verfügung
stehen sollten.
Durch Eure Antworten habe ich das Problem schon mal
richtig verstanden und kann es nun - hoffentlich - erfolgreich angehen.
Viele Grüße, Lars Brinkmann

Sorry, die Mail war noch nicht fertig.... setDBinit ist leer, da
steht natürlich nicht admin drin.
Trage ich in setDBinit dieses hier ein: set names utf8;
Dann werden die falschen Umlaute auch im Frontend angezeigt.
Viele Grüße, Lars Brinkmann
Am 4. Februar 2015 um 21:38 schrieb Lars Brinkmann

Post by Lars Brinkmann
Hallo zusammen,
ich habe hier ein älteres Projekt, bei dem ich nicht mehr
nachvollziehen kann, wie die frühere Einrichtung bzw.
Konfiguration gewesen ist. Hier werden aber bei einem Update auf
6.2 falsche Sonderzeichen/Umlaute angezeigt.
Ich beschreibe mal die Ausgangsposition.
Aktuell läuft die Seite auf TYPO3 4.5.39. Charset für Ausgabe
steht auf utf-8 und alle Texte werden korrekt ausgegeben, auch
die Umlaute bereiten keine Probleme.
Der Server-Zeichensatz lt. phpMyAdmin steht auf UTF-8, die
Kollation der Tabelle tt_content (und der anderen auch) steht
auf utf8_general_ci
Im Feld tt_content#bodytext zeigt mir phpMyAdmin aber die Texte
schon mit falschen Umlauten an: "...QualitÃ¤tsanspruch..."
Ich gehe also mal davon aus, dass mein Problem schon besteht und
nicht erst durch das Update auf 6.2 entsteht. Die Frage ist nun,
was kann ich hier tun, um das Problem zu beseitigen?
[SYS]setDBinit] = admin [SYS]UTF8filesystem] = 1
[BE][forceCharset] = utf-8

--
_______________________________________________
TYPO3-german mailing list
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

--
***@gmail.com

Chris Wolff - AERTiCKET AG

2015-02-11 10:05:38 UTC

Permalink

Hi Lars,
das mit den Charsets ist immer wieder eine "freude".
Deine server Settings :
Server characterset: latin1
DB characterset: latin1
Client characerset: latin1
Conn. characterset: latin1
Sind nur die defaults falls der client nix anderes aushandelt.
Meistens liegt das problem daran das typo3 utf-8 daten schickt. Ohne eine utf-8 verbindung auszuhandeln. Dann speichert der datenbank server halt "komische zeichen" weil er das utf-8 als latin1 interpretiert.
Und typo3 nimmt das latin1 wieder raus und interpretiert es als utf8. Nur in der Datenbank steht halt "mist".

Nun Zu den typo3 einstellugnen:
[SYS][UTF8filesystem] = 1 -- heist nur das der fileadmin utf-8 zeichen erlaubt. Hat also gar nix mit der datenbank zu tun.
[BE][forceCharset] = utf-8 -- das Backend wird mit UTF-8 Encoding ausgeliefert statt latin1, betrifft die Datenbank nur indirekt.
[SYS][setDBinit] = -- hier sollte eigendlich "set names utf8" stehen um die Datenbank verbindung in allen Belangen auf utf8 zu setzten.

Mein vorgehen wenn ich so eine "kaputte" Installation habe. Ist immer folgende erstmal mach ich ein datenbank dump mittels mysqldump.

Dann versuche ich herauszufinden in welchem "echten encoding" die daten hinterlegt sind. (dazu hilft es ein programm zu haben wo du beim öffnen expliziet sagen kannst als was
Die daten interpretiert werden sollen. dann weisst du schon mal sicher das ich "utf-8 daten habe. Der dump aber denkt es währen latin1 daten.

Dann kann man im dump mittels suche und ersetzte das Charakterencoding der datenbanken und tabellen
Ändern. So das der mysql dump auch korrekterweise behauptes es währen utf-8 daten drin.

Danach spielt man den mysql dump (in eine neue datenbank wieder ein) ändert das setDBinit auf "set names utf8" und passt die datenbank verbindung auf die neue datenbank an.

Und schaut erstmal ob im backend die umlaute in Ordnung sind. Wenn das gut aussieht schaut man noch mal im frontend. (es kann sein das man noch ein paar typoscript settings anpassen muss um die
Darstellung im Frontent zu fixen.
config.metaCharset -- welches charset wird im meta tag der seite angegeben
config.renderCharset -- welches charset wird von typo3 fürs interne rendering genutzt.
Diese beiden settings führen unter umständen dazu das typo3 character convertierungen vornimmt.

Gruss chris

-----Ursprüngliche Nachricht-----
Von: typo3-german-***@lists.typo3.org [mailto:typo3-german-***@lists.typo3.org] Im Auftrag von Lars Brinkmann
Gesendet: Mittwoch, 11. Februar 2015 09:52
An: German TYPO3 Userlist
Betreff: Re: [TYPO3-german] Falsche Umlaute in Datenbank und nach Update auf Webseite

Hallo zusammen,

leider bin ich mit meinem Problem immer noch nicht wirklich weiter gekommen.
Alle Konvertierungsversuche sind bislang fehlgeschlagen. Vielleicht bin ich auch falsch an das Problem ran gegangen. Hier also ein neuer Versuch.

Ich habe mich per Shell mit der Datenbank verbunden und den Status ausgeben lassen. Dort steht dann:

Server characterset: latin1
DB characterset: latin1
Client characerset: latin1
Conn. characterset: latin1

Ok. Lasse ich mir also den Status der Tabelle anzeigen. Hier steht dann:
tt_content utf8_general_ci

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.

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 ..."

TYPO3 ist wie folgt konfiguriert:

[SYS][UTF8filesystem] = 1
[BE][forceCharset] = utf-8
[SYS][setDBinit] =

Im TypoScript ist KEIN Charset definiert, in der HTML-Ausgabe steht aber:
< meta http-equiv="Content-Type" content="text/html; charset=utf-8" / >

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".

Ich frage mich nun, wo erst einmal der grundlegende Fehler zu suchen ist?
Sind die Daten schon in der Datenbank falsch gespeichert? Aber warum kann ich sie mir dann in der Konsole korrekt anzeigen lassen? Und warum kann 4.5 sie korrekt zeigen, 6.2 aber nicht?

Viele Grüße, Lars Brinkmann

Post by Lars Brinkmann
Hallo Peter und alle anderen,
vielen Dank erst einmal für die Hilfestellung. Zum Glück kann ich mir
etwas Zeit lassen und ein wenig testen. Shell-Zugriff und iconv habe
ich bei diesem Projekt auch, so dass mir wohl auch die richtigen
Werkzeuge zur Verfügung stehen sollten.
Durch Eure Antworten habe ich das Problem schon mal richtig verstanden
und kann es nun - hoffentlich - erfolgreich angehen.
Viele Grüße, Lars Brinkmann

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Lars,
wahrscheinlich stehen in der DB tatsächlich die kaputten Zeichen
drin, als einzelne Zeichen. Statt dem Unicode-Zeichen ä stehen da
also die zwei Unicode-Zeichen 'Ã' und '¤'.
Ich hatte das Problem auch schonmal, die genaue Lösung weiß ich
1. Hol dir einen Dump der Datenbank, latin1-codiert. Geht mit
`mysqldump -u <username> -p -r <outpufile>
- --default-character-set=latin1 <dbname>`
2. Lade den Dump in eine neue DB, aber interpretiere die Datei dabei
als UTF8. Es kann sein, dass dass du dafür den Dump modifizieren und
die eine oder andere "set charset" oder "set names"-Direktive dadrin
entfernen oder ändern muss.
Gruß Jost

Sorry, die Mail war noch nicht fertig.... setDBinit ist leer, da
steht natürlich nicht admin drin.
Trage ich in setDBinit dieses hier ein: set names utf8;
Dann werden die falschen Umlaute auch im Frontend angezeigt.
Viele Grüße, Lars Brinkmann
Am 4. Februar 2015 um 21:38 schrieb Lars Brinkmann

Post by Lars Brinkmann
Hallo zusammen,
ich habe hier ein älteres Projekt, bei dem ich nicht mehr
nachvollziehen kann, wie die frühere Einrichtung bzw.
Konfiguration gewesen ist. Hier werden aber bei einem Update auf
6.2 falsche Sonderzeichen/Umlaute angezeigt.
Ich beschreibe mal die Ausgangsposition.
Aktuell läuft die Seite auf TYPO3 4.5.39. Charset für Ausgabe
steht auf utf-8 und alle Texte werden korrekt ausgegeben, auch die
Umlaute bereiten keine Probleme.
Der Server-Zeichensatz lt. phpMyAdmin steht auf UTF-8, die
Kollation der Tabelle tt_content (und der anderen auch) steht auf
utf8_general_ci
Im Feld tt_content#bodytext zeigt mir phpMyAdmin aber die Texte
schon mit falschen Umlauten an: "...QualitÃ¤tsanspruch..."
Ich gehe also mal davon aus, dass mein Problem schon besteht und
nicht erst durch das Update auf 6.2 entsteht. Die Frage ist nun,
was kann ich hier tun, um das Problem zu beseitigen?
[SYS]setDBinit] = admin [SYS]UTF8filesystem] = 1
[BE][forceCharset] = utf-8

--
_______________________________________________
TYPO3-german mailing list
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

--
***@gmail.com
_______________________________________________
TYPO3-german mailing list
TYPO3-***@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Marcus Raphelt

2015-02-11 11:06:09 UTC

Permalink

Daag,

weiß der Apache davon? :)
Probiere mal
AddDefaultCharset utf-8

in der VHost-Definition oder in der htaccess.

Gruß,
Marcus

Post by Lars Brinkmann
Server-Zeichensatz: UTF-8 Unicode (utf8)

RDE - Gert Redlich

2015-02-11 12:11:57 UTC

Permalink

Post by Lars Brinkmann
Hallo zusammen,
leider bin ich mit meinem Problem immer noch nicht wirklich weiter gekommen.
Alle Konvertierungsversuche sind bislang fehlgeschlagen. Vielleicht bin ich
auch falsch an das Problem ran gegangen. Hier also ein neuer Versuch.

--
mit freundlichen Grüßen
Dipl.Ing.Gert Redlich

Lars Brinkmann

2015-02-11 12:46:13 UTC

Permalink

Hallo Gert und alle anderen,

habe einen Teilerfolg zu verzeichnen.

Zunächst einmal habe ich in der Shell zwei Dumps erzeugt:

a) mysqldump --opt -Q -u[user] -p[pw] -h[host] [DB] > dump-a.sql
b) mysqldump -u[user] -p[pw] -h[host] --compatibel=mysql40 [DB] > dump-b.sql

Beide Dumps habe ich in Notepad++ geöffnet. Dump A zeigt die
Sonderzeichen falsch an, Dump B zeigt sie korrekt.

Dann habe ich mit
mysql -u[user] -p[pw] -h[host] --default-character-set=utf8 [DB] < dump-b.sql
den zuletzt erzeugten Dump mit den korrekten Sonderzeichen in die
DB eingespielt.

Daraufhin fehlten viele Texte in TYPO3. Ich habe dann in der TYPO3
Konfiguration ['setDBinit'] = 'SET NAMES utf8;' gesetzt (fehlte ja bisher).

Nun wird die Seite in Deutsch korrekt angezeigt. Alle Sonderzeichen
wieder da.

Allerdings werden nun die chinesischen Zeichen mit ???? dargestellt. Sowohl
im Frontend als auch im Backend. Das hat also noch nicht funktioniert.

Viele Grüße, Lars Brinkmann

Post by RDE - Gert Redlich

Hallo Lars,
gehe nochmal auf
http://software.rde.de/typo3-6-hilfsprogramme.html
und dort Topic 108 (108 - Die alte Datenbank auslesen ="dumpen":)
und dort Versuch2
und dumpe mal die Datenbank mit dieser Kommandozeile auf Systemebene
und dann schau mit dem text-Editor in das gedumpte Ergebnis rein,
ob Du die Sonderzeichen korrekt sehen kannst.
Es wäre ein Versuch wert
--
mit freundlichen Grüßen
Dipl.Ing.Gert Redlich
_______________________________________________
TYPO3-german mailing list
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

--
***@gmail.com

Chris Wolff - AERTiCKET AG

2015-02-11 13:49:10 UTC

Permalink

Hallo Lars,
schau dir noch mal deinen ersten dump an. notepad++ hat die möglichkeit dateien mit verschieden encodings anzuzeigen.
Also öffne den file noch mal und änder das anzeige encoding bis du die sonderzeichen richtig siehst. Dann weist du schon mal was
Das richtige encoding deiner daten ist.

Ich vermute mal die daten sind UTF-8 encodiert (die datenbank glaubt aber es währe latin1) sonst würde das mit den chinesichsen zeichen
Gar nicht gehen (latin1 kann kein chinesisch abbilden).

Gruss chris

-----Ursprüngliche Nachricht-----
Von: typo3-german-***@lists.typo3.org [mailto:typo3-german-***@lists.typo3.org] Im Auftrag von Lars Brinkmann
Gesendet: Mittwoch, 11. Februar 2015 13:46
An: ***@ipw.net; German TYPO3 Userlist
Betreff: Re: [TYPO3-german] Falsche Umlaute in Datenbank und nach Update auf Webseite

Hallo Gert und alle anderen,

habe einen Teilerfolg zu verzeichnen.

Zunächst einmal habe ich in der Shell zwei Dumps erzeugt:

a) mysqldump --opt -Q -u[user] -p[pw] -h[host] [DB] > dump-a.sql
b) mysqldump -u[user] -p[pw] -h[host] --compatibel=mysql40 [DB] > dump-b.sql

Beide Dumps habe ich in Notepad++ geöffnet. Dump A zeigt die Sonderzeichen falsch an, Dump B zeigt sie korrekt.

Dann habe ich mit
mysql -u[user] -p[pw] -h[host] --default-character-set=utf8 [DB] < dump-b.sql den zuletzt erzeugten Dump mit den korrekten Sonderzeichen in die DB eingespielt.

Daraufhin fehlten viele Texte in TYPO3. Ich habe dann in der TYPO3 Konfiguration ['setDBinit'] = 'SET NAMES utf8;' gesetzt (fehlte ja bisher).

Nun wird die Seite in Deutsch korrekt angezeigt. Alle Sonderzeichen wieder da.

Allerdings werden nun die chinesischen Zeichen mit ???? dargestellt. Sowohl im Frontend als auch im Backend. Das hat also noch nicht funktioniert.

Viele Grüße, Lars Brinkmann

Post by RDE - Gert Redlich

Post by Lars Brinkmann
Hallo zusammen,
leider bin ich mit meinem Problem immer noch nicht wirklich weiter gekommen.
Alle Konvertierungsversuche sind bislang fehlgeschlagen. Vielleicht
bin ich auch falsch an das Problem ran gegangen. Hier also ein neuer
Versuch.

Hallo Lars,
gehe nochmal auf
http://software.rde.de/typo3-6-hilfsprogramme.html
und dort Topic 108 (108 - Die alte Datenbank auslesen ="dumpen":)
und dort Versuch2
und dumpe mal die Datenbank mit dieser Kommandozeile auf Systemebene
und dann schau mit dem text-Editor in das gedumpte Ergebnis rein, ob
Du die Sonderzeichen korrekt sehen kannst.
Es wäre ein Versuch wert
--
mit freundlichen Grüßen
Dipl.Ing.Gert Redlich
_______________________________________________
TYPO3-german mailing list
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

--
***@gmail.com
_______________________________________________
TYPO3-german mailing list
TYPO3-***@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

bernd wilke

2015-02-11 15:24:53 UTC

Permalink

Post by Lars Brinkmann
Hallo Gert und alle anderen,
habe einen Teilerfolg zu verzeichnen.

[...]

da kann ich dann ja mal auf ein Scrpt hinweisen, mit dem ich einige
TYPO3-installationen nach UTF-8 hinbekommen habe.
es ist eine Sammlung einiger Snippets, über die man immer wieder
stolpert, verbunden mit einigen Lösungen, die ich immer wieder brauchte.

vielleicht hilft es dir ja ohne dass du Riesendateien in einem Editor
aufmachen und konvertieren musst.

http://pi-phi.de/293.html

Auf Datensicherung um bei Bedarf wieder vom ursprünglichen Zustand neu
anzufangen muss ich ja wohl nicht hinweisen.

bernd

--
http://www.pi-phi.de/cheatsheet.html

Peter Linzenkirchner

2015-02-11 13:23:08 UTC

Permalink

Hallo Lars,

wie ich dir schon geschrieben habe, du hast doppelt utf8-kodierte Daten in der Datenbank.

Post by Lars Brinkmann
Server characterset: latin1
DB characterset: latin1
Client characerset: latin1
Conn. characterset: latin1

=> das ist der Übeltäter.

Post by Lars Brinkmann
tt_content utf8_general_ci

=> das ist belanglos, damit wird nur die Sortierung geregelt.

Post by Lars Brinkmann
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.

Post by Lars Brinkmann
Gehe ich nun mit pypMyAdmin auf diese Datenbank bekomme ich zunächst
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
"... 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.

Post by Lars Brinkmann
[SYS][UTF8filesystem] = 1
[BE][forceCharset] = utf-8
[SYS][setDBinit] =

=> das ist der Übeltäter, damit steht die Connection auf latin.

Post by Lars Brinkmann
< 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.

Post by Lars Brinkmann
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.

Post by Lars Brinkmann
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.

Post by Lars Brinkmann
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.

Post by Lars Brinkmann
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

Peter Linzenkirchner

2015-02-11 14:55:13 UTC

Permalink

Hallo,

Post by Lars Brinkmann
"... 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

Lars Brinkmann

2015-02-11 21:03:58 UTC

Permalink

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

Post by Dirk Ho
Hallo,

Post by Lars Brinkmann
"... GmbH Ã¼bernimmt ..."

https://www.liveconfig.com/de/kb/11
ö Ã¶
ü Ã¼
das sind doppelt utf8-kodierte Daten, und die stehen so in der Datenbank. Punkt.
http://www.gerd-riesselmann.net/softwareentwicklung/php-und-utf-8-eine-anleitung-teil-1-mysql/
• 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.
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
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

--
***@gmail.com

Peter Linzenkirchner

2015-02-11 21:25:48 UTC

Permalink

Hi Lars,

klasse! Freut mich, dass ich helfen konnte! Wenn man da mal durch ist, schreckt einen im Bereich Kodierung nichts mehr :-)

Gruß
Peter

Post by Lars Brinkmann
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.
mysqldump -u[user] -p[pw] --default-character-set=latin1 [db] > dump.sql
vi dump.sql
:%s/latin1/utf8/
:wq
setDBinit = SET NAMES utf8;
DROP DATABASE [db];
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

Post by Dirk Ho
Hallo,

Post by Lars Brinkmann
"... GmbH Ã¼bernimmt ..."

--
_______________________________________________
TYPO3-german mailing list
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

--
Xing: http://www.xing.com/profile/Peter_Linzenkirchner
Web: http://www.typo3-lisardo.de
Facebook: http://tinyurl.com/lisardo-multimedia

RDE - Gert Redlich

2015-02-04 22:56:33 UTC

Permalink

Lars Brinkmann schrieb:

Hi Lars,

schau mal hier rein, wenn Du alte Tabellen hast

eine Anleitung zum Dumpen auf Systemebene

http://software.rde.de/typo3-6-hilfsprogramme.html

--
mit freundlichen Grüßen
Gert Redlich

bernd wilke

2015-02-05 07:34:07 UTC

Permalink

Post by Lars Brinkmann
Sorry, die Mail war noch nicht fertig....
setDBinit ist leer, da steht natürlich nicht admin drin.

leer ist leider schlimmer als gar kein Eintrag.
bei leer wird glaube ich der default für Verbindungen genommen.
bei nicht vorhanden wird ein "set names utf8" als TYPO3-default benutzt
so dass der Zeichensatz mit dem der Tabellenfelder üebreinstimmt.

in mysql gibt es ja diverse stellen um einen (default) Zeichensatz
einzustellen:
die DB
die Tabelle
ein Tabellenfeld
das wichtigste ist hierbei natürlich das Tabellenfeld.

aber es gibt auch noch den Zeichensatz für Verbindungen zur DB. und hier
erfolgt ggfls. dann noch mal eine Konvertierung wenn erforderlich.

Post by Lars Brinkmann
Trage ich in setDBinit dieses hier ein: set names utf8;
Dann werden die falschen Umlaute auch im Frontend angezeigt.

und dann versucht TYPO3 noch einmal selber alles in UTF8 zu bringen.
bei leerem setDBinit geht TYPO3 wohl von latin1 aus und bearbeitet alles
noch einmal, obwohl es eigentlich richtig wäre.
wenn also daten in die DB geschrieben werden konvertiert TYPO3 deien
UTF8 daten nach latin1, mysql bekommt (laut Konfiguration) aber UTF8 und
schon werden die Zeichen falsch gespeichert.

da das ganze beim auslesen genau umgekehrt erfolgt merkst du auf TYPO3
Seite nichts. Nur wenn du mit phpadmin/mysqldump auf die DB ganz ohne
Konvertierung zugreifst siehst du die falschen Zeichen.

wie schon vorgeschlagen hast du zwei Möglichkeiten:
beim aufbau der Verbindung zur DB die Konvertierung aktivieren, oder
alles 'as is' dumpen und den erzeugten Dump als Textdatei konvertieren.
Notepad wäre ein Tool. Dazu müßtest du den dump aber erstmal vom Server
zu deinem Rechner transferieren und nachher wieder zurück.
mit "iconv" steht dir auf fast jedem *ix system ein Tool genau für
diesen Anwendungsfall zur Verfügung.

bernd

--
http://www.pi-phi.de/cheatsheet.html

Peter Linzenkirchner

2015-02-05 10:38:24 UTC

Permalink

Hallo Bernd,

bei leerem setDBinit geht TYPO3 wohl von latin1 aus und bearbeitet alles noch einmal, obwohl es eigentlich richtig wäre.

Nicht TYPO3. In älteren PHP-Versionen ist die Datenbank-Verbindung per Default auf latin. MySQL erwartet dann latin-Daten. Um das zu verhindern muss man in php so vorgehen:

$db_link = mysql_connect (MYSQL_HOST, MYSQL_BENUTZER, MYSQL_KENNWORT);
$db_sel = mysql_select_db( MYSQL_DATENBANK ) or die("Auswahl der Datenbank fehlgeschlagen");
$sql = "set names 'utf8';";
mysql_query( $sql,$db_link );
return $db_link;

damit wird die Verbindung für den aktuellen DB-Zeiger ($db_link) auf utf8 umgestellt. Das tut innerhalb von TYPO3 die Einstellung setDBinit im Install-Tool. Wenn die fehlt, dann werden utf8-Daten über eine latin-Verbindung an die DB gesendet, die dann die utf8-Daten erneut nach utf8 kodiert. Beim Auslesen findet der umgekehrte Prozess statt. Tatsächlich gibt es nirgends wirklich latin-Daten; und es hängt nicht direkt mit TYPO3 zusammen sondern mit den PHP-Versionen und der Konfiguration der Datenbank-Verbindung.

wenn also daten in die DB geschrieben werden konvertiert TYPO3 deien UTF8 daten nach latin1,

Stimmt so m. W. nicht. in TYPO3 ist noch alles korrekt, nur die Verbindung zur DB ist latin. Die Daten werden völlig korrekt verarbeitet, aber MySQL erwartet aufgrund der DB-Verbindung latin und konvertiert selbst nach utf8. Da die Daten bereits utf8 sind, werden sie doppelt utf8 kodiert gespeichert. Der Übeltäter ist also eigentlich die Datenbank - und deshalb kann man es über Export in einen latin-Dump korrigieren.

Wenn man PHP updatet (oder TYPO3) dann wird die DB-Verbindung plötzlich utf8 und MySQL konvertiert beim Ausliefern der Daten nicht mehr zuerst nach latin (also nach einfach utf8) sondern sendet direkt doppelt-utf8 kodierte Daten. Das sind dann diese kryptischen Zeichen in Back- und Frontend. Zwei Lösungen: die Daten von doppelt utf8 zu einfach utf8 konvertieren, oder die DB-Verbindung über setDBinit auf latin setzen.

In PHP würde das so aussehen:

$db_link = mysql_connect (MYSQL_HOST, MYSQL_BENUTZER, MYSQL_KENNWORT);
$db_sel = mysql_select_db( MYSQL_DATENBANK ) or die("Auswahl der Datenbank fehlgeschlagen");
$sql = "set names 'latin';";
mysql_query( $sql,$db_link );
return $db_link;

So stelle ich z. B. sicher, dass in eine DB wirklich latin geschrieben wird (in ein paar Anwendungen brauche ich noch latin). Innerhalb von TYPO3 würde das die Einstellung setDBInit="set names latin" bewirken.

beim aufbau der Verbindung zur DB die Konvertierung aktivieren,

Das müsste dann allerdings "set names latin" lauten - das funktioniert in älteren TYPO3 Versionen, aber ich glaube nicht mehr in TYPO3 6.2. Bis TYPO3 4.5 habe ich das bei etlichen Installationen so gehandhabt. Kleine Zeitbomben, weil mich das beim Update auf 6.2 natürlich in den Hintern beissen wird :-)

Das hier hilft vielleicht weiter:
http://www.skom.de/Doppelt-UTF-8-kodierte-Daten-i.191.0.html

Gruß
Peter

--
Xing: http://www.xing.com/profile/Peter_Linzenkirchner
Web: http://www.typo3-lisardo.de
Facebook: http://tinyurl.com/lisardo-multimedia

Dirk Ho

2015-02-04 21:12:10 UTC

Permalink

Hallo,

ob das DER ultimative Tipp ist weiß ich nicht, aber, ich würde so vorgehen:

Über PHPMyAdmin die komplette DB dumpen (dann hast du die Sql-Statements
mit allen Daten). Die Dump-Datei dann im Notepad++ öffnen. Dort dann
unter "Konvertiere" -> "Konvertiere zu UTF-8 ohne BOM" wählen, checken,
ob die Umlaute jetzt wieder richtig da sind und dann die DB platt machen
und den Dump wieder einspielen.

Viele Grüße,

Dirk

Marcus Raphelt

2015-02-05 08:10:37 UTC

Permalink

Tag,

wir haben vor einiger Zeit auch ein paar Projekte "vererbt" bekommen,
bei denen die Problematik ähnlich war. Hier waren die Inhalte aber kreuz
und quer mal in utf8, mal nicht, d.h. selbst eine Character-Set-Angabe
beim mysqldump hat nichts gebracht. Sollte das bei Dir auch der Fall
sein, bleibt letzten Endes nur noch search&replace, was wiederum am
besten mit sed und hexedit klappt.

-mysqldump exportieren
-Mit Hexedit nach den betroffenen Stellen im ascii suchen, per Tab dann
im Hexcode den Hexwert der fiesen Zeichen herausfinden (können auch zwei
hintereinander sein)
-Per SED ersetzen.

Beispiel: liegt das "ö" als c3 83 c2 b6 vor, dann ist der Sed-Befehl
s/\xc3\x83\xc2\xb6/ö/g;

Wenn man sich also weitere Zeichen zusammensammelt, kann soetwas dabei
herauskommen:

sed -e
"s/\xc3\x83\xc2\xb6/ö/g;s/\xc3\x83\xc2\xa4/ä/g;s/\xc3\x83\xc2\xbc/ü/g;s/\xc3\x83\xc5\x93/Ü/g;s/\xc3\x83\xc5\xb8/ß/g;s/\xc3\x83\xe2\x80\x93/Ö/g;"
dump.sql > dumpneu.sql

Nur, wie gesagt: die Methode ist der Schritt, den man machen muss, wenn
alles andere NICHT geklappt hat. Es besteht einfach die Gefahr, dass man
Zeichen übersieht.

Gruß,
Marcus