Muss eine "leere" Datei ein BOM enthalten?

[Der schöne Günther]

Dumme Frage wahrscheinlich. Angenommen wir haben ein leere Text-Datei. Ganz leer, null Byte. .NET gibt für System.IO.File.ReadAllText(path, Encoding.Unicode); einen leeren String zurück, Delphi fliegt bei TFile.ReadAllText(filePath, TEncoding.Unicode); mit einer EEncodingError -Exception "Invalid source array" raus.

Technisch ist das wenig verwunderlich, denn die Delphi-Implementation versucht als erstes direkt den zwei Byte langen BOM aus dem Stream zu lesen der null Byte Inhalt hat und scheitert daran.

Meine Frage: Ist das korrekt so? Wenn vereinbart ist "Unicode", dann kann ich die zwei BOM-Bytes auch zwingend erwarten? Wenn sie fehlen ist es keine valide Datei?

[mschaefer]

Zunächst hat man einen Directory Eintrag mit Zeiger auf den Sektor.
Im Sektor muss zumindest ein 0 Byte als Zeilenende Marker sein.
Liest Du Utf ein, öffnest Du als Utf, dann wird Utf Kennung und Zeilenende Marker erwartet.

Denke Du solltest die Exception abfangen.

[himitsu]

Nein, eine leere Textdatei muß nicht zwingend ein BOM haben.
Außer man Speicher einen leeren String mit BOM in einer Datei, dann kann/muß auch natürlich auch nur der BOM in der Datei drin stehen.

Du gibst ein Encoding vor (zweiter Parameter), also darf da nur bei einem "falschen" Encoding der EEncodingError kommen,
denn es wäre doch auch korrekt, wenn die Datei eben ohne BOM erstellt wurde.
Denn es ist das "Default" encoding, welches genommen wird, wenn kein BOM vorhanden ist.
Anders wäre es, wenn dieser Parameter ein "Check" wäre und auf ein bestimmtes Encoding prüft. (für TXT ist in Windows nunmal die aktuelle CodePage das Default, also ANSI)



Mach mal eine Meldung ans QC
und hoffe dieser 7-8 Jahre alte Bug wird dann schnell behoben.

[Der schöne Günther]

Wenn ich es jetzt richtig verstehe dann ist es doch kein Bug.

Gebe ich explizit ein Encoding mit Preamble an dann muss die Datei dieses enthalten, auch wenn der Netto-Inhalt ein leerer String ist.

[p80286]

Eine leere Datei enthält einen Leerstring, der ist zu allen möglichen Kodierungen kompatibel oder aber er ist vollkommen ohne Eigenschaft (null,Nil....)
Wenn man sich den Eintrag in der Wikipedia anschaut, dann ist das BOM ein "nice to get".

Wenn Du Dir z.B. eine Word-.DOC-Datei anschaust, dann ist das ein fröhliches Durcheinander von 16 und 8-Bit Codierungen, natürlich ohne BOM.

Gruß
K-H

[jobo]

Ist das nicht ein bisschen Pseudo Diskussion?
Immerhin haben wir einen Aufruf, wo Unicode explizit angegeben wird.
Wenn es sich um Basisfunktionen handelt, könnte ich mir gut vorstellen, dass es eine TFile Funktion gibt, die das Encoding prüft, sodass man programmatisch anschließend die richtige Open / Load Methode wählen kann.
Ich habe aus alten Zeiten noch so ein Prinzip im Kopf, irgendwas mit "reine Lehre".
Es gibt eine Schicht, die einfach Operationen durchführt, ohne Prüfung, reine Lehre. Die muss natürlich genügend "Werkzeug" liefern, die Methoden auch richtig einzusetzen. Hat z.B. was mit Performance zu tun und Redundanz.
Darüber kann dann eine Komfortschicht liegen.
Und da wäre man dann bei .Net / MS. Die machen für meinen Geschmack immer gern irgendetwas "komfortabel". Leider weiß man nie genau, was, wie warum. Auf API Ebene kenne ich das allerdings kaum aus der Praxis, aber es entspräche deren Programm / OS Logik. Bspw. Notepad, kann nichts, aber das erstaunlich gut, u.a. Dateien unterschiedlichster encodings öffnen.

[Der schöne Günther]

Zitat von jobo:

Bspw. Notepad, kann nichts, aber das erstaunlich gut, u.a. Dateien unterschiedlichster encodings öffnen.

https://en.wikipedia.org/wiki/Bush_hid_the_facts

[jobo]

Haha, das kannte ich nicht!
Zum Glück habe ich nur von "Öffnen" geschrieben.

Im Grunde wird MS mit sowas ja zum Sklaven genau dieser windelweichen "Komfort" Thematik, von der ich oben schrieb. Notepad versucht halt, beim Öffnen ein Encoding zu interpretieren, schlimmer aber, dass es beim Speichern dann dieser eigenen Logik nicht folgt. (Oder halt einfach konsequent mit / ohne BOM oder Speichervarianten arbeiten würde)

Bedeutet zum Thema m.E., "wo ist das Problem?" Streng genommen ist das Verhalten von TFile ok und wenn es anders wäre, würden vielleicht Delphi Programme eines Tages auch in der BHTF Hall of Fame landen.

[Der schöne Günther]

Ich meckere gerne, aber ich sehe es genauso. Das Verhalten der Delphi RTL ist hier im Vergleich zu .NET strenger/pingeliger, aber auch "korrekter".