Zeichenkodierung – wahrscheinliche Ursache
Auch nach 4-stündiger Suche konnte ich das Problem mit der Zeichenkodierung in der Live-Umgebung – also hier – nicht ausfindig machen. In der Test-Umgebung lief alles reibungslos.Nach weiteren zwei Stunden habe ich nun eine wahrscheinliche Ursache für das Problem mit der Zeichenkodierung gefunden.
Nachdem ich mit dem W3C Markup Validator Service meine Homepage gescannt habe, wurde folgende Warnung ausgegeben:
Important Warnings
The validator has found the following problem(s) prior to validation, which should be addressed in priority:
Warning Character Encoding mismatch!
The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the <meta> element (utf-8). I will use the value from the HTTP header (iso-8859-1) for this validation.
In Folge dessen begab ich mich auf die Suche nach einen HTTP Header Analyser und wurde auch relativ schnell fündig. Über den HTTP-Header Analyser von der Firma sitepoint GmbH konnte ich folgende Daten für http://www.danielmayr.at auslesen:
HTTP/1.1 200 OK
Date: Sun, 29 Jul 2007 21:33:07 GMT
Server: Apache/2.0.59 (NETWARE) PHP/5.2.3 mod_jk/1.2.15
Accept-Ranges: bytes
X-Powered-By: PHP/5.2.3
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Der in Fettschrift gekennzeichnete Bereich könnte nun eine wahrscheinliche Ursache für das Problem mit der Zeichenkodierung sein. Auch wenn im HTML-Header UTF-8 angegeben ist, scheint der Tag im HTTP-Header vorrangig zu sein.
Der Vollständigkeit halber habe ich den HTTP-Header für das Forum ebenfalls noch auslesen lassen:
HTTP/1.1 301 Moved
Date: Mon, 30 Jul 2007 11:05:09 GMT
Server: Apache/2.0.59 (NETWARE) PHP/5.2.3 mod_jk/1.2.15
Location: http://www.danielmayr.at/forum//
Content-Length: 347
Connection: close
Content-Type: text/html; charset=iso-8859-1
Sollte eine News auf Grund dieser falschen Kodierung nicht lesbar sein, dann könnt ihr die Zeichenkodierung über den Menüpunkt Ansicht sehr rasch umstellen. Jedoch muss dies bei jedem Neuaufruf umgestellt werden.
Ich werde mit meinem Provider in Kontakt treten, um dieses Problem so schnell wie möglich beheben zu können.
Vielen Dank für euer Verständnis.
Update: (01.08.2007 22:30 Uhr)
Ich habe einen weiteren Test durchgeführt, dessen Ergebnis sehr interessant ist. Ich habe eine HTML-Datei erstellt und im META-Tag den "charset"-Wert auf "UTF-8" gestellt. Anschließend habe ich diese Datei ins Stammverzeichnis hochgeladen. Genau dieselbe Datei habe ich nochmals hochgeladen, diesmal jedoch mit der Endung ".PHP". Der Inhalt beider Dateien ist komplett identisch. Hier nun also die HTTP-Header-Daten für index-utf8.html und index-utf8.php:
index-utf8.html:
HTTP/1.1 200 OK
Date: Wed, 01 Aug 2007 19:43:37 GMT
Server: Apache/2.0.59 (NETWARE) PHP/5.2.3 mod_jk/1.2.15
Last-Modified: Wed, 01 Aug 2007 19:34:29 GMT
eTag: "821158-159-6a14db40"
Accept-Ranges: bytes
Content-Length: 345
Connection: close
Content-Type: text/html
index-utf8.php:
HTTP/1.1 200 OK
Date: Wed, 01 Aug 2007 19:43:45 GMT
Server: Apache/2.0.59 (NETWARE) PHP/5.2.3 mod_jk/1.2.15
Accept-Ranges: bytes
X-Powered-By: PHP/5.2.3
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Interessant hierbei ist, dass die PHP-Datei automatisch den "charset"-Wert "ISO-8859-1" zugewiesen bekommt.
Zudem macht es keinen Unterschied, ob sich die Datei im Stammverzeichnis befindet oder nicht. Beide Dateien sind ebenfalls im temporären Ordner "utf8" ersichtlich.
Nachdem das Problem mit der Zeichenkodierung gelöst wurde, werden die Dateien und Ordner wieder gelöscht.
Folglich werde ich erneut mit meinem Provider in Kontakt treten, um dieses Problem so schnell wie möglich zu beheben.
Vielen Dank für euer Verständnis.