Encoding/Unicode/Zeichensätze

[EConvertError]

Zitat:

Soweit ich weiss, ist es nicht verpflichtend. Manche Parser wuerden es dann auch garnicht mehr verstehen.

Das heißt, wenn man XML-Dateien richtig einlesen will, müsste man bis zum Encoding-Attribut ANSI lesen und ab dort dann z.B. Unicode (oder was auch immer dort angegeben ist)?

Bei vorhandensein eines BOM könnte ich gleich so wie dadurch angegeben lesen? Weißt du das mit Gewissheit, dass es nicht vorgeschrieben ist?

Zitat:

Schau dir die Datei mal in einem Hexeditor an, dann weisst du es mit Sicherheit.

Werde ich gleich tun.

Der Hintergrund ist nämlich, dass ich verschiede Sourcefiles einlesen möchte und da ist eben auch XML dabei. Und das möchte ich -nach Möglichkeit- richtig machen.

Vielen Dank,
Andreas

[xaromz]

Hallo,

Zitat von EConvertError:

Das heißt, wenn man XML-Dateien richtig einlesen will, müsste man bis zum Encoding-Attribut ANSI lesen und ab dort dann z.B. Unicode (oder was auch immer dort angegeben ist)?

Stimmt. Wobei IMHO XML-Dateien ohne Encoding-Attribut implizit UTF8-codiert sind.

Gruß
xaromz

[Olli]

Zitat von EConvertError:

Das heißt, wenn man XML-Dateien richtig einlesen will, müsste man bis zum Encoding-Attribut ANSI lesen und ab dort dann z.B. Unicode (oder was auch immer dort angegeben ist)?

Genau.

Zitat von EConvertError:

Bei vorhandensein eines BOM könnte ich gleich so wie dadurch angegeben lesen? Weißt du das mit Gewissheit, dass es nicht vorgeschrieben ist?

Sagen wir mal so, es kommt auf die Quelle der Datei an. Ein Server wuerde den Zeichensatz bspw. im Protokollheader angeben und du muesstest trotzdem noch die Angabe in der Datei beachten. Auf Platte habe ich noch keine XML-Datei gesehen, die einen solchen Marker hatte und auch Unicode war.

[EConvertError]

Dankeschön!

Das finde ich allerdings etwas unbequem.

Zitat:

Auf Platte habe ich noch keine XML-Datei gesehen, die einen solchen Marker hatte und auch Unicode war.

Meine genannte Datei stammt vom .NET-Framework (Konfigurationsdatei) und IMHO schreibt auch VS 2005 ein BOM. Fix ist auch, dass im Encoding-Attribut UTF-8 angegeben ist.

Zitat:

Wobei IMHO XML-Dateien ohne Encoding-Attribut implizit UTF8-codiert sind.

Wikipedia: Wird dieser Parameter [= das Encoding-Attribut] ausgelassen, wird UTF-8 angenommen.

Das heißt praktisch, dass ich, um XML und HTML (das sich ja ähnlich verhält) korrekt zu lesen einen XML/HTML-Parser brauche, da ich, zumindest wenn ich kein BOM finde, das Encoding-Attribut lesen muss.
Und fix ist auch, dass ich die XML-Deklaration mit ANSI lesen MUSS, um alles weitere korrekt weiterlesen zu können.

Wird wohl etwas mehr Arbeit für mich...

Vielen Dank,
Andreas

[himitsu]

Och, rein theoretisch könnte man XML/RTF-Dateien auch mal nicht als Ansi abspeichern (zum Glück macht keiner sowas) ... dann wäre das mit dem Auslesen recht nett
(erst über's BOM die "Grundcodierung" erkennen und dann darin anhand des Encoding-Attributes)


[add]
also ich meine den Dateiinhalt und nicht den Feld-/Textinhaltinnerhalb der RTF/XML-Struktur.

XML/RTF sind ja im Grunde Textdateien, worin über eine "spezielle" Struktur der eigentliche Text/Feldinhalt verwaltet wird.



reine Textdateien kann man wohl "nur" anhand des BOM unterscheiden.

XML/RTF wird anscheinend als Ansi geseichert und der Inhalt dann entsprechende dem Encoding-Attribut.

und bei den komplexeren Dateien (z.B. DOC, WKS, PDF, ODT...) isses dann über die entsprechenden Dateispezifikationen geregelt.

[EConvertError]

Hallo!

Zitat:

erst über's BOM die "Grundcodierung" erkennen und dann darin anhand des Encoding-Attributes

Genau das möchte ich tun. Dann muss ich eben meinen kleinen XML-Parser unicode-fähig machen.

Jetzt schaue ich mal nach, ob ein BOM existiert (das habe ich bereits implementiert). Wenn nicht, lese ich im im "ANSI-Modus". Wenn das Encoding-Attribut ausgelesen ist, passe ich das Encoding gegebenenfalls an.

Für mich stellt sich nun die Frage: Angenommen, ich im Encoding-Attribut steht UTF-8 und ich habe bisher im "ANSI-Modus" gelesen. Muss ich dann z.B. UTF-8 anders behandeln als wenn es bereits so im BOM angegeben wäre?

Oder kann ich dann ganz normal so weiterlesen:

Delphi-Quellcode:

SetLength(MyAnsiString, DasWasHaltNochZuLesenIst div SizeOf(AnsiChar));
      Stream.Read(PAnsiChar(MyAnsiString)^, DasWasHaltNochZuLesenIst );
      MeinEndgültigerWideString := UTF8Decode(MyAnsiString);

Selbiges natürlich bei den anderen Unicodes...

Und rein angenommen, im Encoding-Attribut ist z.B. so etwas krankes (im Sinne von selten ) wie IBM855 angegeben: Kann ich das als ANSI einlesen, oder müsste ich das theoretisch extra encoden? Ich habe nämlich nicht wirklich Lust, hunderte Encoder zu schreiben.

In diesem Fall würde ich nur die wichtigsten Fälle, wie UTF-8 und UTF-16 und AnsiString beachten (und natürlich OOP-mäßig ausbaubar machen, falls ich einmal in ferner Zukunft ein besonders seltsames XML-Dokument bekomme).


Vielen Dank,
Andreas

[marabu]

Hallo Andreas,

vielleicht machst du dir zu viele Gedanken. Die Väter von XML haben es so eingerichtet, dass jeder Parser anhand der ersten Zeichen eines Dokuments schnell erkennen kann welches encoding vorliegt. Zuerst wird das Byte-Order-Mark geprüft. Bei Abwesenheit werden die für UTF-16 typischen zero values gesucht. Fehlen diese, dann liegt kein double-byte encoding vor. Jetzt kann es sich nur noch um UTF-8 (multi-byte) oder ein single-byte encoding aus der CodePage-Ära handeln. Durch die genaue Festlegung des Aufbaus der XML-Declaration im Standard ist sichergestellt, dass man problemlos das "encoding Attribut" auswerten kann. Für XML-Dokumente ist die encoding Angabe verpflichtend, wenn es sich nicht um UTF-8 oder UTF-16 handelt. Parser sind aber nicht verpflichtet andere encodings als UTF-8 und UTF-16 zu verstehen. Alleine über diese beiden ist die Interoperabilität sicher gestellt.

Freundliche Grüße

[EConvertError]

Vielen Dank!

Somit betrachte ich meine Frage als geklärt.

Dankeschön,
Andreas

[Muetze1]

UTF-32 ist trotzdem auch noch möglich - selten, aber möglich. Daher kann man bei fehlenden Zero-High-Bytes von 8 Byte CharSize ausgehen. Man kann es aber wissentlich ignorieren bzw. bei den entsprechenden Informationen darauf hinweisen.

[marabu]

Hallo Thomas,

einigen wir uns mal darauf, dass es UTF-32 gibt, aber der aktuelle Standard XML 1.1 es noch aus guten Gründen ignoriert. Kein W3C-konformer XML-Parser muss UTF-32 verarbeiten können.

Freundliche Grüße