StringList => LoadFromFile liest Datei nur zum Teil ein

[juergen]

erstmal danke für die Tipps.

Ich hatte gehofft dass es mit TStream gehen könnte. Aber da wird auch nur bis "2127" gelesen.

Delphi-Quellcode:

var
  fs: TStream;
begin
  fs := TFileStream.Create(lbCsvDateien.Items[i], fmOpenRead);
  try
    try
      sl_EinzelDatei.LoadFromStream(fs);
    except
      on E: EReadError do
        ShowMessage(E.Message);
    end;
  finally
    FreeAndNil(fs);
  end;
end;

Dann hatte ich es mit ReadLn probiert. Damit werden zwar alle Zeichen gelesen, aber die Datei hat nicht mehr denselben Satz-Aufbau. Einige, wenige Zeilen haben einen anderen Inhalt wie die Ursprungsdatei.

Delphi-Quellcode:

sl_Gesamt_alle_Dateien := TStringList.Create;
try
  for i := 0 to ListBox_mit_allen_Dateien.Items.Count - 1 do
  begin
    sl_EinzelDatei := TStringList.Create;
    try
      try
        AssignFile(F, ListBox_mit_allen_Dateien.Items[i]);
        Reset(F);
        while not eof(F) do
        begin
          s := '';
          Readln(F, s);
          sl_EinzelDatei.Add(s);
        end;
      Except
        on E: EReadError do
          ShowMessage(E.Message);
      end;
    finally
      CloseFile(F);
    end;

      sl_Gesamt_alle_Dateien.AddStrings(sl_EinzelDatei);

      sl_EinzelDatei.Free;
  end;

  sl_Gesamt_alle_Dateien.SaveToFile(txtAusgabePfad.Text, TEncoding.Default);

finally
  sl_Gesamt_alle_Dateien.Free;
end;
....

Mir gehen hier leider die Ideen aus.

Für weitere Hilfe wäre ich sehr dankbar.

[Dalai]

Zitat von juergen:

Ich hatte gehofft dass es mit TStream gehen könnte. Aber da wird auch nur bis "2127" gelesen.

Delphi-Quellcode:

var
  fs: TStream;
begin
  fs := TFileStream.Create(lbCsvDateien.Items[i], fmOpenRead);
  try
    try
      sl_EinzelDatei.LoadFromStream(fs);
    except
      on E: EReadError do
        ShowMessage(E.Message);
    end;
  finally
    FreeAndNil(fs);
  end;
end;

Gehe ich recht in der Annahme, dass sl_EinzelDatei eine Stringliste ist? Wenn ja: das wird so nix. Der Stream liest alles, völlig egal, was das für Zeichen sind. Nur bei der Zuweisung zur Stringlist ist eben bei den Nullbytes Schluss. Du musst vor dieser Zuweisung die unerwünschten Zeichen rausfiltern, wenn du hinterher mit Strings arbeiten willst. Leider kann ich nichts konkretes in dieser Richtung beitragen, weil ich eine derartige Problemstellung noch nicht hatte. Ich meine mich aber zu erinnern, dass es bereits Thema hier in der DP war.

Grüße
Dalai

[Fukiszo]

ich hatte mal ein vergleichbares problem,
ich habs per Stream in speicher geladen und dann nach $0D + $0A gesucht,
alles was vor $0D $0A kommt wird mit einer BufToText funktion in eine stringlist gespeichert.
Alle nicht lesbaren/druckbaren zeichen werden in BufToText rausgefiltert.
So etwas ist nur sinnvoll bei kleinen input dateien da jedes einzelne zeichen geprüft wird.

falls interesse daran besteht such ich den source raus wo ich es nutzte.
falls es generell falsch wäre spare ich mir die suche.

Grüße

[p80286]

Zitat von juergen:

Dann hatte ich es mit ReadLn probiert. Damit werden zwar alle Zeichen gelesen, aber die Datei hat nicht mehr denselben Satz-Aufbau. Einige, wenige Zeilen haben einen anderen Inhalt wie die Ursprungsdatei.

Woran machst Du das denn fest?
Lässt Du Dir den Inhalt z.B. in einem Memo anzeigen?

Alle Zeichen kleiner x20 sind Steuerzeichen und werden (oder auch nicht) bei der Ausgabe interpretiert. Hierbei ist es teilweise möglich, daß ein Ersatzzeichen ausgegeben wird oder auch das das Zeichen ignoriert wird.

Eine Quick and very dirty-Lösung wäre es, alle Zeichen kleiner x20 durch x20 zu ersetzen, dann könntest Du mit weiterhin mit Strings arbeiten.
Solange aber nicht klar ist woher die Zeichen stammen, ob sie sinnvoll oder sinnlos sind, geht wohl kein Weg an einer binären Verarbeitung vorbei.

Gruß
K-H

[juergen]

Hallo zusammen,

von Dalai kam der für mich entscheidende Tipp! (ich darf keine StringList nutzen, jetzt im Nachhinein ist das auch klar...)
Die einzelnen Dateien lade ich mir nun in einen TStream. Dann kopiere ich diesen Stream in einen TMemoryStream per copyfrom() fs_Gesamt.CopyFrom(fs, fs.Size); Der Memorystream hat direkt eine SavetToFile-Methode. Somit nutze ich *keine* StringList mehr und alles funktioniert.

Vielen Dank für den Schubs in die richtige Richtung!

Zitat:

Zitat von juergen:
Dann hatte ich es mit ReadLn probiert. Damit werden zwar alle Zeichen gelesen, aber die Datei hat nicht mehr denselben Satz-Aufbau. Einige, wenige Zeilen haben einen anderen Inhalt wie die Ursprungsdatei.
Woran machst Du das denn fest?

Ich hatte das Ergebnis mit UltraCompare jeweils verglichen. Da sah ich dann die Unterschiede.

Vielen Dank an alle und Gute N8!

[HolgerX]

Hmm..

Mal eine Frage:
Könnte es sein, dass der Text in der TStringList richtig ist, jedoch bei der Ausgabe im Memo am #0 abgeschnitten wird?
Ich habe in einer StringList so oft Files mit #0 geladen und bearbeitet.. Alles ohne Probleme.
Jedoch bei der Anzeige im Memo ist am #0 ende.

[himitsu]

Nein, LoadFromStream und LoadFromFile behandeln auch extra die 0 und schneiden schon ab.
EXTRA = absichtlich eingebaut

Es gibt auch einen Unterschied zwischen den vielen TStrings.
Bei TStringList können während ihrer Nutzung sogar #0 und Zeilenumbrüche innerhalb eines "Strings" enthalten sein, da dort intern und in den Property/Methoden des TStrings der Delphi-"String" genutzt wird, welcher es erlaubt.
Bei TMemoStrings und Anderen ist das nicht möglich.

[HolgerX]

Hmm..

Dass war der Grund meiner Frage..
Ich habe bisher TStringList zum Laden von Text-Dateien verwendet und da hat es mit #0 kein Abschneiden gegeben.

LoadFromStream und LoadFromFile mach jeweils keinen Unterschied, da ja LoadFromFile einen FileStream erzeugt und mit diesem dann an LoadFromStream aufruft.
(Zumindest bei D6 )

Unter D6 verwendet das LoadFromStream von TStringList auch nur die Funktionen von TStrings und ist somit identisch zu TMemoStrings. Die TStringList hat keine eigene LoadFrom.. Funktionen.

Das bei einem Memo bei #0 abgeschnitten wird, hat eher den Hintergrund, dass der Text per SendMessage (WM_SETTEXT) an das Memo.Handle (= Windows Edit) geschickt wird, und dort halt ein String ohne Längenangabe versendet wird, welcher dann wie ein PChar verwendet wird und bei dem ist an #0 ende..

Würde man somit auf Memo.Lines direkt zugreifen, könne nach einem LoadFrom.. dort doch der komplette Test stehen, nur wird dieser nicht im Memo angezeigt.

(Oder so ähnlich...)

ich vermute, dass sich mit Umstellung auf Unicode hier etwas verändert hat..

[himitsu]

Seit Delphi 2009 gibt es im LoadFrom... auch noch die Behandlung des Encodings.
Und da kommt es auch drauf an, wie TEncoding mit #0 umgeht.

Nach dem Laden und Decodieren der Datei/Stream kommt der Text dann in TStrings.SetTextStr rein und siehe da, eine Abbruchbehandlung für #0, da das Ganze als PChar behandelt wird.

Delphi-Quellcode:

procedure TStrings.SetTextStr(const Value: string);
var
  P, Start, LB: PChar;
  S: string;
  LineBreakLen: Integer;
begin
  BeginUpdate;
  try
    Clear;
    P := Pointer(Value);
    if P <> nil then
      if CompareStr(LineBreak, sLineBreak) = 0 then
      begin
        // This is a lot faster than using StrPos/AnsiStrPos when
        // LineBreak is the default (#13#10)
        while P^ <> #0 do
        begin
          Start := P;
          while not (P^ in [#0, #10, #13]) do Inc(P);
          SetString(S, Start, P - Start);
          Add(S);
          if P^ = #13 then Inc(P);
          if P^ = #10 then Inc(P);
        end;
      end
      else
      begin
        LineBreakLen := Length(LineBreak);
        while P^ <> #0 do
        begin
          Start := P;
          LB := AnsiStrPos(P, PChar(LineBreak));
          while (P^ <> #0) and (P <> LB) do Inc(P);
          SetString(S, Start, P - Start);
          Add(S);
          if P = LB then
            Inc(P, LineBreakLen);
        end;
      end;
  finally
    EndUpdate;
  end;
end;