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.