Einlesen von KAPUTTER Unicode-Datei

[Redeemer]

Zitat von Codehunter:

Jepp, so seh ich das auch. Wenn ich die Datei mit Notepad++ öffne, dann werden eben jene defekten Zeichen als ein Platzhalter-Rechteck angezeigt.

Das kann aber nicht sein. Bei UTF-16 besteht jedes Zeichen aus 2 oder 4 Bytes, deine ANSI-Fehlersequenz (sie bedeutet das Platzhalterzeichen �) hat aber 3 Bytes, sprich der Editor würde danach falsche Bytes zu einem Zeichen zusammenfassen.

[freimatz]

Zitat von hoika:

hm, so viele verschiedene (deutsche) Sonderzeichen gibt es doch eigentlich gar nicht.

Es geht sicher nicht nur um deutsche Sonderzeichen. Da gibt es tausende.

[Uwe Raabe]

Ich bin mir gar nicht mehr sicher, ob es sich wirklich um eine UTF-16 codierte Datei handelt. Im TStreamReader.Create wird zwar ein TEncoding.Unicode übergeben, aber für das DetectBOM wiederum ein True. Damit wird das Unicode-Encoding lediglich zum Fallback, wenn kein BOM gefunden wird.

[stifflersmom]

Zitat von hoika:

Kannst du die kaputten Zeichen nicht einfach ersetzen?

Wenn alle falschen Zeichen mit der zeichenfolge

Zitat:

�

ersetzt wurden, macht das nicht viel Sinn.

[hoika]

Hallo,

Zitat:

Bein Einlesen einer Datei erhalte ich die Exception

Es steht nicht, einer beliebigen Datei ...

[Codehunter]

Das Problem ist, ich weiß ja nicht welche Zeichen kaputt sind. Bei dieser Datei schon, aber es könnte auch eine beliebig andere kaputte Datei geladen werden. Dort liegen wieder andere Kodierfehler vor. Also einfach Suchen und Ersetzen ist nicht.

Aber wenn ich so in die Quellen von TEncoding schaue dann wird für solche Zeichen tatsächlich nichts anderes gemacht als ein RAISE und fertig. Um das zu ändern müsste ich wohl ein komplett eigenes TEncoding schreiben, weil die Methode TEncoding.GetString (wo das RAISE passiert) nicht virtuell ist. Ich glaub da stehen Aufwand und Nutzen in keinem Verhältnis.

EDIT:

Zitat von Uwe Raabe:

Ich bin mir gar nicht mehr sicher, ob es sich wirklich um eine UTF-16 codierte Datei handelt. Im TStreamReader.Create wird zwar ein TEncoding.Unicode übergeben, aber für das DetectBOM wiederum ein True. Damit wird das Unicode-Encoding lediglich zum Fallback, wenn kein BOM gefunden wird.

Genau so ist das auch beabsichtigt. Ich wollte damit erreichen, dass die Preamble (BOM ist ja eigentlich nur ein Teil dessen) ausgewertet wird. Erst wenn das komplett vor die Wand geht, gebe ich Unicode fest vor. Bei der besagten Datei kann aber auch Notepad++ die kaputten Zeichen nicht retten, egal wie man an der Kodierung dreht. Insofern betrachte ich die Preamble als korrekt und den Inhalt als defekt. Die Datei kommt mit einer Unicode-Preamble. Aber auch anders herum, wenn ich hardcoded UTF8 als Reader-Encoding vorgebe und die Preamble ignoriere, laufe ich in genau die selbe Exception.

[Uwe Raabe]

Zitat von Codehunter:

Die Datei kommt mit einer Unicode-Preamble.

Dann dürfte das GetString aber eigentlich nicht krachen, denn GetCharCount liefert bei TUnicodeEncoding lediglich ByteCount div SizeOf(Char) und GetChars macht ein simples Move.

Was sagt denn der Debugger dazu?

[Redeemer]

Dieser Thread hat keinen Sinn mehr ohne dass du hier einen Screenshot aus einem Hex-Editor (HxD z.B., guck mal auf delphipraxis.net) postest. Da reichen auch die ersten zehn Bytes. Damit ist der Thread sofort, eindeutig und vollumfassend erledigt. Ich bin mir, wie ich bereits im ersten Post geschrieben habe, ziemlich sicher, dass das Problem vor dem PC sitzt und nicht weiß, was für ein Encoding die Datei hat. Eine Datei kann wie erwähnt technisch gesehen unmöglich gleichzeitig eine dreiteilige ANSI-Sequenz und UTF-16-Codepoints enthalten, ohne dass ziemlich genau die Hälfte der Datei aus überwiegend CJK-Zeichen bestände.

Zitat von Codehunter:

tatsächlich ALLE Sonderzeichen geschrottet

Wenn keine Sonderzeichen außer der UTF-8-Sequenz drin sind, sehe ich kein Problem damit, diese eine Sequenz einmalig zu ersetzen.

[freimatz]

Was meinst du mit "dreiteilige ANSI-Sequenz"? Und was meint ihr mit "Sonderzeichen"? Der Begriff kommt wenn ich danach Google bei Unicode nicht vor. Auch bei den Kategorien nicht (https://www.compart.com/de/unicode/category).

[p80286]

Ich würde es etwas anders formulieren, aber Redeemer hat recht. Ohne einen Hexdump ist das alles nur Spökenkiekerei. Jede Datei enthält binäre Daten. Wenn Ihre Anzeige einen sinnvollen Text ergibt, dann stimmt die Interpretation (zufällig?).

Gruß
K-H