TStringList ohne BOM speichern?

[fillibuster]

Hallo,

danke für die Antworten. Werde ich dann wohl selbst Hand anlegen. Eine Sache noch in diesem Zusammenhang. In den gespeicherten Dateien ist immer eine (Leer)Zeile mehr drin als eigentlich geschrieben wird. Liegt das auch am BOM?

Viele Grüße ...

[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

[Perlsau]

Zitat von Tonic1024:

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.

[Tonic1024]

Zitat von Perlsau:

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.

[Perlsau]

Zitat von Tonic1024:

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.

Aus Sicht eines Programmierers ist das vollkommen korrekt. Aus Sicht eines reinen Anwenders, insbesondere eines DAUs, der absolut nichts von irgendwelchen Internas weiß, zählt das, was sein Programm anzeigt. Somit hast du recht: es kommt drauf an, wer die Sache deutet.

Zitat von Tonic1024:

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.

Auch das ist korrekt, denn hier betrachtest du die Sache aus der Sicht eines Programmierers.

Zitat von Tonic1024:

Ü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.

Ich kann daran nichts Unlogisches erkennen: Viele Textanzeige-Programme, die ich kenne, zeigen nach dem Zeilenende eine neue Zeile an. Aus Sicht des Programmierers existiert die zwar nicht, aus Sicht des Anwenders aber schon, denn der kann direkt an der neuen Cursorposition Text eingeben. Bei RTF- und Wörd-Dateien ist das anders, aber das betrifft eben nur die Darstellung bzw. die Anwendungslogik.

Somit dürfte nun auch die Frage aus Nummer 9 erschöpfend beantwortet sein

[fillibuster]

Zitat von Perlsau:

...
Somit dürfte nun auch die Frage aus Nummer 9 erschöpfend beantwortet sein

ich denke auch

[Perlsau]

Dennoch würde ich gerne noch einmal auf meine Frage in Post Nummer 7 zurückkommen:

In welchem Format wird gespeichert, wenn ich keinen Encoding-Parameter angebe?

[p80286]

Zitat von Tonic1024:

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