TStringList ohne BOM speichern?

[DeddyH]

Das hatte Uwe aber bereits erwähnt ;)

[Uwe Raabe]

Zitat:

Zitat von MaBuSE (Beitrag 1241725)

TStrings hat eine Eigenschaft WriteBOM.

Nicht in D2010!

[Tonic1024]

Zitat:

In den gespeicherten Dateien ist immer eine (Leer)Zeile mehr drin als eigentlich geschrieben wird.

Nein, das ist völlig normales Verhalten. Am Ende einer jeden Zeile der Liste ist automatisch ein Zeilenumbruch. Nur in den Köpfen der Programmierer macht es Sinn nach der letzten Zeile keinen Zeilenumbruch haben zu wollen. Bin selbst mal drauf herein gefallen.

Entweder man hat nach jeder Zeile, auch der Letzten, automatisch ein #13#10 oder man kümmert sich von Anfang an selbst drum. Macht durchaus Sinn - falls du das gemeint hast.

Gruß,

Toni

[MaBuSE]

Zitat:

Zitat von DeddyH (Beitrag 1241726)

Das hatte Uwe aber bereits erwähnt ;)

Danke das hatte ich dann auch gesehen.
Man sollte vor dem Posten noch mal einen Refresh machen :oops:

[Sir Rufo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1241727)

Zitat:

Zitat von MaBuSE (Beitrag 1241725)

TStrings hat eine Eigenschaft WriteBOM.

Nicht in D2010!

Jenau

TStrings (D2010 Doku)
TStrings (XE Doku)

[Perlsau]

Zitat:

Zitat von Tonic1024 (Beitrag 1241728)

Nein, das ist völlig normales Verhalten. Am Ende einer jeden Zeile der Liste ist automatisch ein Zeilenumbruch. Nur in den Köpfen der Programmierer macht es Sinn nach der letzten Zeile keinen Zeilenumbruch haben zu wollen. Bin selbst mal drauf herein gefallen.

Diese "letzte Zeile" wird beim Öffnen via Liste.LoadFromFile jedoch nicht mit eingelesen, wie ich eben ermittelt habe: In meiner Testdatei befinden sich laut PsPad 23.971 Zeilen incl. der letzten, leeren Zeile, die ja nur aus 0D0A (#13+#10) besteht. Beim Einlesen derselben Datei via Liste.LoadFromFile erhalte ich jedoch nur 23.970 Zeilen.

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1241717)

1. Update auf XE oder höher
2. Delphi-Quellcode:

   sl.WriteBOM := false;

Danke für die Info. Dann braucht man hier nix mehr selbst machen (bzw. bei Update auf neue Version evtl. Altcode entsorgen).

[himitsu]

Zitat:

Zitat von Furtbichler (Beitrag 1241709)

Wer sollte das dann wieder einlesen können? Der BOM für UTF-8 hat schon seinen Sinn. Was stört dich daran?

Es kommt drauf an.
Bestimmte Dateiformate haben eine andere Standardformatierung, wenn kein BOM vorhanden ist.
z.B. XML ist standardmäßig UTF-8

Und auch bei HTML muß die Kodierung nicht als BOM drinstehen, sondern wird über Meta-Tags definiert.


PS: Im Notfall hätte man sich auch ganz einfach ein eigenes TEncoding definieren können, welches kein BOM enthält.

Delphi-Quellcode:

TMBCSEncoding.Create(CP_UTF8)

[p80286]

Zitat:

Zitat von Tonic1024 (Beitrag 1241728)

Entweder man hat nach jeder Zeile, auch der Letzten, automatisch ein #13#10 oder man kümmert sich von Anfang an selbst drum. Macht durchaus Sinn - falls du das gemeint hast.

Das ist durch die Historie bedingt. "CarriageReturn, Linefeed" war für viele Drucker und Monitore die Ansteuerung für eine neue Zeile. Jetzt kommt es darauf an was Du willst, eine neue Zeile nach Deinem Text oder aber nicht, dementsprechend ein x0D0A oder nicht.
Es gibt/gab ja auch Programme die eine Textdatei mit einem x0D0A121A beendet haben.

Alles eine Frage der Konvention.

Gruß
K-H

[Tonic1024]

Zitat:

Zitat von Perlsau (Beitrag 1241733)

Diese "letzte Zeile" wird beim Öffnen via Liste.LoadFromFile jedoch nicht mit eingelesen, wie ich eben ermittelt habe: In meiner Testdatei befinden sich laut PsPad 23.971 Zeilen incl. der letzten, leeren Zeile, die ja nur aus 0D0A (#13+#10) besteht. Beim Einlesen derselben Datei via Liste.LoadFromFile erhalte ich jedoch nur 23.970 Zeilen.

Ist letztlich Auslegungssache. In meinen Augen ist #13#10 nicht eine neue Zeile, sondern es steht am Ende der letzten, mit text gefüllten Zeile. So wie in jeder Zeile vorher.

Der Cursor blinkt nach einem LineFeed allerdings korrekter Weise am Anfang einer (noch) nicht existenten zusätzlichen Zeile. Der XY-Positionsanzeiger des Cursors zeigt dann folgerichtig natürlich eine Zeile mehr an. Diese wird dann natürlich aber nicht mit gespeichert, weil das ja ein zusätzliches #13#10 (im Stream also ein #13#10#13#10) zur Folge hätte. Mehrfaches Laden und Speichern würde jetzt je eine Zeile mehr erzeugen und die Datei würde wachsen, wachsen, wachsen.

Über die Darstellung kann man sich jetzt natürlich streiten. Technisch betrachtet ist es in meinen Augen aber korrekt wie es ist. Nur im Kopf ist es auf den ersten Blick irgendwie unlogisch.