TTextStream - Textdateien einlesen

[himitsu]

So, den nun hab ich erstmal den Schreib-/Lesekern meiner neuen StringListe seppariert und er läuft endlich.
Manchmal muß man eben mit mehrfachem Code leben ... hartkodierte Konstanten sind eben schneller, als Variablen und eine dynamische Verarbeitung.

Diese Klasse ließt eine beliebig große Textdatei sequentiell ein, wobei sogar unterschiedliche Kodierungen (TEncoding) unterstützt werden und ein eventuelles BOM ausgewertet wird.
Speichern ist natürlich auch möglich.

Nja, die Speicherverwaltung des Lesepuffers gefällt mir noch nicht so ganz
( http://www.delphipraxis.net/internal...t.php?t=177739 ),
aber für diesen Fall dürfte es denoch ausreichend sein.

Ja nach Datei und Computer ist es etwa gleichschnell oder schneller als eine TStringList zu Einlesen braucht (wobei die TStringList irgendwann an ihre Speichergrenzen stößt, da sie alles im Arbeitsspeicher verarbeitet, welches beim Einlesen einer einfachen Ansi-Datei in Delphi2009/2010 mehr als den 4-fachen Speicherbearf, der ursprünglichen Dateigröße verlangt)



Als Zusatzmodul ist mir eingefallen, daß man die (ur)alten Pascal-Datei-Funktionen ersetzen könnte,
aber leider ist es nicht möglich einen adequaten Ersatz für Read, ReadLn, Write und WriteLn zu finden ,
Aber vielleicht hat ja jemand eine brillante Erleuchtung.


PS: Der Name "TStringStreamEx" der Klasse gefällt mir eigentlich auch nicht, aber irgendwer hatte schon die Idee eine andere Klasse TStringStream zu nennen.

[edit] Name angenommen

[edit 20.05.2010]

• alles etwas überarbeitet
• eine Version für Delphis vor 2009 erstellt
  Als Bonus hat sie eine einfache Variante des TEncoding bekommen, welches man natürlich auch für andere Dinge nutzen könnte.
• und Zusatzmodul TTextStreamEx fertiggestellt

[edit 21.05.2010 v1.2c]
Wo es nun zu laufen scheint, hab ich mir mal die Unterschiede angesehn
und beide Versionen miteinander kombiniert.

Außerdem hatte ich glatt was vergessen zu übernehmen.
Beim Einlesen einer Datei werden die Zeilenumbrüche analysiert und das Property LineBreak enthält dann den häufigsten Zeilenumbruch (falls es mal ein bissl gemischt ist) ... die FileStringList wird somit später den Zeilenumbruch einer Datei quasi erhalten und ihn nicht ständig auf Windowsstandard (CRLF) abändern.

[edit 17.08.2010 v1.3]
- BOM-Erkennung bei Angabe einer Kodierung integriert
- BOM kann nun beim Schreiben weggelassen werden

[edit 18.10.2010 v1.4a2]
- neue Testversion (sie Beitrag #31)

[himitsu]

Zitat von p80286:

Ihr kommt auf Ideen, solche Perversitäten,

*rrrrrrrr*

Manchmal sind die alten Pascal-Funktionen eigentlich recht praktisch.
Nur schade ist, daß man damit nur ANSI-Text-Dateien erstellen und auslesen kann
und das interne Caching ist nicht unbedingt .... nja, ich wie soll man es denn nennen? ... optimal?

Hiermit könnte man sogar eine normale TStringList effektiver füllen. Zumindestens was größere Dateien angeht, dann so ab einer 300 MB-Textdatei bekommt man schonmal ein OutOfMemory, da ja alles am Stück eingelesen und verarbeite wird, also wärend des LoadFrom... und SaveTo....

[himitsu]

[info] nicht wundern ... es gibt jetzt nur noch eine Version für Unicode (D2009/2010) und die anderen Delphis.

Nja, und ein paar vergessene Codezeilen wurden noch schnell integriert ... die Erkennung der Zeilenumbrüche (siehe [edit] in #1).

[chaosben]

Fein gemacht!

Ein Verbesserungsvorschlag für Zeile 707: Else Mode := fmOpenReadWrite or fmShareDenyWrite or fmCreate; Ohne dem dem fmCreate machts bei neuen Dateien einfach nur buuuuuuum.

[himitsu]

Ups, also für Zeile 706+707 dann Dieses:

Delphi-Quellcode:

If      Access = saRead   Then Mode := fmOpenRead      or fmShareDenyWrite
Else If Access = saAppend Then Mode := fmOpenReadWrite or fmShareDenyWrite
Else               Mode := fmCreate or fmOpenReadWrite or fmShareDenyWrite;

Im Testcode lese ich über einen Stream ein und schreibe auch darüber. Und dort wird über CreateFile + einen speziellen THandleStream gearbeitet ... da ist dieser CodeTeil wohl etwas zukurzgeraten, beim Test.


Hier knallt's nicht, aber es ist schon blöd, daß man dem TFileStream nicht weitere Attribute mitgeben kann (vorallem FILE_FLAG_RANDOM_ACCESS und FILE_FLAG_SEQUENTIAL_SCAN geb ich ja gerne mal an, um Windows ein bissl unter die Arme zu greifen)

Delphi-Quellcode:

Case Mode of
  fmReadWrite:  Begin
                  A := GENERIC_READ or GENERIC_WRITE;
                  C := OPEN_EXISTING;
                End;
  fmCreate:     Begin
                  A := GENERIC_READ or GENERIC_WRITE;
                  C := CREATE_NEW;
                  Mode := fmReadWrite;
                End;
  fmCreateOrRW: Begin
                  A := GENERIC_READ or GENERIC_WRITE;
                  C := OPEN_ALWAYS;
                  Mode := fmReadWrite;
                End;
  Else          Begin
                  A := GENERIC_READ;
                  C := OPEN_EXISTING;
                End;
End;
H := CreateFile(PChar(Filename), A, FILE_SHARE_READ, nil, C,
  FILE_FLAG_RANDOM_ACCESS or FILE_ATTRIBUTE_NOT_CONTENT_INDEXED, 0);
If H = INVALID_HANDLE_VALUE Then
  Raise EFCreateError.CreateResFmt(@SFCreateErrorEx,
    [ExpandFileName(Filename), SysErrorMessage(GetLastError)]);
AssignToStream(THandleStream2.Create(H), True, Mode = fmReadOnly, Encoding);

Mal sehn, vielleich verbau ich noch 'ne Abwandlung davon in diesem Code.

[chaosben]

Dann habe ich noch ein Problem ... beim Flush im Destructor eines schreibenden (logisch ) TTextStreams kommt eine Zugriffverletzung an der Stelle FByteBuffer := FEncoding.GetBytes(FStringBuffer); in der Funktion "WideCharToMultiByte".

Ich gebe zu, dafür kannst du wahrscheinlich nicht direkt was, aber falls dir eine Lösung einfällt, würde ich mich freuen.

Das hier funktioniert nicht:

Delphi-Quellcode:

procedure TForm30.FormCreate(Sender: TObject);
var
  tt : TTextStream;
begin
  tt := TTextStream.Create('f:\test.txt', saWrite);
  tt.WriteLine(DateTimeToStr(Now));
  tt.Free;

end;

Das gleiche in einer ConsolenApp geht [edit]auch nicht[/edit].

[himitsu]

Oh, da hat sich noch ein Fehler bei der Pufferumstellung eingeschlichen
(früher Byte-Array mit 0-Index und jetzt String mit der bösen 1, aber die anderen Codestellen sehen diesbezüglich OK aus )

Zeile 811

Code:

[b]Procedure[/b] TTextStream.WritePart(Const S: SString);
  [b]Begin[/b]
    ...
      Move(S[1], FStringBuffer[FBufferSize[color=#ff0000][b] + 1[/b][/color]], Length(S) * SizeOf(Char));

und Zeile 836

Code:

[b]Procedure[/b] TTextStream.Flush;
  [b]Begin[/b]
    [b]If[/b] FAccess <> saRead [b]Then Begin[/b]
      FByteBuffer := FEncoding.GetBytes([color=#ff0000][b]Copy([/b][/color]FStringBuffer[color=#ff0000][b], 1, FBufferSize)[/b][/color]);

Aber schon witzig, daß es dennoch manchmal problemlos läuft.

Zitat von chaosben:

[edit]auch nicht[/edit].

manchmal schon


Zum Glück muß ich Fehler jetzt nur noch in einer Version fixen

[chaosben]

Vielen Danke fürs fixen.

[freejay]

Hi Himitsu,

ich benutze Deine Unit TextStream und habe dabei ein Problem und eine weitere Frage:

1. Wenn man eine Datei einliest, die UTF-8 codiert ist (mit! BOM), dann erhält man in der ersten Zeile als erstes "Zeichen" immer $FEFF (65279). Dies passiert nur, wenn man als Encoding beim Öffnen (=Create) TEncoding.UTF8 angibt. Lässt man das Encoding weg (nil), funktioniert es korrekt. Was kann man da machen?

2. Es scheint mir mit Deiner Unit nicht möglich zu sein eine UTF-8 codierte Datei ohne! BOM zu erzeugen, oder habe ich da etwas übersehen?

Danke in Voraus

Freejay

[himitsu]

Joar, da hatte ich wohl ein bissl zuviel gelöscht.

1. sollte jetzt funktionieren.
(die Prüfung wurde ausversehn mit entfernt)

2. joar, das war hier eigentlich nicht vorgesehn
(in meiner größeren Version gibt es dafür eine interne Option ... hab dafür aber nun einen neuen Access-Wert eingeführt > saWriteWithoutBOM)


#$FEFF ist das "Zeichen" für Unicode ... wenn man dieses Zeichen entsprechend kodiert, dann ergibt dieses das BOM der zugehörigen Kodierung.

[ChrisE]

Hallo,

erstmal TOP

Hab beim Überfliegen gerade gesehen, dass sich u.U. ein Copy&Paste-Fehler eingeschlichen hat. In Zeile 287-289 von Class Function TEncoding.GetASCII: TEncoding; wird FBigEndianUnicodeEncoding verwendet anstatt wahrscheinlich FASCIIEncoding .

Ist aber nur eine Vermutung.

Gruß, Chris