Praxis-Tips
Umlaute/UTF-8
Normalisierung
OemToAnsi
MySQL-Import
Site-Suche
City Desk
DynDNS
MXLookup
SPAM
Deutsche Umlaute und UTF-8
Von Antje Binas-Holz
Netcat is eines der besten TCP-Tools, die es gibt. Man kann mittels Netcat TCP-Server und Clients implementieren, ohne eine einzige Zeile Code schreiben zu müssen. Das Tool ist Freeware und ist unter anderem auf vulnwatch.org zu finden.
Letzte Änderung: Donnerstag, 29. Dezember, 2005
Aus aktuellem Anlaß möchte ich eine Frage im Forum zum Thema UTF-8 aufgreifen und etwas ausführlicher erläutern. Das Problem kam bei der Benutzung von CityDesk als Content-Manager auf. Trotz absolut richtiger Konfiguration des Templates wurden Zeichen über 127, z.B. deutsche Umlaute, durch den Browser nicht richtig dargestellt. Was lief hier schief?
CityDesk speichert alle Texte in Unicode ab, genauer gesagt als UTF-8. Deshalb muß charset=UTF-8 als Meta-Tag im Header vereinbart werden. Entsprechende Hinweise sind in der Hilfe zu CityDesk zu finden. Der beste Platz dafür ist natürlich das entsprechenden Template, in dem alle HTML-Header-Tags vereinbart werden sollten, z.B.:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" >
Leider stellte sich heraus, daß damit das Problem nicht zu lösen war. Offensichtlich ignorierte der Browser diesen Eintrag. Schuld daran war der Server, der bei allen Requests folgenden HTTP-Response-Header zurückschickte:
Content-Type: text/html; charset=ISO-8859-1
Mit anderen Worten, der im HTML-Header vereinbarte charset wird durch den HTTP-Header außer Kraft gesetzt. In diesem Fall muß der Webserver umkonfiguriert werden. Er sollte den Charset nicht festlegen und es dem Webdesigner überlassen (HTML-Code), was er wählt. Zum Beispiel könnte der Server niemals russische oder arabische Websites hosten, mit dieser Konfiguration.
Falls der Webserver ein Apache ist, so steht wahrscheinlich folgende Zeile im Setup (http.conf):
AddType "text/html; charset=ISO-8859-1" html
Diese sollte einfach wie folgt geändert werden:
AddType "text/html" html
oder
AddType "text/html; charset=UTF-8" html
Diese Response-Header sind im Browser nicht sichtbar, aber man kann sie sehen, wenn man mit Telnet auf die entsprechende Seite geht oder sich eines kleinen, aber mächtigen Tools bedient: Netcat.
Ursprünglich ein Unix-Tool ist es inzwischen auch für Windows verfügbar (siehe Info-Kasten). Es wird oft auch als das "TCP/IP swiss army knife" bezeichnet, was gar nicht so abwegig ist. Mit Netcat kann man sehr einfach TCP-Verbindung herstellen, da es sowohl als im Client- als auch im Server-Modus verwendet werden kann. Es ermöglicht nämlich, Text-Daten bzw. Dateien zwischen zwei Computern zu übertragen, bei denen Netcat jeweils im Server bzw. Client-Modus gestartet wird. Natürlich "spricht" Netcat mit jedem TCP-Server und kann deshalb u.a. zur Ermittlung des HTTP-Response-Headers verwendet werden, den der Browser uns naturgemäß vorenthält. Gesetzt den Fall, wir verwenden ein Windows-System, so könnte folgendes Skript (httptest.bat) den HTTP-Response-Header inklusive Quelltext der aktuellen Webseite ermitteln, die Sie gerade eben studieren:
del request.txt
echo GET /ger/sections/tips/utf8.html HTTP/1.0> request.txt
echo Accept: */*>> request.txt
echo User-Agent: Mozilla/4.0>> request.txt
echo Host: www.sqldbu.com>> request.txt
echo.>>request.txt
type request.txt | netcat -w 3 -i 1 www.sqldbu.com 80 > response.txt
Der Einfachheit halber habe ich hier die eigene Website ermittelt, das Skript kann natürlich für jede andere Seite angepaßt werden. Nehmen wir an, die Seite, die keine UTF-8-Umlaute anzeigt, heißt /de/index.html und liegt auf www.badserver.de, so muß unser Request-Skript wie folgt angepaßt werden:
del request.txt
echo GET /de/index.html HTTP/1.0> request.txt
echo Accept: */*>> request.txt
echo User-Agent: Mozilla/4.0>> request.txt
echo Host: www.badserver.de>> request.txt
echo.>>request.txt
type request.txt | netcat -w 3 -i 1 www.sqldbu.com 80 > response.txt
Nach der Ausführung des Skripts könnte ein Blick in die Datei Response.txt folgendes zutage fördern:
HTTP/1.1 200 OK
Date: Wed, 14 Dec 2005 13:05:40 GMT
Server: Apache/1.3.28 (Unix) FrontPage/5.0.2.2634 PHP/4.3.3 AuthMySQL/2.20 mod_ssl/2.8.15 OpenSSL/0.9.7a
Last-Modified: Wed, 14 Dec 2005 12:59:50 GMT
ETag: "394263-3850-43a01746"
Accept-Ranges: bytes
Content-Length: 14416
Connection: close
Content-Type: text/html; charset=ISO-8859-1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
...
</html>
Sollten Sie zu diesen oder ähnlichen Ergebnissen bei der Fehleranalyse kommen, dann sprechen Sie mit Ihrem Provider. Wie bereits erwähnt kann nur der Administrator des Webservers das Problem wirklich beheben, den Server also dahingehend verbessern, daß im Response-Header der Character-Set nicht festgelegt wird, z.B.:
Content-Type: text/html
Um sicher zu gehen, daß diese Maßnahme Ihr Problem wirklich behebt, starten Sie einfach mittels Netcat einen Server-Prozeß auf Ihren Computer, der genau diese mittels httptest.bat "gesaugte" HTTP-Response an den Client (Ihren Browser) schickt. Dazu dient die Datei Server.bat mit folgendem Inhalt:
:start
type response.txt | netcat -l -p 8080
goto start
Zum Testen brauchen Sie dieses Skript einfach nur zu starten und dann in Ihren Browser folgende URL eingeben:
http://localhost:8080/
Ich habe im Test bewußt den Port 8080 benutzt, falls Sie auf Ihrer Maschine zu Testzwecken bereits einen Webserver auf Port 80 gestartet haben. Ist das nicht der Fall, so können Sie natürlich auch Port 80 benutzen und im Browser lediglich
http://localhost
eingeben. Zunächst werden Sie keinen Unterschied zu Ihrer fehlerhaften "richtigen" Server-Response feststellen. Editieren Sie deshalb Response.txt dahingehend, daß Sie in der Zeile
Content-Type: text/html; charset=ISO-8859-1
den Charset-Eintrag löschen oder verändern und wiederholen Sie danach den Test. Damit können Sie bequem die unterschiedlichen Ergebnisse bei der Manipulation von Content-Type im Response-Header sowie im HTML-Quelltext untersuchen, weil Sie mittels Netcat sowohl die Server- als auch die Client-Seite in Ihrer Hand haben.
Hinweis: Die Datei utf8.zip enthält alle hier vorgestellten Skripts. Außerdem befinden sich noch einige andere Skripts darin, die jeweils einen HTTP-Server auf Netcat-Basis implementieren. Jeder von ihnen schickt den gleichen HTML-Quelltext (body.txt) mit unterschiedlichem HTTP-Header Character-Set an den jeweiligen Browser.