Zeilenumbruch ersetzen Algorithmus

[KodeZwerg]

Noch eine Idee, aber ich weiß nicht ob alle Delphi Versionen das mitmachen,
deine Text-Datei einfach per ReadLn() einlesen, da ist automatisch schluss, egal wie die zeichenfolge ist.
also im BeginUpdate modus per schleife alles in deine memobox laden, dann passts.
Bei bedarf memo-box inhalt zurück auf platte schreiben, dann ist format einheitlich egal wie's vorher war.

[Delphi.Narium]

@Uwe Raabe

Es geht mir nicht um einen allumfassenden, immer und überall, jederzeit in allen Umgebungen und mit allen Delphiversionen funktionierenden Code, sondern um einen Vorschlag zur Problemlösung.

Selbstdenken und anpassen ist also durch erlaubt, erwünscht und im Rahmen des Möglichen.

Wenn Char nicht ein Byte ist, dann muss man das halt anpassen.

Statt der 1 könnte man halt eben auch SizeOf(ch1) nehmen oder SizeOf(EbenDerTypDenManBenutzt).

[KodeZwerg]

Ich finde es dennoch ineffektiv eine neue und vor allem byte-weise arbeitende Prozedur anzuwenden.
Wenn doch alles bereits bestens funktioniert nur halt die Ausgabe rumzickt dann arbeite ich am Parser und geh nicht im Vorfeld die genannten 700MB komplett (oder chunk-weise) durch um bytes zu ersetzen/entfernen was ja dann eh wieder an Parser geschickt wird der ja namentlich sowas regeln sollte, oder?

[hansklok]

Zitat von KodeZwerg:

Noch eine Idee, aber ich weiß nicht ob alle Delphi Versionen das mitmachen,
deine Text-Datei einfach per ReadLn() einlesen, da ist automatisch schluss, egal wie die zeichenfolge ist.
also im BeginUpdate modus per schleife alles in deine memobox laden, dann passts.

Das hatte ich versucht, ist aber viel langsamer, als alles in einem Wisch als String einzulesen und dann in ein Array zu splitten. Das funktioniert eben nur korrekt, wenn man eine mit „0A“ kodierten Zeilenumbrüchen Datei vorliegen hat.

Zitat von KodeZwerg:

Ich finde es dennoch ineffektiv eine neue und vor allem byte-weise arbeitende Prozedur anzuwenden.
Wenn doch alles bereits bestens funktioniert nur halt die Ausgabe rumzickt dann arbeite ich am Parser und geh nicht im Vorfeld die genannten 700MB komplett (oder chunk-weise) durch um bytes zu ersetzen/entfernen was ja dann eh wieder an Parser geschickt wird der ja namentlich sowas regeln sollte, oder?

Nochmal zur Aufklärung, die Parserklasse erwartet nur einen einzeiligen String, der dann mittels Regulärem Ausdruck in Einzelteile gesplittet wird. Heißt, den Parser interessiert ein Zeilenumbrüchen nicht. Er erwartet einen bereits korrekt gesplitteten String. Deswegen muss ich ja zwei Durchläufe machen. Einen zum splitten der Zeilen der Datei in ein Array und einen, der das Array Zeilenweise parst.
Mir fällt keine andere Taktik ein, als eine Art Präprozessor, der erst alle Zeilenumbrüche auf „0A“ vereinheitlicht, dann im zweiten Durchlauf alle Zeilen mit „0A“ am Ende in ein Zeilen-Array splittet und dann jede Zeile parst.

[KodeZwerg]

Danke für Aufklärung, nun sieht die Lage für mich anders aus und byte-check ist absolut Ok.
Mein Ablauf wäre wie folgt:
Datei puffern,
Byte-Check starten,
innerhalb des checks gleich einen fertigen String anfertigen anstelle einen neuen Stream zu erschaffen,
(das erspart dir ein erneutes Suchen nach $0A, in theorie könntest Du sogar den check einzeln auf $0A und $0D beschränken,
also bei jedem 0A oder 0D den String als fertig betrachten und eher auf die Länge des produzierten Strings reagieren um Leerzeilen zu vermeiden, nachteil: bewusste Leerzeilen fehlen dann)
fertige Zeile eventuell mit TStringList verwalten (virtuell puffern) oder gleich an Bestimmungsort senden,
Parser weglassen da bereits alles fertig ist.

Ps: Im Nachhinein, als ich Nachricht bereits abgeschickt hatte, fiel mir auch ein, ReadLn() ist ja LowLevel langsame Routine, sorry dafür!

[himitsu]

Zitat von KodeZwerg:

Noch eine Idee, aber ich weiß nicht ob alle Delphi Versionen das mitmachen,
deine Text-Datei einfach per ReadLn() einlesen, da ist automatisch schluss, egal wie die zeichenfolge ist.
also im BeginUpdate modus per schleife alles in deine memobox laden, dann passts.
Bei bedarf memo-box inhalt zurück auf platte schreiben, dann ist format einheitlich egal wie's vorher war.

Ihhh.

TStringList: Lesen tut die Alles (LoadFromXyz und .Text) und geschreiben wird, was in TStringList.LineBreak steht.
Aber TMemo ersetzt auch alles, gleich beim Zuweisen an .Text

PS: AdjustLineBreaks
Und das sucht übrigens auch doppelt und bytweise.
* einmal um die Länge des Ergebnisses zu berechnen
* und dann nochmal inkl. Umkopieren
Denn das Suchen und nur eine Speicherreservierung ist wesentlich schneller, als mehrere Reservierungen+umkopieren während der Suche.

Ach ja, ich hatte mir mal eine Ersetzenklasse geschrieben, welche die Operationen sammelt, in einem statischen Array und dann zusammen ausführt, wenn der Puffer voll oder die Arbeit beendet ist.
Muß man auch nur einmal suchen, aber bearbeitet nicht jeden Schritt einzeln.

[hansklok]

Danke für das zahlreiche Feedback.

Zitat von KodeZwerg:

Datei puffern

Was meinst Du mit puffern?

Zitat von KodeZwerg:

Byte-Check starten, innerhalb des checks gleich einen fertigen String anfertigen anstelle einen neuen Stream zu erschaffen, (das erspart dir ein erneutes Suchen nach $0A, in theorie könntest Du sogar den check einzeln auf $0A und $0D beschränken, also bei jedem 0A oder 0D den String als fertig betrachten und eher auf die Länge des produzierten Strings reagieren um Leerzeilen zu vermeiden, nachteil: bewusste Leerzeilen fehlen dann) fertige Zeile eventuell mit TStringList verwalten (virtuell puffern) oder gleich an Bestimmungsort senden, Parser weglassen da bereits alles fertig ist.

Oje, jetzt wird’s kompliziert für mich, wie meinst Du das? Leerzeichen gibt es in den Dateien nicht.

[KodeZwerg]

Nun ist mir wieder eingefallen in welchen Zusammenhang ich ReadLn() verwendete so das es auch noch relativ flott war.

hier ein mini beispiel:

Delphi-Quellcode:

begin
 test := TStreamReader.Create('C:\Test\Temp\Delphi\DP\Testing\Textfile.txt'); // hier kann auch ein dein puffer rein (TStream/Memory/File) damit es schneller abläuft
// wenn im puffer-modus, musst du noch eine methode einbauen die die letzten zeichen vor dem ende sich "merkt" und beim nächsten puffer-laden vorneweg einbindet
// LESE UNBEDINGT VORHER DIE DELPHI HILFE UM ZWISCHEN ASCII UND UTF-8 DATEIEN ZU UNTERSCHEIDEN, im normalfall wird ascii (0-127) verwendet (ich glaube so etwas gelesen zu haben)
 try
  while not(test.EndOfStream) do // in diesem beispiel verarbeite den TStreamReader.Create komplett bis zum ende der datei
   begin
    Memo1.Lines.Add(test.ReadLine); // das hier ist nur platzhalter damit man weiß wie man ReadLine benutzt
// wenn du RichEdit anstelle von Memo nimmst, wird es ein wenig schneller
// Memo konvertiert manchmal alles nochmal um und verbraucht damit 2-4x soviel speicher bei gleicher datenmenge
// hier könntest du zum beispiel 100 zeilen in eine tstringlist o.ä. sammeln/puffern
// die strings eventuell noch bearbeiten
// und dann alle 100 auf einen rutsch in die anzeige mit beginupdate/endupdate zu casten
   end;
 finally
  test.Free;
 end;
end;
// dieses beispiel geht von richtigen input/output angaben aus und besitzt deswegen keinerlei weiterer checks
// try -> finally reichte mir zum testen aus

Zu Deinen Fragen:
1. Mit Puffern meine ich das was Du bereits machst, dir einen Teil vom ganzen Puffern (TStream).
2.1 Ich meinte Leerzeilen, nicht Leerzeichen

2.2 Die Zeile hier drüber ist eine Leerzeile und überall wo nichts steht ist ein Leerzeichen, das macht einen großen Unterschied