PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Charsetproblem (umlaute) mit apache,tomcat,mysql



anquijix
13.10.05, 14:36
Hi

Langsam dreh ich durch..

Ich ersetze unseren alten Webserver (FC2, apache 2.0.48 ,tomcat5.0.19, mysql 3.23-584)
mit folgendem Server: FC4, apache 2.0.54, tomcat5.5, mysql 4.1

Ist alles schön eingerichtet und konfiguriert und dem alten Server angepasst. Die Webseiten und DB's habe ich auch schon übernommen. Das Problem ist, dass Umlaute in jsp-Seiten und Datenbankeinträgen nicht richtig angezeigt werden. Genauer gesagt werden äöü als '?' oder unlesbare Zeichen angezeigt.
Normale HTML-Seiten werden korrekt angezeigt, dies aber auch nur, wenn ich in der httpd.conf als DefaultCharset UTF-8 verwende. Bei ISO-8859-1 geht das nicht.
Die Systemsprache ist auf de_DE.UTF-8 gesetzt.
In der tomcat5.conf habe ich LANG=de_DE.UTF-8 gesetzt. Ich habe es auch schon mit überall ISO-8559-1 versucht und auch Variationen von beidem probiert, überall erfolglos.

Seit mysql 4.* oder so gibt es das Feature, mit Charsets und Collations zu arbeiten. In diesem Fall ist das Problem eher einzugrenzen, da sich seit Version 3.23 einiges geändert hat. Aber auch hier, wenn ich überall Charsets und Collations anpasse (habs auch in diesem Fall mit Variationen probiert), es passiert rein gar nichts.

Habt ihr irgendwelche Ansätze, wo ich nach dem Problem suchen soll? Oder gar ähnliche Erfahrungen gemacht?
Mein Gefühl ist es, dass entweder etwas Bestimmtes oder mehrere Sachen verändert werden müssen. Umgesagt hab ich mich bisher entweder um den heissen Brei gearbeitet oder ich muss tatsächlich diverse Sachen anpassen, dass alles so läuft, wie ich es will und die Zeit, die ich bis anhin verschwendet habe, wenigstens nicht vergebens verschwendet wurde.

Im Internet gibt es diverse Problemstellungen, die ähnlich sind, deren Lösungen jedoch in keinem Fall zu meinem Problem passen. Ich habe sämtliche Lösungsvorschläge durchgeackert, aber keiner hat gegriffen. Ich hab echt das Gefühl, dass ich mich im Kreis bewege und keinen Schritt voran komme. Langsam bin ich am Ende meines Lateins.

Möglicherweise habe ich etwas nicht beachtet oder ich verstehe die Funktion von Charsets bzw. die Zusammenarbeit der drei Dienste im Zusammenhang mit den Charsets nicht ganz. Ich gehe mal davon aus, dass die Handhabung der Charsets nicht transparent ist unter den Diensten, daher kann ich das nicht global einstellen, dass es für alle drei passt.

Ich bedanke mich für jeden Hinweis.

marce
13.10.05, 19:14
Darstellung von Umlauten ist immer wieder lustig - deswegen gehören die ja eigentlich ge-&uml-t...

wichtig ist, das das System in sich konsistent ist. Geht zwar auch anders, aber dann wirds immer irgendwie hakelig.

Dein System nutzt UTF-8, also würde ich alles auf UTF-8 umsetzen. Und dann noch dafür sorgen, dass der Client das auch richtig encodet - am sichersten ist, per Meta-Tag in der Seite den Code mitzuliefern, ansonsten bist Du auf Good-will des Browsers und aller beteiligten Komponeten (können auch Proxies sein...) angewiesen...

temir
14.10.05, 08:57
Ich habe es auch schon mit überall ISO-8559-1 versucht...
Möglicherweise war auf der alten Machine ISO-8859-15 eingestellt?
Und wie sieht es mit der (bei Suse in /etc/sysconfig/language) Variable
RC_LC_CTYPE="" ? Im FC könnte sie LC_CTYPE heißen oder RC_CTYPE...wird für
die glibc eingestellt - also für I/O's.

anquijix
14.10.05, 10:17
Darstellung von Umlauten ist immer wieder lustig - deswegen gehören die ja eigentlich ge-&uml-t...

ja, das wäre die lösung.. aber da müsste man diverse seiten anpassen. und surfer, die zb im guestbook was reinschreiben, müssten auch &uml's verwenden. dies ist unzumutbar.
was lustig ist, aufm alten server war das problem in einem gewissen grade auch vorhanden.
da ich dazumals noch nicht da arbeitete, kann ich auch nicht ganz nachvollziehen, aws gemacht wurde. auf alle fälle wurde mit den charset einstellungen gespielt, bis eine angemessene ösung gefunden wurde. nur ist diese lösung ein gebastel. auf ein paar seiten hat es zwischendurch &uml's, dann wieder hardcoded umlaute..und irgendwie so hat man es dann hingekriegt, dass alle umlaute korrekt angezeigt werden.
die problematik ist einfach, dass das charset-zeugs auf verschiedenen ebenen gehandhabt wird. daher, wo soll man anfangen, und was übersteuert womöglich eine andere einstellung etc.


Möglicherweise war auf der alten Machine ISO-8859-15 eingestellt?
Und wie sieht es mit der (bei Suse in /etc/sysconfig/language) Variable
RC_LC_CTYPE="" ? Im FC könnte sie LC_CTYPE heißen oder RC_CTYPE...wird für
die glibc eingestellt - also für I/O's.

aufm alten server ist tatsächlich iso8895-15 eingestellt. das hatte ich auch schon auf meim neuen server probiert.. also den hab ich von grund auf dem alten server angepasst. nur scheint dies nicht überall zum gleichen effekt zu führen.

in /etc/sysconfig hats zwei dateien. einerseits die i18n, die folgenden inhalt hat:

LANG="de_DE"
SYSFONT="latarcyrheb-sun16"
SUPPORTED="de_DE:de_DE:de

da stellt sich gleich die frage, ob de_DE die iso8859-15 variante ist. denn wenn ich de_DE.ISO8859-15 mache, und danach den befehl locale ausführe, um die charset-einstellungen zu sehen, kommen ein paar meldungen, dass die charset-datei nicht gefunden wurde. und ne explizite iso8859-15 datei finde ich nirgends in den locale-verzeichnissen. da stellt sich gleich die zweite frage, kann man charsets nachinstallieren, und von woher beziehe ich diese?

Zusätzlich gibts die Datei keyboard, wobei ich kaum glaube, dass die hier relevant ist.. hier stehen einfach die angaben, dass ich mit ner schweizer tastatur schreibe:

KEYBOARDTYPE="pc"
KEYTABLE="sg"

die ausgabe von locale gibt mir die von dir besagte variable aus und sieht so aus:


LANG=de_DE
LC_CTYPE="de_DE"
LC_NUMERIC="de_DE"
LC_TIME="de_DE"
LC_COLLATE="de_DE"
LC_MONETARY="de_DE"
LC_MESSAGES="de_DE"
LC_PAPER="de_DE"
LC_NAME="de_DE"
LC_ADDRESS="de_DE"
LC_TELEPHONE="de_DE"
LC_MEASUREMENT="de_DE"
LC_IDENTIFICATION="de_DE"
LC_ALL=de_DE


momentan habe ich alles auf de_DE, was meines erachtens eben iso8559-15 entspricht. korrigiert mich, falls das falsch ist.

marce
14.10.05, 10:20
ja, das wäre die lösung.. aber da müsste man diverse seiten anpassen. und surfer, die zb im guestbook was reinschreiben, müssten auch &uml's verwenden. dies ist unzumutbar.
Das sollte eigentlich das GB-Script von alleine machen...

Ansonsten ist das anpassen eigentlich kein Problem - find -name "*.html" -exec sed irgendwas sollte das komplett lösen...

anquijix
14.10.05, 10:36
naja, das finde ich sehr heikel.. zum beispiel hats bei der guestbook-seite im jsp-code drin bei den umlauten zum teil bloss einen punkt (aber auch nur vom aussehen her).. die werden schon da nicht richtig dargestellt. aber auf der seite selbst werden besagte umlaute korrekt dargestellt. von daher ist es recht schwierig, nach irgendwas bestimmtem zu suchen, um es danach zu ersetzen. und überall &uml's setzen kann ja nicht die lösung sein.. zumindest nicht die optimale lösung, daher die charsets überall richtig gesetzt und so.

marce
14.10.05, 10:45
... dann würde ich zuerst mal den Code der Seiten an sich "umkodieren" - damit da schon mal alles einheitlich ist. Dann sämtliche Apaches und Tomcats und so wieter noch zwingen, auch UTF-8 zu verwenden und die Header entsprechend setzen... - geht ja auch in der apache bzw. Tomcat-Config...

anquijix
14.10.05, 11:18
nun ja, könnte schon die lösung sein, dafür muss ich jedoch die erlaubnis einholen :ugly: