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.