Sonderzeichen (Umlaute) und seltsames Verhalten von Typo...

[automatix]

Hallo allerseits!

Wieder einmal Probleme mit Sonderzeichen beim Export/Import...

Ich hab den Seitenbaum bzw. die Tabelle pages und die Inhaltselemente bzw. die Tabelle tt_content aus der "E"-Datenbank in die "I"-Datenbank ex-/importiert. Dabei hatte eine Seite den Namen "Home äöüß" und ein Contentelement (Text) mit Überschrift "äöüß" und Inhalt "Lorem ipsum... äöüß". Alles ist richtig ex- und importiert worden, das sieht man im phpmyAdmin, wenn man sich die Tabelle pages bzw. tt_content anzeigen lässt.

Im BE allerdings werden die Sonderzeichen im Seitentitel und Contentelement als Fragezeichen dargestellt.

Weiter. Füge ich noch ein paar Sonderzeichen in den Seitentitel ein, sieht es dann im BE so aus: "Home ���� ßüöä". Wenn ich mir jetzt aber den Seitentitel im phpMaAdmin anschaue, sehe ich folgendes: "Home ���� ßüöä" (o. s. Bild).

Was mache ich falsch? Warum kodiert Typo beim Speuchern die in der DB richtig gespeicherten Zeichen?

Danke

[automatix]

Hallo!

Nach langem Rumrecherchieren und unzähligen Versuchen kam ich endlich auf den segensrechen Gedanken, die localconf.php der Probleminstanz mit der einer, auf der alles gut läuft, zu vergleichen -- Zeile für Zeile. Dabei kam heraus, dass es an $TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8'; hakte... Ich habe die Zeile auskommentiert, und jetzt läuft alles wieder.

Aber eigentlich soll ja $TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8'; gerade die richtige Einstellung sein:

10.2 TYPO3 als UTF-8 einrichten
10.2.1 Überblick
1. Legen Sie die MySQL-Datenbank mit einer UTF-8-Kollation an. (ist in meinem Fall utf8_unicode_ci)
2. Setzen Sie [BE][forceCharset] = utf-8 im Installtool.

????? ?????

[steffenk]

ja, das ist das, was phpMyAdmin oft nicht ganz richtig macht.
Du musst erst die DB anlegen mit charset utf8. Das muss dann bei den Tabellen auch so sein, sonst bekommst Du diesen Murx.

Also: DB löschen, neue DB erstellen - charset utf8, Backup einspielen (auch utf

[Wolfgang G]

Hallo automatix,

das hat zwar nichts mit Deinem Typo3-Problem zu tun, aber als ich das hier las,

[…] Zeile für Zeile. […]

fiel mir dieses Programm ein: http://winmerge.org/

Es zeigt die Unterschiede zwischen 2 Dateien an und vereinfacht so die Fehlersuche.

Grüße
Wolfgang

[automatix]

@Wolfgang G
Danke!

@steffenk

ja, das ist das, was phpMyAdmin oft nicht ganz richtig macht.
Du musst erst die DB anlegen mit charset utf8. Das muss dann bei den Tabellen auch so sein, sonst bekommst Du diesen Murx.

Also: DB löschen, neue DB erstellen - charset utf8, Backup einspielen (auch utf

Danke auch Dir für Deine Antwort.
Ich habe jetzt alles nochmal von vorne angefangen. Ich hab eine DB mit Kollation utf8_unicode_ci angelegt. Nachdem Typo da seine Tabellen angelegt hat, ist die Kollation nicht mehr utf8_unicode_ci, sondern utf8_general_ci. Ich nehme an, das ist die Default-Einstellung von Typo... Soll ich jetzt die Kollation der DB und der Tabellen auf utf8_unicode_ci stellen?

[steffenk]

utf8_general_ci ist das gängige utf8-format und sollte für Deine Ausgaben völlig ok sein.

Ausserdem verwechselst Du Kollation mit Charset - Kollation ist nur die Sortierreihenfolge, sonst nichts, entscheidend ist der Charset utf8.

[automatix]

utf8_general_ci ist das gängige utf8-format und sollte für Deine Ausgaben völlig ok sein.

Auch für Russisch oder Chinesisch?

Ausserdem verwechselst Du Kollation mit Charset - Kollation ist nur die Sortierreihenfolge, sonst nichts, entscheidend ist der Charset utf8.

Ich habe die beiden nicht verwechselt, aber ich wusste nicht, wie (un)wichtig die Kollation-Einstellung ist und was sie genau bewirkt. Wenn über Kollation lese, verstehe ich meistens nur Bahnhof... Bestimmt die Kollation nur, in welcher Reihenfolge die Tabellen (nach Name) und die Tabellenzeilen (nach Inhalt der Zellen) in der DB gespeichert und per Default verglichen->ausgelesen werden?

[Stefan_G]

Moin,

Auch für Russisch oder Chinesisch?

ja.

//Stefan

[steffenk]

bei chinesisch zumindest für "simple chinese".
Es gibt auch Sprachen, da braucht man utf16, aber ich kenne chinesische/japanische Seiten mit utf8.

noch zur Kollation: das hat auch mit dem speichern nichts zu tun, nur mit der Sortierung, also wenn Du ein "ORDER BY feld" machst. Bei deutsch z.B. gibt es die Unterschiede wo ä/ö/ü einsortiert werden, genauso ist es bei e / è / é etc.

Noch eine Ergänzung: Kollation bezieht sich also nur auf ein einzelnes Feld. Die Tabelle bekommt eine Kollation, die als "default" für die Felder gilt, man kann dann einem Feld zusätzlich eine individuelle Kollation zuweisen.

[automatix]

Jetzt scheint alles klar! )) Vielen Dank!

[automatix]

neue DB erstellen - charset utf8, Backup einspielen (auch utf8)

Noch ein Anfängerfrage...

Bei mir werden DBs "per Knopfdruck" angelegt (über das Kundenmenü meines Poviders), also habe ich keinen Einfluss darauf, mit welchem Zeichensatz die neue DB erstellt wird. Wo kann man das ersehen (und ggf. ändern)?

[steffenk]

man kann jederzeit den charset umstellen, am besten wenn noch keine Tabellen da sind, damit angelegte automatisch den charset bekommen:

 ALTER DATABASE `dbname` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci

[automatix]

man kann jederzeit den charset umstellen, am besten wenn noch keine Tabellen da sind, damit angelegte automatisch den charset bekommen:

 ALTER DATABASE `dbname` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci

Aha... Danke. Aber wird auch irgendwo (im phpMyAdmin) angezeigt, welcher Charset aktuell verwendet wird?

[steffenk]

nicht das ich wüsste - wenn man eine Tabelle anlegt ohne Angabe der Kollation und charset sieht man da die default-Einstellung.

[automatix]

Ja das ist es ja -- wenn man eine Tabelle anlegt, sieht man die Default-Kollation (die auch in "Operationen" angezeigt wird), aber nicht den Charset... Merkwürdig...

Nachtrag:

Auf der Einstigsseite des phpMyAdmin steht folgendes:

MySQL-Zeichensatz: UTF-8 Unicode (utf8)

Das kann doch nichts anderes sein, als das, was wir suchen, oder? Um das zu prüfen, habe ich den Charset umgestellt:

ALTER DATABASE `db148903_157` DEFAULT CHARACTER SET latin1

Und die Charset-Angabe ist immer noch UTF-8 Unicode (utf8) (s.u.)