Was bisher geschah. Es gibt zig Zeichensätze. Welchen man benutzt, ist erstmal egal, nur muss man dies konsequent tun. XML-Dokumente müssen sagen, in welchem Zeichensatz sie zu lesen sind. HTTP legt auch einen Zeichensatz für Dokumente fest. Verschickt man also XML-Dokumente über HTTP hat man zwei Angaben über den Zeichensatz. Die XML-Spec sagt nun, das man bei doppelten Angaben denen des übergeordneten System trauen soll, in diesem Fall also denen von HTTP. Problematisch dabei: das XML-Dokument enthält deutsche Schriftzeichen, der Webserver steht aber in den USA und sendet alle Dateien mit der Zeichensatzangabe ascii aus - dieser Zeichensatz kennt keine Umlaute, das XML-Dokument ist demnach nicht wohlgeformt, peng.
Um die Verwirring perfekt zu machen, spielt neben der Angabe des Zeichensatzes auch die des Content-types in HTTP eine Rolle. In dem RFC 3023 wird nämlich festgelegt, welcher Zeichensatz bei welchem Content-type anzunehmen ist, wird kein Zeichensatz angegeben. So legt der RFC fest, das Dokumente, die als text/xml verschickt werden, den Zeichensatz us-ascii verpasst bekommen.
Das Problem liegt also im Zusammenspiel von XML und HTTP. HTTP kann Dokumente sinnvollerweise nur an Äußerlichkeiten erkennen, zum Beispiel der Dateiendung, und alle Dateien mit dem gleichen Merkmal gleich behandeln. Die Alternative wäre, bei jeder Anfrage die Angaben über Content-type und Zeichensatz direkt aus dem Dokument herauszulesen - mit dem Ergebnis, das XML-Anwendungen im Web verdammt langsam werden würden.
XML hingegen legt diese Angaben auf Dokument-Ebene fest. Äußerlichkeiten wie Dateiendungen sind XML egal, solange der Inhalt valides XML ist, wird jeder Parser es als solches erkennen und verarbeiten können.
Die Lösung des Problems muss an zwei Stellen erfolgen. Zum einen müssen Webserver korrekt konfiguriert werden, so daß sie verschiedene Typen von XML-Dokumenten mit dem korrekten Content-type ausliefern. Zum anderen müssen XML-Applikationen und Webserver aufeinander abgestimmt werden, damit beide den gleichen Zeichensatz für das selbe Dokument verwenden. Technisch ist das relativ einfach zu lösen, beispielsweise über Weiterleitungen oder dynamische Auslieferung durch Skriptsprachen, die den Content-type/charset-HTTP-Header selbst für jedes ausgelieferte Dokument setzen.
Hallo Sascha,
wie kann ein Otto-Normal-User dies beeinflüssen? Denn, zum Beispiel, benutzen User aus sowohl USA und Deutschland einen Server, der in USA steht. Kann der Server dann trotzdem so konfiguriert werden, daß er weiss, wann welches charset zu nehmen ist?
Und ausserdem, wie leicht ist der Einflussnahme, wenn es ein Server einer großen Provider betrifft???
Viele Grüsse,
Birthe
Zum Beispiel über den Virtual Host. Auf einem Apache-Server laufen bei großen Hostern x Webs, sprich Domains. In Techspeak heissen diese Dinger Virual Hosts. Es wäre ohne großen Aufwand möglich, pro Virtual Host festzulegen, mit welchem Charset die Daten verschickt werden.
Für die dynamische Variante sähe es so aus, das die Applikation, die das XML-Dokument verschickt, den Header selbst festlegt. In PHP geht dies recht einfach mit
—-da ist was verloren gegangen—-
Virtual hosts sind ja einfache Servereinstellungen. Geht es dann auch Userseitig mit zum Beispiel .htaccess?
Grüsse,
Birthe
Oops ;)
In PHP kann man mit http://php.net/header den HTTP-Header selbst beinflussen.
Was die virtuellen Hosts angeht: die werden zwar in der zentralen Apache-Konfiguration bestimmt. Aber die Konfiguration der Dateien in den VHosts sind durchaus auch über .htaccess möglich.
Das Charset kann man im Apache-httpd auf Directory-Ebene Einstellen (und damit auch in .htaccess): http://httpd.apache.org/docs-2.0/mod/core.html#adddefaultcharset