Die Zeichen in HTML-Dokumenten liegen in einer bestimmten Codierung vor, welche vom Editor festgelegt wird. CGI-Scripts geben ebenfalls Zeichen aus, die in einer definierten Codierung vorliegen. Gegebenenfalls gibt es eine Datenbankanbindung, wo Benutzereingaben mit der richtigen Zeichencodierung gespeichert und wieder ausgegeben werden sollen. Um diese Dinge geht es hier.
Reicht es, die Dateien in UTF-8 oder ISO-8859-1 oder in irgendeiner anderen Codierung zu speichern? Weit gefehlt! Es müssen mehrere Dinge in Einklang gebracht werden, damit die Darstellung korrekt ist:
Ersteres wird mit dem Editor festgelegt, moderne Texteditoren bieten die Wahl zwischen ANSI und UTF-8. Die Codierung der Zeichen in ANSI entspricht weitgehend der ISO-Codierung und ist abhängig von der Sprache des Betriebsystems, auf dem die Datei erzeugt wird. In der Regel werden dabei deutsche Umlaute in HTML-Dateien, die in ANSI auf einem deutschsprachigen XP gespeichert wurden, für den Browser mit der Codierung ISO-8859-1 richtig dargestellt. Sofern HTML-Dateien in UTF-8 gespeichert werden, ist zu beachten, dass keine BOM (Byte Order Mark) mitgespeichert wird, diese Einstellung ist also im Editor vorzunehmen.
Im HTML-Header muss die verwendete Codierung deklariert werden wie folgt:
<head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head>
Wobei an dieser Stelle natürlich auch eine andere Codierung, beispielsweise ISO-8859-1 angegeben werden kann. Auf jeden Fall ist es empfehlenswert, über die gesamte WebSite eine einheitliche Codierung zu verwenden, das erspart unnötige Convertierungen und vereinfacht die Fehlersuche bei möglichen Darstellungsproblemen.
Nach diesen ersten Amtshandlungen kann die HTML-Datei dem Webserver übergeben werden, möglicherweise jedoch, wird sie dennoch nicht richtig dargestellt. Betrachten wir dazu das HTTP-Protokoll genauer gesagt: den HTTP-Header, der vom Webserver erzeugt und noch vor der eigentlichen Datei gesendet wird. Bei einigen Browsern gibt es die Möglichkeit, ein PlugIn zu installieren, womit der Response-Header des Webservers angezeigt werden kann. Das Header-Feld, was hierzu von Interesse ist, heißt Content-Type:
Content-Type: text/html; charset=UTF-8
Merke: Die Angabe des MIME-Type (text/html) und die Angabe des charset (UTF-8) erfolgt in einer Zeile, es ist ein Feld im Header des HTTP-Protokolls was trotz dieser Zweifaltigkeit Content-Type heißt! Falls im HTTP-Header die Angabe charset=... fehlen sollte, ist es möglich, dass der Browser die Codierung nicht erkennt und es somit zu einer fehlerhaften Darstellung kommen kann. Zum Komplettieren des Content-Type-Header-Fields ist ein Eingriff in die Konfiguration des Webservers erforderlich, das kann in der Datei .htaccess gemacht werden (Apache-Webserver):
AddDefaultCharset UTF-8
Wenn somit alles richtig konfiguriert wurde (Kontrolle HTTP-Header!), sollte es keine Darstellungsprobleme mehr geben. Im Zweifelsfall konsultieren Sie Ihren Provider.
Solange ein Script (Perl, PHP) keine HTML-Ausgaben mit print() oder echo erzeugt, ist es gleichgültig, in welcher Codierung die Datei gespeichert wird. Das liegt daran, dass sämtliche Anweisungen und Script-Code in Zeichen geschrieben sind, die sowohl in ANSI, DOS, ASCII, ISO oder UTF-8 gleichermaßen codiert sind: a-z, A-Z, 0-9 und Interpunktionszeichen sind Zeichen einer 7-Bit-Codierung, der gemeinsame Nenner ist ASCII (128 mögliche Zeichen). In dem Moment jedoch, wo eine print-Anweisung notiert ist, kommt die Frage nach der Zeichencodierung ins Spiel:
print "München"; # Perl echo "München"; // PHP
Merke: Die print- bzw. echo-Anweisung verwendet diejenige Zeichencodierung, die beim Speichern der Script-Datei angegeben wurde. Wurde das Script in UTF-8 gespeichert, schicken obenstehende Anweisungen den Text "München" auch UTF-8-codiert auf STDOUT (oder den entsprechenden Handle, beispielsweise in eine Datei).
Die Deklaration im HTML-Header erfolgt bei Scripts, die HTML ausgeben, ganz genauso, wie weiter oben in den Abschnitten zu HTML-Dateien beschrieben. Vor der Ausgabe von HTML muss ein CGI-Script den richtigen Content-Type anweisen, Beispiel in Perl:
print "Content-Type: text/html; charset=UTF-8\n\n";
womit der Webserver den richtigen Content-Type in den HTTP-Header einbauen kann und es ist auch goldrichtig empfehlenswert, die Deklaration der Zeichencodierung an dieser Stelle vorzunehmen.
In Perl-Scripts, die in utf-8 gespeichert sind, sollten folgende Zeile enthalten:
use utf8;
Damit wird bereits dem Perl-Interpreter signalisiert, dass die Datei utf-8-codiert vorliegt. Andererseits gibt der Interpreter eine Fehlermeldung aus, wenn eine print-Anweisung Umlaute enthält:
Malformed UTF-8 character (1 byte, need 6) at...
Dieselbe Meldung, die im Browser zu einem Error 500 führt, wird auch ausgegeben, wenn in einem Perl-Script, was nicht in utf-8 gespeichert ist, Umlaute innerhalb einer Regular-Expression notiert sind, beispielsweise zum Filtern/Prüfen von Benutzereingaben.
PHP als Preprocessor parst die Datei und führt den Code aus, sofern zwischen den Token <?php ?> PHP-Code eingebaut ist. Der Content-Type-Header wird dazu automatisch generiert, phpinfo() zeigt im Abschnitt HTTP Headers Information an, welcher Wert für das Feld Content-Type konfiguriert ist, beispielsweise: text/html; charset=UTF-8. Im Abschnitt PHP Core ist außerdem beschrieben, was für default_charset und default_mimetype eingestellt ist. Zum Erzeugen eines davon abweichenden HTTP-Headers gibt es die die Funktion header():
header("Content-Type: text/html; charset=UTF-8"); // Empfehlung w3.org
Wenn jedoch der Parser bereits selbst den Webserver bezüglich Content-Type angewiesen hat, führt der Einbau obenstehender Zeile zu einer Warnmeldung, die besagt, dass der Header bereits gesendet wurde, wobei das Feld "Content-Type...; charset..." nicht unbeding den gewünschten Vorstellungen entspricht. Das ist immer dann der Fall, wenn außerhalb der Token <?php ?> HTML-Code oder andere Zeichen notiert sind, das können auch Leerzeichen, Zeilenümbrüche oder Tabulatoren vor <?php oder nach ?> sein und das gilt ebenso auch für Dateien, die mit include() eingebunden wurden. Was auch gerne übersehen wird: PHP-Dateien dürfen keine BOM enthalten.
Merke: Perl- und PHP-Scripts senden das Header-Feld Content-Type unabhängig von der Konfiguration des Webservers und legen damit die Zeichencodierung für die HTTP-Response fest.
Benutzereingaben aus HTML-Forms kommen mit der Zeichencodierung am Server an, mit der das Formular an den Browser ausgeliefert wurde. Entscheidend hierzu ist, wie weiter oben bereits dargelegt, die Angabe des "Content-Type; charset=..." im HTTP-Header, welcher dem Senden des Formulars vorausgeht. Wenn also das Formular mit einem Content-Type: text/html; charset=UTF-8 ausgeliefert wurde, kommen die Eingaben auch UTF-8-codiert am Server an, es sei denn, der Benutzer hat vor dem Absenden des Formulars eine abweichende Codierung eingestellt. Letzteres lässt sich nicht verhindern, es kann jedoch anhand von mitgeschickten "Referenzzeichen" geprüft werden, ob eine benutzerseitige Änderung vorliegt.
Die Codierung ist unabhängig vom Content-Type-Header, der dem Senden des Formulars vorausging. Für einen POST wird UTF-8 verwendet, d.h., nach dem Einlesen eines Eingabefelds mit JavaScript wie untenstehend:
var cin = document.getElementById('cin').value;
und der anschließenden Übertragung mit Ajax und Request-Method = POST kommen alle eingegebenen Zeichen utf-8-codiert zum Server.
Für die Request-Method GET muss die Eingabe URL-encodet werden, wofür das DOM entsprechende Funktionen hat:
msg = escape(document.getElementById('msg').value); // ISO-8859-1
msg = encodeURI(document.getElementById('msg').value); // UTF-8
msg = encodeURIComponent(document.getElementById('msg').value); // UTF-8 weitere Zeichen
Die Funktion encodeURIComponent() codiert neben den Umlauten auch Sonderzeichen, die sonst dem HTTP-Protokoll vorbehalten sind, z.B. das Ampersand: & ein Ampersand in der Benutzereingabe würde ohne diese Funktion zwar auch beim Server ankommen, jedoch nicht als Benutzereingabe gewertet sondern als Trennzeichen einer Parameterliste.
Merke: Die Funktion escape() funktioniert nur bei Zeichen der ISO-8859-1-Tabelle zuverlässig und ist als deprecated einzustufen.
Für die Response auf einen Ajax-Request ist der HTTP-Header genauso festzulegen, wie für jede andere Response in welcher text/html oder text/plain oder text/xml usw. gesendet werden soll, z.B.:
header("Content-Type: text/xml; charset=UTF-8"); // PHP
Danach folgt die Response mit dem Text in der gewünschten Codierung, die nicht zwingend UTF-8 sein muss. Je nach Verwendungszweck kann das durchaus eine andere Codierung sein, mehr dazu hier und da.
Ab Version 5 unterstützt MySQL die Deklaration von Zeichencodierungen an Datenbanken und Tabellen sowie die Konfiguration von Collationen die spaltenbezogen sein können. Im Einzelnen:
Betrachte untenstehendes Create-Table-Statement:
CREATE TABLE onkz ( onkz varchar(100) NOT NULL default '0', ort varchar(100) NOT NULL default '', info varchar(100) default '', KEY idx (ort) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Die letzte Zeile enthält den TabellenTyp und die Deklaration der Zeichencodierung. Letzteres legt fest, wieviel Speicher für ein Zeichen reserviert wird: Bei CHARSET=latin1 werden pro Zeichen 8 Bit = 1 Byte reserviert. Mit der Angabe CHARSET=utf8 jedoch, werden pro Zeichen 3 Byte (24 Bit) reserviert, also dreimal soviel wie für ISO-Zeichen. Die Codierung der Zeichen selbst innerhalb der Tabelle, ist davon unabhängig. Wenn der Anteil derjenigen Zeichen, die mehr als 1 Byte Platz benötigen, gegenüber dem restlichen Text gering ist, wäre zu überlegen, ob tatsächlich für jedes Zeichen 3 Byte reserviert werden sollen.
Merke: Textfelder können in MySQL Zeichen verschiedener Codierungen beeinhalten. UTF8-codierte Zeichen haben einen erhöhten Speicherbedarf gegenüber ISO-codierten Zeichen, können jedoch ohne Datenverlust in Latin-deklarierten-Tabellen gespeichert sein, sofern genügend Platz reserviert ist (Latin1 = ISO-8859-1).
Untenstehend ein Auszug aus einem Create-Table-Statement:
`msg` text character set latin1 collate latin1_german1_ci NOT NULL,
Für das Feld 'msg' (type text) ist hier einmal die Zeichencodierung deklariert und die Collation festgelegt. Bezüglich Charset gilt auch hier das weiter oben Gesagte, die Collation hingegen ist von Bedeutung bei allen Funktionen, in denen Stringvergleiche eine Rolle spielen, beispielsweise in WHERE-Klauseln oder Suchvorgängen mit LIKE.
Merke: Auf die Angabe einer Collation kann verzichtet werden, sofern die Zeichen in Vergleichs- oder Suchfunktionen gleichermaßen codiert sind. Die Collation kann anders lauten als die Deklaration der Zeichencodierung und kann auch für Suchvorgänge im Statement selbst festgelegt, muss also nicht fest an die Spalte seitens MySQL gebunden sein.
Gegeben sei die Tabelle 'onkz' nach obenstehenden Muster. Alle Zeichen in den Spalten (Feldern) 'info' und 'ort' liegen utf8-codiert vor, Datensatz-Beispiel:
| onkz | ort | info |
|---|---|---|
| 089 | München | Landeshauptstadt |
Per WebFormular soll nun eine Suche mit LIKE auf das Feld 'ort' erfolgen. Das WebFormular ist als CGI in Perl geschrieben und kommt utf-8-codiert zum Browser:
print "Content-Type: text/html; charset=utf-8\n\n";
Das wäre also als Erstes zu prüfen, siehe ScreenShot (FF-Plugin Tamper Data):
Wie der ScreenShot zeigt, wird der HTTP-Header mit dem gewünschten Content-Type ausgegeben. Das Nächste ist die Übertragung der Eingabe per HTTP, die soll ja auch in UTF-8 erfolgen, also tippen wir mal als Suchstring 'München' ein und sehen in der Adresszeile:
http://rolfrost/cgi-bin/onkz.cgi?q=M%C3%BCnchen
Was ebenfalls korrekt ist, denn das 'ü' wird im URI als Hex-Wert C3BC codiert und das entspricht UTF-8 (nicht zu verwechseln mit dem Codepoint eines Zeichens! Siehe dazu auch die Anlage). Jetzt muss, ausgehend davon, dass die Zeichen mit der richtigen Codierung am Server ankommen, dafür gesorgt werden, dass die auch in MySQL genauso in LIKE eingebaut werden. Vorher wird im Perl-Script noch die Eingabe gefiltert, damit keine unerwünschten Zeichen eingeschmuggelt werden. Das Perl-Script ist in utf8 gespeichert, so kann folgende RegEx notiert werden:
use utf8; $q =~ s/[^0-9a-zA-Zäöüß]//g;
was alle unerwünschten Zeichen rausfiltert. Nun kann die LIKE-Abfrage dem Perl-Modul DBI.pm übergeben werden. Das DBI-Modul ist für Zeichencodierungen transparent, d.h., die dem Database-Handle im SQL-Statement übergebene Zeichencodierung wird nicht verändert und kommt genauso an wie in das Statement gegeben. Wir können an dieser Stelle davon ausgehen, dass die Suchanfrage einen Match ergibt, auch ohne Angabe einer Collation. Sofern eine solche Suchanfrage leer sein sollte, würde das bedeuten, dass die Zeichencodierung in der Tabelle nicht stimmt. Für eine Prüfung der Zeichencodierung in der Tabelle brauchen wir eine geeignete Abfrage und ein Konsolenfenster mit der gewünschten Zeichencodierung, auf einem CentOS gibt es dafür Locale und für eine bash die .bashrc wo das entsprechend gesetzt werden kann:
# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
# User specific aliases and functions
export LC_COLLATE="de_DE.ISO-8859-1"
export LC_CTYPE="de_DE.ISO-8859-1"
# oder UTF-8
Am mysql-Prompt sollte eine geeignete Abfrage darüber Klarheit verschaffen, in welcher Codierung die Zeichen in der Tabelle vorliegen. Gegebenfalls wird die Ausgabe mit \T outfile in eine Datei geleitet und diese mit einem Editor betrachtet.
Sofern ein Konsolenzugriff auf dem entfernten Server nicht gegeben ist, wird es etwas schwieriger. Wichtig ist eine DB-Anbindung, die hinsichtlich Zeichencodierung transparent ist, das ist mit dem PerlModul DBI der Fall. Siehe also Remote Datenbank Management mit Perl.
Zum Schluss haben wir noch das Suchergebnis darzustellen. Die Frage der Zeichencodierung in MySQL hätten wir geklärt und das DBI-Modul ändert daran auch nichts. Das Suchergebnis wird mit dem richtigen Content-Type-Header (charset) ausgegeben und sollte damit einwandfrei lesbar sein. Ansonsten ist der HTTP-Header zu konsultieren. Ein weiteres hilfreiches Werkzeug ist der validator.w3.org, auch damit lassen sich Fehler in der Zeichencodierung leicht eingrenzen.
Kurze Antwort: Mit dieser Codierung ist jedes Zeichen eindeutig codiert.
Längere Antwort: Es gibt Zeichen, die werden Sie in ISO-8859-Tabellen vergeblich suchen, z.B. das Eurozeichen. Wenn Sie eine HTML-Datei in ANSI speichern, kann es durchaus sein, dass Sie zwar das Eurozeichen im Editor richtig als € sehen, wobei es jedoch vom Browser abhängt, ob ANSI-Zeichen (Windows Codepage 1252) Ihren Vorstellungen entsprechend dargestellt werden oder eben auch nicht. Sie könnten zwar mit dem HTML-Entity € das Zeichen richtig darstellen, besser jedoch ist es, die Datei gleich in der passenden Codierung zu speichern, also in UTF-8.
Ein bischen komplizierter wird es, wenn Benutzereingaben zu erwarten sind und verarbeitet werden sollen. Ein Besucher, der kyrillische Zeichen eingibt, bekommt die in ISO-8859-1 verständlicherweise ganz anders angezeigt als in ISO-8859-5, beide Codierungen sind also nebeneinander nicht gleichermaßen lesbar darstellbar, denn für eine Seite kann es nur eine Codierung geben.
| Zeichen | ISO-8859-1 | UTF-8 | Codepoint | UTF-8-Codierung |
|---|---|---|---|---|
| ä | %E4 | %C3%A4 | U+00E4 | C3A4 |
| ö | %F6 | %C3%B6 | U+00F6 | C3B6 |
| ü | %FC | %C3%BC | U+00FC | C3B6 |
| Ä | %C4 | %C3%84 | U+00C4 | C384 |
| Ö | %D6 | %C3%96 | U+00D6 | C396 |
| Ü | %DC | %C3%9C | U+00DC | C39C |
| ß | %DF | %C3%9F | U+00DF | C39F |
Linkstehende Tabelle zeigt, wie einige Zeichen in einem URI codiert per HTTP übertragen werden. Derartige URIs sind in der Adresszeile des Browsers zu sehen, wenn das Formular mit der Request-Methode "GET" abgeschickt wurde, d.h., dieses Encoding besorgt der Browser.
Die Angabe der Codierung in nebenstehender Tabelle bezieht sich auf das Formular, mit welchem der Request ausgeführt wird.
Für Ajax-Requests muss sich der Programmierer selbst darum kümmern, dass der URI mit den Parametern ordentlich codiert wird. Dafür gibt es die DOM-Methoden escape() für ISO und encodeURI() für eine UTF-8-gerechte Codierung.
Betrachten wir untenstehendes Perl-Script, das Script ist in der Codierung utf-8 gespeichert, in der Datei selbst liegt das Zeichen 'ä' also utf-8-codiert vor:
printf "Vector: %vX\n", 'ä'; # Vector: C3.A4
Das Flag v steht für Vector und zeigt die Bitfolge als Integer (hexadezimal), mit welcher Zeichen 'ä' aus der Datenquelle (Datei) gelesen wird. Würde das 'ä' ISO-8859-1-codiert vorliegen, zeigte obenstehende Perlzeile die Bitfolge als E4.
Diese Datenquellen sind für den Webdesigner von Interesse:
All diese Datenquellen liefern Zeichen als Bitfolge, außer dem QUERY_STRING bei GET-Parametern: Hier ist die Bitfolge in eine Folge von in der URL sichtbaren Zeichen umgewandelt, aus C3.E4 wird %C3%E4.
Das Ausgabegerät muss nun aus dieser Bitfolge die Zeichen zurückcodieren, dazu muss ein Ausgabegerät wissen, in welcher Codierung das erfolgen soll, damit das oder die Zeichen lesbar sind.
Schlicht und ergreifend einfach kann auch hier an dieser Stelle festgestellt werden, dass Schriftzeichen nur dann lesbar sind, wenn die Codierung bei der Eingabe in eine Datenquelle die gleiche Codierung ist, mit der diese Zeichen nach dem Lesen der Datenquelle für die Ausgabe im Browser oder einem Editor zurückcodiert werden.
Betrachten wir nun noch das Eurozeichen, so wie es von einer Tastatur unter XP in eine ANSI Datei eingegeben und abgespeichert wurde. Obenstehender Perlcode zeigt als Vector eine 80 (dezimal 128). Mit einer 8 Bit Codierung wird so der € unter Windows auf Codepage 1252 geführt. Um die Verwirrung komplett zu machen, gibt es noch den Standard ISO-8859-15 für Westeuropäische Zeichen, dort steht der Euro an Position A4 (dezimal 164). Der Codepoint des € jedoch, ist U+20AC (dezimal 8364, Unicode) und in UTF-8-codiert liegt das Eurozeichen als Bitfolge E2.82.AC vor.
Merker: Handle wie STDIN oder Dateihandle liefern Bitfolgen, die zwar abhängig von der Zeichencodierung sind aber die Codierung selbst ist nicht an das Handle gebunden. Ein Handle stellt lediglich den Transport Layer dar, der vom Presentation Layer (Darstellungsebene, Content-Type) klar getrennt ist. Ein Handle kennt weder den Content-Type noch den Charset!
Diese Zeichen sehen Sie genau dann, wenn die Zeichen UTF-8-codiert in einer Datei vorliegen, jedoch in Codierung ANSI mit dem Editor betrachtet werden.
Gleichermaßen werden UTF-8-codierte Zeichen (links) so wie in er rechten Spalte vom Browser wiedergegeben, wenn an diesem die Codierung ISO-8859-1 eingestellt ist.
Das Zeichen à (zweite Spalte) entspricht dem ersten Integer des Zeichenvectors, dezimal 195, hexadezimal C3, was folgenden Sachverhalt veranschaulicht: der Browser versucht, aufgrund einer Fehlcodierung den Vector darzustellen und interpretiert diesen als zwei Zeichen, weil in ISO ein Zeichen mit 8 Bit codiert ist. Den Euro übrigens, würde der Browser in diesem Fall als € darstellen (Vector E2.82.AC), wobei das mittlere Zeichen von manchen Browsern nicht als x82 sondern als x201A übersetzt und dargestellt wird, diese Übersetzung basiert auf der der Codetabelle Windows 1252.
Unicode ist ein System bzw. ein Standard, eine Ordnung, in der jedem Zeichen eine eindeutige Nummer zugeordnet ist. Diese Nummer ist der Codepoint und wird im Allgemeinen so dargestellt: U+20AC, wobei das U für Unicode steht und die Ordnungsnummer hexadezimal nach dem +Zeichen folgt.
UTF-8 ist eine Codierung, genauso wie jede andere Codierung, beispielsweise ISO-8859-1, mit der die Bitfolge eines Zeichens festlegt wird. Hierzu noch etwas Perl-Code:
# Erzeuge ein UTF-8-codiertes Zeichen anhand der Angabe des Codepoints
my $chr = pack("U", $codepoint);
$chr = pack("U", 0x20AC); # erzeugt ein UTF-8-codiertes EURO-Zeichen
# Das Zeichen in eine Bitfolge umwandeln und die Bitfolge ausgeben
# hexmap erzeugen
my %hexmap = map{ chr($_), sprintf("%02X", $_) }(0..255);
$chr =~ s/(.*?)/$hexmap{$1}/g;
print $chr; # E282AC Bitfolge des Eurozeichens
In Perl zwei Funktionen zum Convertieren utf-8-codierter Zeichen in ISO-8859-1-Codierung und umgekehrt:
sub utf8_to_latin1{return(pack("C*", unpack("U*", shift)))}
sub latin1_to_utf8{return(pack("U*", unpack("C*", shift)))}
Die Convertierung funktioniert nur für Zeichen der ISO-8859-1-Tabelle (Latin1)!
Die ISO-8859 Tabellen zeigen Zeichen für die Codierungen in ISO-8859-1 bis ISO-8859-10.
Tabellen für UTF-8-codierte Zeichen sind hier abrufbar. Mit diesem Tool hier kann zu jedem beliebigen eingegebenen Zeichen der Codepoint ermittelt werden, weiterhin wird der Vector (vector of integers) angezeigt, mit welchem das Zeichen übertragen wurde.
Das nächste Tool kann zum Testen verwendet werden, es zeigt die Codierung der Übertragung von Zeichen mit Ajax GET/POST (JavaScript ist erforderlich).
Das Script Charset zeigt Ihnen, wie UTF-8-Zeichen bzw. ISO-8859-1-Zeichen mit dem jeweils falschem HTTP-Header im Browser dargestellt werden.
Last-Modified: Tue, 22 Jun 2010 19:50:33 GMT