✔ generelle Ein und 2 Byte Codierungen in XML

[takidoso]

Hallo und Halli,
Ich habe da mal ne Frage bezüglich der generellen Codierungen in einer XML vor allem bezogen auf UTF-8
Ich habe neulich ein XML-Dokument gesehen, welches genrell 2-Byte codiert war. (Es begann mit Hexadecimal FFFE dann gefolgt von dem eigetnlichen XML)
Was dabei drollig ist, dass das encoding mit UTF8 angegeben war.
Bisher war ich davon ausgegangen, dass UTF8 1 Byte-Code ist, es sei denn man gibt bestimmte Zeichen vor die bezüglich ihrer ersten bits sagen dass es sich um ein Zeichen handelt was mit entsprechend mehr als 1 Byte codiert ist.
Meine Frage: Ist dass trotzdem ein legales XML-Dokument?
Für näheres Verständnis bezogen auf das was ich meine s. Anhang

Vielen Dank für Hinweise

Tankidoso

 

[deepthroat]

Hi.

Hallo und Halli,
Ich habe da mal ne Frage bezüglich der generellen Codierungen in einer XML vor allem bezogen auf UTF-8
Ich habe neulich ein XML-Dokument gesehen, welches genrell 2-Byte codiert war. (Es begann mit Hexadecimal FFFE dann gefolgt von dem eigetnlichen XML)

Das heißt also eigentlich im UTF-16LE Encoding.

Was dabei drollig ist, dass das encoding mit UTF8 angegeben war.
Bisher war ich davon ausgegangen, dass UTF8 1 Byte-Code ist, es sei denn man gibt bestimmte Zeichen vor die bezüglich ihrer ersten bits sagen dass es sich um ein Zeichen handelt was mit entsprechend mehr als 1 Byte codiert ist.
Meine Frage: Ist dass trotzdem ein legales XML-Dokument?

Nein, laut W3C XML Spezifikation ist es ein "fatal error" wenn das angegebene encoding nicht mit dem vorher festgestellten Encoding übereinstimmt.

Gruß

PS: Warum machst du einen Screenshot um ihn dann in ein Word Dokument einzufügen?

 

[takidoso]

Das heißt also eigentlich im UTF-16LE Encoding.

ahh danke, aber gibt es da eine Auflistung irgendwo im Netz bezüglich welche encodings auf welche ersten beiden Bytes passen?

Nein, laut W3C XML Spezifikation ist es ein "fatal error" wenn das angegebene encoding nicht mit dem vorher festgestellten Encoding übereinstimmt.

Kann es sein dass der Sax-Parser Xerces wie er standardmäßig in Java 5 vorkommt (oops vielleicht müsste ich die Frage im Java Forum stellen) diesen Fehler noch nicht auswirft, oder muss ich dazu noch irgendwelche Einstellungen (Properties) vornehmen?

PS: Warum machst du einen Screenshot um ihn dann in ein Word Dokument einzufügen?

ohh sorry aber hier im Büro habe ich leider kein Graphik-Programm gefunden, daher erstmal nur dieses Behilfs Word-Dokument. Ich weiß herzlich umständlich :-(.

 

[deepthroat]

ahh danke, aber gibt es da eine Auflistung irgendwo im Netz bezüglich welche encodings auf welche ersten beiden Bytes passen?

Das steht sogar in der XML Spezifikation: http://www.w3.org/TR/REC-xml/#sec-guessing

Kann es sein dass der Sax-Parser Xerces wie er standardmäßig in Java 5 vorkommt (oops vielleicht müsste ich die Frage im Java Forum stellen) diesen Fehler noch nicht auswirft, oder muss ich dazu noch irgendwelche Einstellungen (Properties) vornehmen?

Das kann natürlich sein. Das mit den Properties weiß ich nicht.

ohh sorry aber hier im Büro habe ich leider kein Graphik-Programm gefunden, daher erstmal nur dieses Behilfs Word-Dokument. Ich weiß herzlich umständlich :-(.

Es gibt kein Paint bei euch?

Gruß

 

[takidoso]

Hi deepthroat,
also irgendwie bin ich noch nicht auf den Hinweis in der XML-Spezifikation gestoßen bezüglich eines Fatal-Errors im Falle, dass ein BOM FFFE steht aber UTF-8 in der Kodiervorschrift hinterlegt ist. Falls Du zufällig noch weißt wo das stand, könntest Du mir den Ausschnitt zeigen? Vielleicht ist dies ja auch der Gund warum Xerces da nicht zu meckern scheint

verstehe ich es eigetnlich richtig das Little-Endian heißt erst low dann high-byte?
(Ich hatte ursprünglich das Gegenteil angenommen nach dem Motto erst High und Low byte am Ende; aber das scheint irgendwie so wie ich es sehe genau andersherum zu sein).

für Hinweise dankbar und eine schöne Adventszeit ...

Takidoso

 

[deepthroat]

Hi.

Hi deepthroat,
also irgendwie bin ich noch nicht auf den Hinweis in der XML-Spezifikation gestoßen bezüglich eines Fatal-Errors im Falle, dass ein BOM FFFE steht aber UTF-8 in der Kodiervorschrift hinterlegt ist. Falls Du zufällig noch weißt wo das stand, könntest Du mir den Ausschnitt zeigen? Vielleicht ist dies ja auch der Gund warum Xerces da nicht zu meckern scheint

Section 4.3.3:

it is a fatal error for an entity including an encoding declaration to be presented to the XML processor in an encoding other than that named in the declaration

Das heißt, wenn dort UTF-8 in der encoding Deklaration steht, das Encoding in Wirklichkeit (mit oder ohne BOM) aber UTF-16LE ist, ist das ein fataler Fehler.

Evtl. geht Xerces davon aus, dass die Encodings so "ähnlich" sind, das es kein Problem ist da immer erfolgreich konveriert werden kann. Vielleicht bekommt der Xerces Parser die Bytes gar nicht zu Gesicht, sondern nur die Unicode Zeichen...

verstehe ich es eigetnlich richtig das Little-Endian heißt erst low dann high-byte?
(Ich hatte ursprünglich das Gegenteil angenommen nach dem Motto erst High und Low byte am Ende; aber das scheint irgendwie so wie ich es sehe genau andersherum zu sein).

Little Endian bedeutet, das das geringwertigste Byte zuerst gespeichert wird.

Gruß

 

[takidoso]

hier des Rätsels Lösung.
Das war echt gemein.... UltraEdit hat je nach Einstellungen die Angewohnheit diesen BOM zu erzeugen. In Wirklichkeit war das File doch nur 1 Byte kodiert.
Für mich als Gedächtnisstütze und für andere mit zufällig ähnlichem Problem hier die Optionsänderungen in UltraEdit
Unter Extras->Optionen->Reiter Allgemein sollten die drei UTF-8-Optionenen deaktiviert werden. Zur Verdeutlichung noch ein Hardcopy

Takidoso