Zeichensatzprobleme Apache/PHP
Obermotz 01.03.2010 - 15:27 1747 9
Obermotz
Fünfzylindernazi
|
Hi!
Wir haben hier bei einem Projekt Schwierigkeiten mit dem Zeichensatz. In generierten PDF-Files (fpdf) und gesendeten Emails werden UTF8-Relevante Sonderzeichen (aus der DB und aus den i18n-files) nicht korrekt angezeigt - ü statt Ü zum Beispiel.
Komischerweise tritt das Problem nur auf einem Server auf (blöderweise der des Kunden^^), der aber exakt die gleichen Configs hat wie unsere Entwicklungsserver.
System ist ein CentOS52 mit Apache22 und PHP53.
Hatte schon mal jemand ein ähnliches Problem?
tia
|
COLOSSUS
AdministratorGNUltra
|
Ja, massig. Woher kommen die Zeichen? MySQL? Ist dort die (Default) Collation der Tabelle bzw. Datenbank richtig eingestellt? Sind die Daten dort auch garantiert UTF-8-kodiert abgelegt worden? Hat der Server die von euch benoetigte Locale ueberhaupt installiert? Gibt's sicher kein Charset-Override in der (globalen oder VHost-spezifischen) Apache-httpd-Konfiguration? Wenn das Problem wirklich nur bei generierten PDFs und versandten Mails auftritt, ist die Apache-Config wohl nicht schuld. Welche Locales haben die beiden Server denn als default im Environment? Wie sehen die Header von versandten Mails (sowohl von eurem Dev-, als auch vom Produktiv-Server) aus? Dieses fpdf-Zeug macht sich in den FAQ uebrigens selbst derb madig: http://www.fpdf.org/en/FAQ.php#q7
|
Obermotz
Fünfzylindernazi
|
Hmm, hab das Problem mittlerweile auch auf einem anderen Server auf dem Ubuntu läuft. Hab jetzt herumgewerkelt und hab die locale folgendermaßen konfiguriert:
LANG=de_AT.UTF-8
LANGUAGE=de_AT.UTF-8
LC_CTYPE="de_AT.UTF-8"
LC_NUMERIC="de_AT.UTF-8"
LC_TIME="de_AT.UTF-8"
LC_COLLATE="de_AT.UTF-8"
LC_MONETARY="de_AT.UTF-8"
LC_MESSAGES="de_AT.UTF-8"
LC_PAPER="de_AT.UTF-8"
LC_NAME="de_AT.UTF-8"
LC_ADDRESS="de_AT.UTF-8"
LC_TELEPHONE="de_AT.UTF-8"
LC_MEASUREMENT="de_AT.UTF-8"
LC_IDENTIFICATION="de_AT.UTF-8"
LC_ALL=
Sehr komisch allerdings, der Apache zeigt nach wie vor keine Umlaute an - außer die Daten kommen aus der Datenbank.
edit: solved.
Bearbeitet von Obermotz am 31.03.2010, 15:44
|
COLOSSUS
AdministratorGNUltra
|
Und wie?
|
Smut
takeover&ether
|
ev. war folgendes in der httpd/apache2.config auskommentiert:
AddDefaultCharset ISO-8859-1
edit: aha ok, zu schnell gelesen.
jo, lösung bitte bei sowas immer posten, ich hasse es mit google auf solche threads zu stoßen!
|
Obermotz
Fünfzylindernazi
|
Das Problem war (entgegen meiner Vermutung) Anwendungsspezifisch, darum keine Lösung 
|
jives
And the science gets done
|
Darf ich trotzdem nachhaken und nach dem Problem bzw. der Lösung fragen? Ein paar Stichworte würden schon reichen...
Ich glaube nämlich, vor einiger Zeit auf etwas Ähnliches gestoßen zu sein und keine Lösung gefunden zu haben.
|
mat
AdministratorLegends never die
|
Aus meiner Erfahrung heraus ist es am besten, wenn Apache-seitig "AddDefaultCharset Off" gesetzt wird und die HTML-Seite per Meta-Tag das Charset selbst bestimmt. Natürlich schließt das nicht aus, dass es noch Probleme mit der DB-Verbindung, der DB-Struktur und der Kodierung der Dateien geben kann.
|
COLOSSUS
AdministratorGNUltra
|
Aus meiner Erfahrung heraus ist es am besten, wenn Apache-seitig "AddDefaultCharset Off" gesetzt wird und die HTML-Seite per Meta-Tag das Charset selbst bestimmt. Imho ist das keine keine empfehlenswerte Loesung - diese Information gibt es dann nur in HTML, und sobald man mal andere Textdaten via HTTP transportiert braucht man erst wieder einen korrekten Content-Type mit entsprechendem Charset im Header. Und da gehoert die Information auch hin. Letztendlich kommt man um eine korrekte Konfiguration des Webservers nicht herum. Sollte dieser keine entsprechende Flexibilitaet oder Konfigurierbarkeit fuer den Content-Type bieten → weg damit.
|
mat
AdministratorLegends never die
|
Imho ist das keine keine empfehlenswerte Loesung - diese Information gibt es dann nur in HTML, und sobald man mal andere Textdaten via HTTP transportiert braucht man erst wieder einen korrekten Content-Type mit entsprechendem Charset im Header. Und da gehoert die Information auch hin. Deshalb gibts ja AddCharset. AddDefaultCharset dient nur der Bequemlichkeit und wird genau dann ungut, wenn mehrere Charsets innerhalb eines Vhosts verwendet werden (müssen). Meine Antwort oben war also nicht genau genug: 1.) AddDefaultCharset Off 2.) AddCharset für diverse File Extensions (halte ich derzeit bis PHP6 mit voller UTF8-Unterstützung kommt noch in 8859-15, falls möglich) 3.) HTML => Meta-Tag
|
Anmeldung