A.12 Anhang F: Automatische Erkennung von Zeichenkodierungen (nicht normativ)

Die XML-Kodierungsdeklaration fungiert als eine interne Markierung in jedem Entity, die anzeigt, welche Zeichenkodierung benutzt wird. Bevor ein XML-Prozessor die interne Markierung lesen kann, muss er offensichtlich wissen, welche Zeichenkodierung benutzt wird — was genau das ist, was die interne Markierung anzeigen will. Im allgemeinen Fall ist das eine hoffnungslose Situation. In XML ist es aber nicht völlig hoffnungslos, weil XML den allgemeinen Fall auf zwei Arten einschränkt: Es wird angenommen, dass jede Implementation nur eine endliche Menge von Zeichenkodierungen unterstützt, und die XML-Kodierungsdeklaration ist in ihrer Position und ihrem Inhalt eingeschränkt, um eine automatische Erkennung der benutzten Zeichenkodierung in jedem Entity im Normalfall zu ermöglichen. Außerdem sind in vielen Fällen zusätzlich zum XML-Datenstrom andere Informationsquellen verfügbar. Zwei Fälle können unterschieden werden, abhängig davon, ob das XML-Entity dem Prozessor ohne oder mit weiteren (externen) Informationen zur Verfügung steht. Wir nehmen zunächst den ersten Fall an.

Da jedes XML-Entity, das nicht im UTF-8- oder UTF-16-Format vorliegt, mit einer XML-Kodierungsdeklaration beginnen muss, in der die ersten Zeichen <?xml sind, kann jeder konforme Prozessor nach Einlesen von zwei bis vier Oktetten entscheiden, welcher der folgenden Fälle vorliegt. Beim Lesen dieser Liste kann es hilfreich sein, zu wissen, dass in UCS-4 das < die Kodierung #x0000003C und ? die Kodierung #x0000003F hat und dass die Byte-Order-Markierung, die von UTF-16-Datenströmen benötigt wird, die Kodierung #xFEFF hat.

• 00 00 00 3C: UCS-4, Big-endian-Maschine (Reihenfolge 1234)
• 3C 00 00 00: UCS-4, Little-endian-Maschine (Reihenfolge 4321)
• 00 00 3C 00: UCS-4, ungewöhnliche Oktett-Reihenfolge (2143)
• 00 3C 00 00: UCS-4, ungewöhnliche Oktett-Reihenfolge (3412)
• FE FF: UTF-16, Big-endian
• FF FE: UTF-16, Little-endian
• 00 3C 00 3F: UTF-16, Big-endian, keine Byte-Order-Markierung (und damit — streng genommen — fehlerhaft)
• 3C 00 3F 00: UTF-16, Little-endian, keine Byte-Order-Markierung (und damit — streng genommen — fehlerhaft)
• 3C 3F 78 6D: UTF-8, ISO 646, ASCII, einige Teile von ISO 8859, Shift-JIS, EUC oder jede andere 7-Bit-, 8-Bit-, oder Kodierung mit gemischter Breite, die sicherstellt, dass die ASCII-Zeichen ihre normale Position, Breite und Werte haben. Die tatsächliche Kodierungsdeklaration muss gelesen werden, aber da jede dieser Kodierungen die gleichen Bitmuster für ASCII-Zeichen verwendet, kann die Kodierungsdeklaration selbst sicher gelesen werden.
• 4C 6F A7 94: EBCDIC (In einigen Fällen muss die vollständige Kodierungsdeklaration gelesen werden, um sagen zu können, welche Codepage verwendet wird.)
• Andere: UTF-8 ohne Kodierungsdeklaration; andernfalls ist der Datenstrom fehlerhaft, unvollständig oder in irgendeinen Wrapper eingepackt.

Dieses Niveau der automatischen Erkennung ist ausreichend, um die XML-Kodierungsdeklaration zu lesen und den Identifier für die Zeichenkodierung zu analysieren, was immer noch notwendig ist, um zwischen einzelnen Mitgliedern einer Kodierungsfamilie zu unterscheiden (z.B. um UTF-8 von 8859 und die Teile von 8859 voneinander zu unterscheiden oder um die genaue EBCDIC-Codepage zu identifizieren).

Da der Inhalt der Kodierungsdeklaration auf ASCII-Zeichen beschränkt ist, kann ein Prozessor sicher die gesamte Kodierungsdeklaration lesen, sobald er erkannt hat, welche Kodierungsfamilie verwendet wird. Da praktisch alle weit verbreiteten Zeichenkodierungen in eine der oben genannten Kategorien fallen, erlaubt die XML-Kodierungsdeklaration eine hinreichend zuverlässige Selbstbeschreibung der Zeichenkodierungen, selbst wenn externe Informationsquellen auf Ebene des Betriebssystems oder Transport-Protokolls unzuverlässig sind.

Hat der Prozessor einmal die verwendete Zeichenkodierung erkannt, kann er angemessen handeln, sei es durch den Aufruf einer für jeden Fall separaten Eingaberoutine oder den Aufruf einer geeigneten Konvertierungsfunktion für jedes Eingabezeichen.

Wie jedes selbstkennzeichnende System wird auch die XML-Kodierungsdeklaration nicht funktionieren, falls irgendeine Software den Zeichensatz oder die Kodierung des Entity ändert, ohne die Kodierungsdeklaration zu aktualisieren. Programmierer von Routinen zur Zeichenkodierung sollten mit Sorgfalt die Korrektheit von internen und externen Informationen zur Kennzeichnung eines Entity sicherstellen.

Der zweite mögliche Fall tritt ein, wenn das XML-Entity durch Kodierungsinformationen ergänzt wird, wie in einigen Filesystemen und Netzwerkprotokollen. Wenn mehrere Informationsquellen verfügbar sind, sollten ihre relative Priorität und die bevorzugte Methode zur Handhabung von Konflikten als Teil des Übertragungsprotokolls, das zum Versenden von XML benutzt wird, spezifiziert werden. Regeln für die relative Priorität der internen Kennzeichnung und zum Beispiel der MIME-Typ-Kennzeichnung in einem externen Protokollkopf sollten Teil des RFC-Dokumentes sein, das die MIME-Typen text/xml und application/xml definiert. Im Interesse der Zusammenarbeit werden aber folgende Regeln empfohlen:

• Falls ein XML-Entity in einer Datei steht, dann werden die Byte-Order-Markierung und die Processing Instruction mit Kodierungsdeklaration verwendet (falls vorhanden), um die Zeichenkodierung zu bestimmen. Alle anderen Heuristiken und Informationsquellen dienen einzig dazu, im Fehlerfall weiterzuarbeiten.
• Falls ein XML-Entity mit dem MIME-Typ text/xml ausgeliefert wird, dann bestimmt der charset-Parameter des MIME-Typs die Zeichenkodierung. Alle anderen Heuristiken und Informationsquellen dienen einzig dazu, im Fehlerfall weiterzuarbeiten.
• Falls ein XML-Entity mit dem MIME-Typ application/xml ausgeliefert wird, dann werden die Byte-Order-Markierung und die Processing Instruction mit Kodierungsdeklaration verwendet (falls vorhanden), um die Zeichenkodierung zu bestimmen. Alle anderen Heuristiken und Informationsquellen dienen einzig zur Fehlerbehebung.

Diese Regeln gelten nur bei Fehlen von Dokumentation der Protokoll-Ebene. Insbesondere sobald die MIME-Typen text/xml und application/xml definiert sind, werden die Empfehlungen des relevanten RFC diese Regeln ersetzen.