UTF-8/ISO-8859-1 - Encodingproblem

[allorange]

Hallo zusammen,
nach einem Serverumzug werden teilweise Kundenwebseiten nicht mehr korrekt dargestellt (Umlaute).
alter Server:
Debian Sarge, Apache2, MySQL4.0, Php4
neuer Server:
Debian Etch, Apache2, MySQL5, Php5

Als lokaler Zeichensatz ist de_DE (ISO-8859-1) eingestellt. Damit werden UTF-8 kodierte Seiten nicht richtig angezeigt.
Füge ich nun in der httpd.conf

Code: Select all

<IfModule mod_mime.c>
...
AddDefaultCharset UTF-8
...

ein, funktionieren wieder die ISO-kodierten Seiten nicht richtig (mit AddDefaultCharset ISO-8859-1 passiert logischerweise genau das Gegenteil).

Wo ich auch suche, ich kann keinen Unterschied in der Konfiguration gegenüber dem alten System feststellen, wo alle Seiten korrekt dargestellt wurden. Da sich auf dem Server etliche datenbankbasierte Seiten verschiedenster Kunden befinden, ist es absolut unmöglich, alle Webseiten entsprechend anzupassen.

Da mich Google und die Forensuche leider kein Stück weitergebracht hat, hoffe ich nun, dass mir jemand von euch einen guten Tipp geben kann.

Grüße,
allorange

[oxygen]

Eine Zeile mit AddDefaultCharset gehört in keine Apache Konfiguration. Aber davon lassen sich die Debianer leider nicht überzeugen.

[Joe User]

Abgesehen von dem AddDefaultCharset-Problem (Debian begreift es seit Jahren nicht) wette ich auf fehlende Anpassungen der Datenbanken beim Upgrade auf MySQL-5.x (siehe MySQL-Dokumentation).

[allorange]

war ja auch nur n Versuch, das Problem loszuwerden.
Die Zeile war weder in der alten, noch ist sie jetzt in der neuen Konfiguration.

[suntzu]

Dann entweder das DB-Problem oder es fehlen die Content-Type-Zeilen in den HTML-Dateien.

[allorange]

Guten Morgen,

die Content-Type-Zeilen in den per Hand erstellten html-Dateien sehen folgendermaßen aus:

1. <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
oder
2. <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Bei 1. erhalte ich ein ? für die Sonderzeichen.
Bei 2. erhalte ich die utf-Zeichen (A mit Tilde...).

Auf dem alten Server hat es problemlos funktioniert und wir finden keinen Ansatzpunkt woran es beim neuen Server hakt.

Grüße.

[Joe User]

Es sind garantiert nur Texte aus Datenbanken betroffen, was die fehlende Konvertierung beim Upgrade auf MySQL5 bestätigt.

[allorange]

Hab ich vorhin nicht erwähnt, der Serveradmin hat es geschafft, das die Seiten, die aus DB's generiert werden, wieder korrekt angezeigt werden.

Aber es gibt auch Kunden, die von Hand html-Dateien erstellen (ohne DB) und da funktioniert es nicht (wie oben beschrieben).

[Update] Zur Ansicht kann ich auch Links zur Verfügung stellen.[/Update]

[Anonymous]

Hallo Leute

Habe die gleiche Konfiguration und das gleiche Problem , ich hoffe das jemand hier eine Lösung hat , wenn ja ,bitte um Hilfe.
Ich habe schon stundenlang gegoogelt aber nichts brauchbares gefunden

Danke in Vorraus

Michael

[suntzu]

Welchen content type (ct) haben die Dateien auf dem Dateisystem, welcher ct wird in http übertragen (z.B. mit Firebug zu testen), was ist mit der DB? Es sollte alles UTF-8 oder zumindest einheitlich sein.

[chr.raible]

Hi Leute,

ich hatte mit einer WEbsite genau das gleiche Problem! Hab den Fehler aber gefunden und behoben bekommen.

Und zwar war das Problem das die MySQL Datenbank die kollation utf8_general_ci hatte und nich "reiness" UTF-8 kenne da den Unterschied zwar net aber das war das Problem.

Sobald ich in die charset datei unter /etc/apache2/conf.d von UTF-8 in utf8_general_ci umgestellt hatte funktionierte alles einwandfrei!

Porbiert das mal! Danch apache restarten net vergessen (So wars bei mir beim ersten versuch!!! )

Ich hoffe dass das euer Problem behebt!


Mfg
Chr.Raible

[Joe User]

Porbiert das mal!

Nein, nein und nochmal nein! Entweder die Datenbanken richtig ex- und importieren, oder gar nichts tun. Alles andere ist schlimmer als Pfusch...

[chr.raible]

Porbiert das mal!

Nein, nein und nochmal nein! Entweder die Datenbanken richtig ex- und importieren, oder gar nichts tun. Alles andere ist schlimmer als Pfusch...

Also ich hab weder meine Datenbank damals falsch ex noch importiert! Es wurde ein ganz normales CMS system installiert. Hab aber auch die Sicherung der alten Page getestet.

Das Backup wurde mit mysqldump, phpmyadmin und als Master - Master replikation (der zweite Master war der neue Server ) exportiert!

Importiert habe ich meine DB mit PHPmyadmin, über die konsole und wie gesagt über die replikation! Die Kollation wurde komplett auf UTF-8 umgestellt. Bei den Import vorgängen über PHPMyAdmin wurde utf-8 eingestellt. Aber nichts funktionierte! Sobal ich wieder was geschrieben hab, wurden die Umlaute nicht mehr richtig angezeigt!

Was hätte man da deiner Meinung nach anders machen sollen / können? Wenn du da eine Lösung hast dann wäre ich froh diese zu erfahren!

Und warum soll es Pfusch sein, wenn man in der charset datei vom Apache von UTF-8 auf utf8_general_ci umstellt? Man passt doch den Apache nur dem MySQL-Server an!

Mfg
Chr.Raible

[Joe User]

http://dev.mysql.com/doc/refman/4.1/en/ ... m-4-0.html
http://dev.mysql.com/doc/refman/5.0/en/ ... m-4-1.html

In der httpd.conf setzt man grundsätzlich kein AddDefaultCharset, die Apache-Devs raten nicht grundlos dringlichst davon ab, auch wenn die Debian-Maintainer dies seit Jahren wissentlich ignorieren und es nicht einmal für nötig halten, ihre User darüber zu informieren. Zudem ist eine MySQL-Collation kein Charset und dort ohnehin fehl am Platz und wird Dir hoffentlich bald die damit verbundenen Probleme bereiten...

[suntzu]

Lies dir mal die Doku zu den Collations und Charsets bei MySQL durch, dann schau mal, was du mit deiner Apache-Einstellung da geändert hast. Dann verstehst du das alles erstmal und DANN wirst auch du verstehen.

[Roger Wilco]

Siehe auch http://blog.koehntopp.de/archives/1360- ... erger.html und http://blog.koehntopp.de/archives/1424- ... lagen.html

[mex]

Moin,

neue server haben utf-8 als standard-encoding für alle files vorgegeben, wenn man aus kompatibilitätsgründen (ich musste ne php4/mysql4-anwndung auf einen neuen debian-server migrieren) auf iso angewiesen ist hilft es manchmal nur, alle dateien von utf-8 auf iso zu recoden, ist dirty aber manchmal hilf nix anderes.

mex

Hallo Leute

Habe die gleiche Konfiguration und das gleiche Problem , ich hoffe das jemand hier eine Lösung hat , wenn ja ,bitte um Hilfe.
Ich habe schon stundenlang gegoogelt aber nichts brauchbares gefunden

Danke in Vorraus

Michael

[lesswire]

In der httpd.conf setzt man grundsätzlich kein AddDefaultCharset, die Apache-Devs raten nicht grundlos dringlichst davon ab...

Kann mir einer erklären, warum ein Developer von der Nutzung des von ihm programmierten Tags abrät?
Wofür ist dann "AddDefaultCharset" gedacht?

vg, LW.

[freddy36]

AddDefaultCharset should only be used when all of the text resources to which it applies are known to be in that character encoding and it is too inconvenient to label their charset individually. One such example is to add the charset parameter to resources containing generated content, such as legacy CGI scripts, that might be vulnerable to cross-site scripting attacks due to user-provided data being included in the output. Note, however, that a better solution is to just fix (or delete) those scripts, since setting a default charset does not protect users that have enabled the "auto-detect character encoding" feature on their browser.

http://httpd.apache.org/docs/2.0/mod/core.html

[Joe User]

Kann mir einer erklären, warum ein Developer von der Nutzung des von ihm programmierten Tags abrät?

Weil nicht alles was der Kunde will auch sinnvoll oder empfehlenswert ist.

Wofür ist dann "AddDefaultCharset" gedacht?

Kkompatibilität zu uralten WebApps und Clients...