Hallo,
ich habe die Diskussion zum Thema 'Codepage' verfolgt; es hat mir aber nicht geholfen. Meine Versuche sind in dem unten stehenden TS zu sehen...
Mein Problem:
Ich habe auf einem WAMP entwickelt und bin jetzt mit meinem Projekt auf einen Linuxserver umgezogen.
Seitdem werden Umlaute fehlerhaft dargestellt. Interessanterweise passiert das sowohl im FE wie auch im BE.
Wenn ich die Codierung von 'Westeuropäisch' auf UTF-8 umstelle, werden die Umlaute im FE korrekt dargestellt. Mache ich das Gleiche im BE, wird die erste Vorschauseite korrekt geladen. Wähle ich danach eine andere Seite (im BE), wird die Codierung wieder zurückgestellt, was zum beschriebenen Fehler führt.
Es sind vermutlich zwei Probleme zu lösen:
1. In TS eine funktionierende Einstellung zu finden, die dauerhaft gültig ist,
2. das BE so zu konfigurieren, dass der beschriebene Effekt nicht auftritt.
Noch ein Gag zum Schluß: Weil ich das hier Gelesene gleich in einem separaten Fenster ausprobieren wollte, hatte ich letztlich auch beim Schreiben dieses Postings keine Umlaute mehr zur Verfügung. Ich musste alle Browserfenster schließen und neu starten, damit das nicht mehr passiert ...
Mit freundlichem Gruß
Wolfgang Erdmann
page = PAGE
page.typeNum = 0
page.meta.http-equiv = Content-Type" content="text/html; charset=UTF-8
page.bodyTag = <body bgcolor="#FFFFFF" scroll="auto">
page.headerData.10 < temp.headTemplate
page.10 = USER
page.10.userFunc = tx_templavoila_pi1->main_page
config.language = de
config.locale_all = de_DE
Hallo,
hast Du im Install-Setup die Variable:
$TYPO3_CONF_VARS[BE][forceCharset]=utf-8 gesetzt?
und im setup generell:
page.config.metaCharset = utf-8?
Und die Kollation der Datenbank auf utf8_unicode_ci?
MfG
Hallo,
vielen Dank erstmal für den Tipp. Die Einstellung waren auf Quell- und Zielsystem unterschiedlich. Ich habe das alles wie beschrieben eingestellt.
Das Problem ist aber ein anderes:
Die fehlerhaften Umlaute stecken bereits im Dump. Deshalb ist es kein Wunder, wenn das Zielsystem nicht korrekt arbeitet.
Um das zu beheben, wollte ich mit Access auf die mySQL- DB zugreifen. Allerdings bekomme ich die Umlaute hier korrekt angezeigt. Jetzt suche ich ein Werkzeug, mit dem man unter Linux ein solches 'Suchen und Ersetzen' durchführen kann.
Außerdem ist noch eine ganz andere Sache als Nebeneffekt eingetreten. Wenn auf der Seite an irgend einer Stelle ein fehlerhafter Umlaut auftritt, dann wird die Schrift in meinem grafischen Menü deutlich kleiner dargestellt. Erwische ich eine Seite ohne Umlaute, ist die Darstellung korrekt.
Mit freundlichem Gruß
Wolfgang Erdmann
tandem schrieb
Hallo,
hast Du im Install-Setup die Variable:
$TYPO3_CONF_VARS[BE][forceCharset]=utf-8 gesetzt?
und im setup generell:
page.config.metaCharset = utf-8?
Und die Kollation der Datenbank auf utf8_unicode_ci?
MfG
Hallo,
hatte das Problem selbst schon mal.
Habe die Tabellen unter Access einzeln (Tab separiert) in ASCII exportiert und dann - wieder einzeln in Mysql - importiert.
Import über phpMyAdmin aus Textdatei.
Das hat ohne Problem geklappt.
MfG
tandem schriebHabe die Tabellen unter Access einzeln (Tab separiert) in ASCII exportiert und dann - wieder einzeln in Mysql - importiert.
Import über phpMyAdmin aus Textdatei.
Warum einfach, wenn´s auch umständlich geht... 😉
Bei Typo3 gips dafür zum Glück mehr als nur eine Extension.
Hallo theo,
Warum einfach, wenn´s auch umständlich geht...
Weil es bei mir zum Produktionsprozess gehört!
Denn produziert werden die Daten in einer Access-DB und übrigens nie in ein Typo3-System importiert!
Bei Typo3 gips dafür zum Glück mehr als nur eine Extension.
Und welche dient dem Zweck, die Probleme von wvd at home zu lösen?
MfG
[/quote]
tandem schriebUnd welche dient dem Zweck, die Probleme von wvd at home zu lösen?
Sofern ich das richtig verstanden habe, sollen im Prinzip Datenbankeinträge nachträglich in utf-8 konvertiert werden?
Bei Verwendung des Suchbegriffs "utf" im TER finde ich im Moment zwei Konvertierungsextensions (ich dachte es wären mal mehr gewesen...).
Hallo,
vielen Dank für die heftige Diskussion. Es sind zumindest zwei machbare Alternativen für mich dabei. Wenn ich das mit der Extension nicht hinbekomme, bleibt mir immer noch die Fleißarbeit (55 Tabellen).
Einen schönen Tag
Wolfgang Erdmann