Encoding/Unicode/Zeichensätze

[EConvertError]

Hallo!

Diesmal will ich Textdateien lesen und deren Zeichensätze berücksichtigen. Bisher habe ich bereits herausgefunden, wie ich mit UTF-8 und UTF-16 umgehe:

• UTF-8: UTF8Decode konvertiert mir das bequem in einen WideString.
• UTF-16 ist hier schön beschrieben.

Meine Fragen sind jetzt:

• Wird da Low/Big Endian auch berücksichtigt? Diesbezüglich kenne ich mich nämlich nicht aus (Um ehrlich zu sein, weiß ich nicht einmal was das ist)...
• Kann es sein, dass eine Datei in UTF-16 gespeichert ist, dies aber nicht mit einem BOM anzeigt (Natürlich angenommen, dass regelkonform verfahren wird.)? Zum Beispiel bei XML, wo das nur in encoding ="UTF-16" angegeben ist?
• Für mich sind zwar UTF-8 und UTF-16 die wichtigsten Zeichensätze, aber wenn ich dennoch einmal "normale" Zeichensätze mit Unterstützung für Umlaute einlesen will? Wird das funktionieren, oder muss ich das extra berücksichtigen, indem ich AnsiString oder String anstatt von WideString verwende?

Vielen Dank,
Andreas

PS: Ich verwende für alle Dateizugriffsfunktionen TFileStreams und nichts anderes Abartiges. :mrgreen:

[EConvertError]

Hallo nochmal!

Eine weitere Sache, die mir in diesem Zusammenhang unklar ist, ist wie (und ob) ich auch andere Zeichensätze (nicht Unicode) erkennen kann. Bei XML ist es ja durch das Encoding-Attribut klar, aber mir geht es ja ganz allgemein um Textdateien. Mir scheint so (nicht getestet), dass es z.B. der StreamReader aus .NET durch die CurrentEncoding-Eigenschaft unterstützt.

Und wie kann ich mit UTF-32 verfahren?

Vielen Dank,
Andreas

[himitsu]

100%-ig sicher kann man garnichts in diesem Zusammenhang prüfen.

Aber es ist oftmals so, daß am Anfang der Textdatei 1-4 Bytes zur Identifizierung stehen.

Diese müssen aber auch beim Speichern von dem Programm eingefügt werden.
Viele Editioren machen das zum Glück, aber wenn du selber mal 'ne Datei speicherst, dann mußt du dich daum kümmern, da dieses nicht autoatisch geschieht.

Hier im Forum findest du einiges zu diesem Thema
und in der CodeLib gibt's auch schon etwas.

Dateiformat einer ( Unicode ) Textdatei ermitteln

[EConvertError]

Vielen Dank!

Zitat:

100%-ig sicher kann man garnichts in diesem Zusammenhang prüfen.

Klingt irgendwie beunruhigend. :gruebel:

Zitat:

Viele Editioren machen das zum Glück, aber wenn du selber mal 'ne Datei speicherst, dann mußt du dich daum kümmern, da dieses nicht autoatisch geschieht.

Deshalb meine Frage, denn gleich nach dem Einlesen steht Speichern auf meiner Liste. :mrgreen:

Ja bisher kann ich, wie oben bereits beschrieben UTF-16 und UTF-8, handhaben:
Ich checke das BOM und lese entweder UTF-8 (UTF8Decode) oder mit diesem ByteSwap Daten ein. Wenn ich kein BOM finde, lese ich einen AnsiString ein.

Die Frage ist, ob ich so bereits alles (oder zumindest das Wichtigste) abdecke, oder da noch mehr Arbeit gefragt ist. Wenn das der Fall ist, würde mich interessieren, wie ich das noch ausbauen kann, denn zu den anderen Unicodes/Encodings konnte ich nicht viel finden.

EDIT: Deinen Link kannte ich schon, aber ich müsste das auch noch einlesen und das bereitet mir Kopfzerbrechen.


Wahrscheinlich kann ich morgen auch schon etwas Code rausrücken (Heute, am Abend vor einer Mathematik-Schularbeit, ist das ein Ding der Unmöglichkeit :mrgreen: ).

Vielen Dank,
Andreas

[EConvertError]

Hallo!

Die Frage hat sich erledigt, da ich einige Beispiecodes gefunden habe, die Unicode abdecken. In der JCL, zum Beispiel findet sich eine TWideStringList, deren LoadFromStream-Methode sehr interessant ist.

Anscheinend genügt es wirklich auf UTF-8 und UTF-16 (hierbei wird noch zwischen Unicode LSB und Unicode MSB unterschieden) zu prüfen und im Notfall einen AnsiString einzulesen.

Liege ich in der Annahme richtig, dass ich hiermit alle wichtigen Fälle behandeln kann und alle anderen Unicodes nicht so wichtig sind unnd bei Bedarf leicht nachgerüstet werden können?

Vielen Dank,
Andreas

[himitsu]

Mit den beiden Unicodes, UTF8 und Ansi(OEM/ASCII...) ist wohl weitesgehend alles abgedeckt ... jedenfalls was "reine" Textdateien angeht.

Im Prinzip wird Ansi und UTF8 am Heufigsten verwendet und solange eine entspechende Signatur am Dateianfang steht, kannst du auch noch andere Formate leicht nachrüsten.

[EConvertError]

Hallo!

Zitat:

jedenfalls was "reine" Textdateien angeht.

:shock: Verhalten sich z.B. XML/HTML Dateien da anders?

Ich wollte diese Klassen, die ich da gerade Schreibe, als Basis für alles, was mit Textdateien zu tun hat, benutzen. Muss ich das Dateiformat auch noch extra beachten?

Vielen Dank,
Andreas

[Olli]

Zitat:

Zitat von EConvertError

:shock: Verhalten sich z.B. XML/HTML Dateien da anders?

Ich wollte diese Klassen, die ich da gerade Schreibe, als Basis für alles, was mit Textdateien zu tun hat, benutzen. Muss ich das Dateiformat auch noch extra beachten?

Ja und ja. Aber in XML-Dateien sollte ja der Zeichensatz ohnehin spezifiziert sein :zwinker:

[EConvertError]

Hmmmm, dankeschön!

Jetzt wird es kompliziert... :gruebel:

Mir ist schon klar, dass es in XML das Encoding-Attribut gibt, aber ich habe gehofft, dass auch am Beginn von XML ein BOM steht. Dann könnte ich das XML-Dokument auch immer korrekt einlesen. Vielleicht würde es nicht immer mit der im Attribut angegebenen Kodierung übereinstimmen, aber es geht ja nur um die richtige Darstellung.

Würde das funktionieren, oder bin ich da völlig auf dem Holzweg?

Einige Textdateien haben am Anfang - wenn sie mit iso-8859-1 angesehen werden - folgende Zeichen: 
Das müsste das doch das BOM sein, oder nicht?

Vielen Dank,
Andreas

[Olli]

Zitat:

Zitat von EConvertError

Mir ist schon klar, dass es in XML das Encoding-Attribut gibt, aber ich habe gehofft, dass auch am Beginn von XML ein BOM steht.

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

Zitat:

Zitat von EConvertError

Einige Textdateien haben am Anfang - wenn sie mit iso-8859-1 angesehen werden - folgende Zeichen: 
Das müsste das doch das BOM sein, oder nicht?

Sieht fuer mich danach aus. Schau dir die Datei mal in einem Hexeditor an, dann weisst du es mit Sicherheit.

[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:

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:

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:

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 :roll:
(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. :mrgreen:

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 :mrgreen: ) 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. :wink:

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

[EConvertError]

Naja, UTF-32 möchte ich sowieso nicht beachten. Sonst wird das ganze zu umfangreich...

Danke euch allen,
Andreas