das muss ich glatt ausprobieren. lese mich gerade auch ein, weil die Umstellung von Typo3 auf Japanisch echt alles andere als einfach ist. Habe shift_jis in typo3 und sjis_japanese_ci in der Datenbank. So kriege ich dauernd den Fehler noch, und ich sehe nur Fragezeichen. Muss wohl an der php noch liegen. Collations scheinen dabei nicht das Problem zu sein. In Datenbank kann man die Kanji/Kana lesen, aber Typo3 spuckt und schreibt nur Fragezeichen und Sondermüll…

danke für die Richtigstellung! Ich arbeite nicht sehr häufig mit Typo3, von daher war ich froh als es damals endlich lief wie es sollte Ist ja auch schon ein paar Jährchen her… Also – danke für die ausführlichen Informationen!

Gruß, Ingo

Kurz zusammengefasst muss folgendes berücksichtigt werden: - TYPO3 arbeitet mit Daten und nutzt dafür den Zeichensatz, der in $TYPO3_CONF_VARS['BE']['forceCharset'] eingestellt ist. Standardwert ist ‘iso-8859-1′ (Latin1) oder je nach Sprache des Backends der jeweilige Standard-Zeichensatz dieser Sprache. - Die MySQL-Schnittstelle in PHP, die von TYPO3 genutzt wird, verwendet ebenfalls ihr eigenes Charset. Standardwert ist je nach Distribution unterschiedlich, kann mit “SHOW VARIABLES LIKE ‘character_set_%’” überprüft werden (folgende müssen mit dem o.g. forceCharset übereinstimmen: character_set_client, character_set_connection, character_set_result). Konfiguration erfolgt entweder über MySQL-Konfiguration (my.ini). Wer nicht sicher ist, kann den Zeichensatz auch von TYPO3 bei jedem Aufruf setzen lassen: $TYPO3_CONF_VARS['SYS']['setDBinit'] = ‘SET NAMES utf8;’ - MySQL selber nutzt dann ebenfalls ein eigenes Charset. Dabei muss insbesondere berücksichtigt werden, dass nicht nur für die Datenbank, sondern für jede Tabelle und sogar für jedes einzelne Feld ein anderer Zeichensatz verwendet werden könnte. (Dieses Gemisch taucht oft auf wenn eine Datenbank nicht richtig migriert wird, darum sollte dies bei Problemen als erstes überprüft werden.) Richtigerweise sollten auch hier alle Tabellen/Felder ebenfalls mit o.g. Zeichensatz übereinstimmen. Der Zeichensatz, der für die DB ausgewählt wurde, wird jeweils für neu angelegte Tabellen verwendet. Auch wichtig: “CONVERT TO CHARACTER SET …” setzt nicht nur die Einstellung für eine Tabelle, sondern konvertiert auch gleich deren Inhalt. Wer bereits fälschlicherweise UTF-8 in eine Latin1-DB schreibt, würde demnach doppelt kodierte Daten erhalten. Eine Lösung für dieses Problem ist hier beschrieben: http://bugs.typo3.org/view.php?id=6098#c15368 (Alternativ müssen halt einfach alle falschen Zeichen manuell korrigiert werden – das ist je nach grösse des Datenbestands verschmerzbar und einfacher…)

ich habe keine Ahnung ob das bekannt ist. Bei manchen Sprachen (russisch, chinesisch, …) gab es da halt Probleme. Ich hatte auch keine Zeit mich noch näher mit dem Problem zu befassen. Deine Einschätzung könnte also richtig sein

Grüße, Ingo

Wirklich nett, danke für die Hilfe und die Tipps.

Man kann den metaCharset in page.config setzen. Auch das Rendern geht darüber.

Siehe Tabelle

page.config.metaCharset = utf-8 page.config.renderCharset = utf-8

was meinst Du mit: In TS Setup meta charset setzen

???

Grüße TPITS

Komplette Datenbank auf utf-8 umgestellt. (Struktur erstellt => latin1 auf utf8, dann die Daten eingelesen) 0. editiere die typo3conf/localconf.php und füge ein: $TYPO3_CONF_VARS['BE']['forceCharset'] = ‘utf-8′; 1. Datenbank Dump der Site erstellen 2. Eine Kopie des Dumps konvertieren: recode LATIN1..UTF8 copy_of_dbname.sql 3. Bestehende Datenbanktabellen löschen 4. UTF-8 Dump zurückspielen mysql dbname < copy_of_dbname.sql oder halt erweitert um -u für user und -p für passwort

• In TS Setup meta Charset setzen
• In Install [setDBinit] SET NAMES utf8;
• damit base64 encoding funktioniert (mailform) in php.ini: mbstring.internal_encoding = UTF-8

Angeblich muß man multiplyDBfieldSize auf >1 stellen, wenn der Fehler 102 kommt, wenn man versucht, in tt_content Umlaute einzugeben. Wenn alles stimmt, kommt dieser Fehler aber nicht. Wenn >1 geht compare Database auch nicht mehr.