libxml2: Char 0xFFFF out of allowed range

gritsch · 3. Oktober 2014, 19:13

Hallo,

ich erstelle ein xml mit UTF-8 encoding.
dort befindet sich unter anderem auch das "Noncharacter"-zeichen: fileformat.info/info/unicode/char/ffff/index.htm
beim erstellen des xmls gibt es kein problem. Warum auch, 0xEF 0xBF 0xBF ist ja ein gültiges UTF8-zeichen (0xFFFF in UTF16).
beim parsen jedoch wird der obige fehler ausgegeben. aber warum? es ist doch ein gültiges zeichen!?

ich hänge das test-projekt an (sehr kurz).

hier die genaue fehlermeldung vom parser:

Entity: line 2: parser error : Char 0xFFFF out of allowed range
<root test="ae"/>
^
Entity: line 2: parser error : invalid character in attribute value
<root test="ae"/>
^
Entity: line 2: parser error : attributes construct error
<root test="ae"/>
^
Entity: line 2: parser error : Couldn't find end of Start Tag root line 2
<root test="ae"/>
^
Entity: line 2: parser error : Extra content at the end of the document
<root test="ae"/>

macmoonshine · 3. Oktober 2014, 20:36

+doppelpost+

macmoonshine · 3. Oktober 2014, 20:37

+doppelpost+

macmoonshine · 3. Oktober 2014, 20:38

0xFFFF ist kein gültiges UTF-16-Zeichen, da diese Bytefolge für den Überlauf zu UTF-32 gebraucht wird.

16.7 Noncharacters schrieb:

The Unicode Standard sets aside 66 noncharacter code points. The last two code points of each plane are noncharacters: U+FFFE and U+FFFF on the BMP, U+1FFFE and U+1FFFF on Plane 1, and so on, up to U+10FFFE and U+10FFFF on Plane 16, for a total of 34 code points. In addition, there is a contiguous range of another 32 noncharacter code points in the BMP: U+FDD0..U+FDEF. For historical reasons, the range U+FDD0..U+FDEF is contained within the Arabic Presentation Forms-A block, but those noncharacters are not "Arabic noncharacters" or "right-to-left noncharacters," and are not distinguished in any other way from the other noncharacters, except in their code point values.

macmoonshine · 3. Oktober 2014, 20:39

0xFFFF ist kein gültiges UTF-16-Zeichen, da diese Bytefolge für den Überlauf zu UTF-32 gebraucht wird. (siehe 16.7 Noncharacters in unicode.org/versions/Unicode5.2.0/ch16.pdf)

Thallius · 3. Oktober 2014, 20:46

Wohl eher ein 4-Fach Post

Gruss

Claus

gritsch · 3. Oktober 2014, 20:48

ja aber es ist eine gültige UTF-8-sequenz. also warum soll es mir das nicht erlauben?

und falls sie es nicht erlauben wollen, warum ist es dann beim erstellen ok, beim parsen aber nicht?
muss ich etwa anfangen vorher das auszufiltern???

macmoonshine · 3. Oktober 2014, 20:55

Die Einsen am Beginn einer UTF-8-Sequenz bedeuten, dass es sich um ein Mehrbyte-Zeichen handelt, wobei die Anzahl der Bytes ungefähr linear von der Anzahl der Einsen abhängt. Die Folge 0xFFFF würde also eine sehr lange UTF-8-Bytefolge einleiten.

Die Zeichenübersicht zeigt übrigens zu jedem Zeichen auch dessen UTF-8-Bytefolge an. Was ist denn dort für Dein Zeichen angegeben?

macmoonshine · 3. Oktober 2014, 20:56

Thallius schrieb:

Wohl eher ein 4-Fach Post

Ja, ein Doppeldoppelpost.

gritsch · 3. Oktober 2014, 21:09

die frage ist ja ob es eine gültige UTF8-sequenz ist. und das ist es ja - oder irre ich?

das zeichen mach ja auch keinem texteditor probleme.

und wenn es nicht gültig ist, warum gibts dann kein problem mit der gleichen sequenz beim erstellen des XMLs?

macmoonshine · 3. Oktober 2014, 21:24

Auch laut Zeichenübersicht ist 0xFFFF kein gültiges Zeichen (siehe Mauszeiger):

gritsch · 3. Oktober 2014, 21:32

der zeichentabelle ist ja nicht so recht zu trauen (siehe 0xFFFE links daneben ;-))

warum gibts dann aber kein problem beim erstellen des xmls?
und auch die ganzen string-klassen von apple haben kein problem mit der sequenz also wo sollte man ansetzen das zu verhindern?
vor dem parsen den ganzen text nach UTF-16 konvertieren und alle 0xFFFE und 0XFFFF durch 0x20 ersetzen und dann das parsen (der parser darfs dann wieder zurückkonvertieren).

zerm · 4. Oktober 2014, 12:49

gritsch schrieb:

ja aber es ist eine gültige UTF-8-sequenz. also warum soll es mir das nicht erlauben?

Soweit mir bekannt, darf 0xFF niemals in einem UTF-8 stream irgendwo auftauchen?!

Wenn Du keine super-tollen Features von libxml2 brauchst, kann ich tinyxml empfehlen, der ist denk ich auch ein wenig vezeihlicher.

mattik · 4. Oktober 2014, 13:54

Ich finde, dass das Verhalten ganz normal und richtig ist. 0xFFFF ist ein valider Codepoint in Unicode. Er darf in Strings vorkommen und ist in UTF8 auch korrekt mit 0xEF 0xBF 0xBF codiert. Aber er ist in XML 1.0 und XML 1.1 verboten. Also verstehe ich gut, dass der XML-Parser meckert.

Dass der Encoder das anstandslos macht, ist zwar etwas eigenartig, finde ich aber nachvollziehbar. So kann man den Codepoint für Private Use verwenden - ganz so, wie er gedacht ist. Dann muss man ihn halt vor dem erneuten Parsen seinem Private Use zuführen. Ist nicht ganz konsistent, aber wer diese Codepoints verwendet, sollte eh ganz genau wissen, was er da tut - besonders nach dem Bedeutungswirrwarr in den verschiedenen Unicode-Versionen.

zerm · 4. Oktober 2014, 16:44

mattik schrieb:

0xFFFF ist ein valider Codepoint in Unicode

D'uh, ja, Codepoint. Ich dachte Bytes, aber hatte Gritsch ja schon im Eingangspost geklärt

Ich brauch Wochenende, glaub ich...

kmr · 4. Oktober 2014, 19:46

macmoonshine schrieb:

Ja, ein Doppeldoppelpost.

Es gibt ja auch nichts besseres als einen doppelten Espresso. Und davon zwei.

gritsch · 5. Oktober 2014, 13:36

0xFDD0 ist hingegen kein problem für libxml obwohl auch ein non-character...
was soll der inkonsistente mist? (beim erstellen kein problem, beim parsen einige ein problem ondere jedoch nicht...)

fileformat.info/info/unicode/char/FDD0/index.htm

mattik · 5. Oktober 2014, 13:44

gritsch schrieb:

0xFDD0 ist hingegen kein problem für libxml obwohl auch ein non-character...

Ist exakt nach der Spezifikation - wie viel Sinn das ergibt ist sicherlich ein anderes Thema...

gritsch · 5. Oktober 2014, 13:48

mattik schrieb:

gritsch schrieb:

0xFDD0 ist hingegen kein problem für libxml obwohl auch ein non-character...

Ist exakt nach der Spezifikation - wie viel Sinn das ergibt ist sicherlich ein anderes Thema...

<ironie>das macht natürlich sehr viel sinn</ironie>

Ähnliche Themen