Daten aus großen Binärdateien lesen

[trid]

Hallo Wissende,

ich habe folgendes Problem:

Ich will aus einer ca. 10MB großen Binärdatei der Reihe nach alle Daten lesen, konvertieren und in einem Textfile abspeichern.
Funktioniert auch soweit ganz gut, nur....

wenn ich mit

while not eof(SourceFile)

auf das ende hin prüfe, bricht das programm immer nach genau 835168 gelesenen bytes ab.

lasse ich diese Prüfung weg, bricht er zwar nicht ab, liest aber nur noch $1A.

Hat jemand IRGENDEINE Idee, wie das zu verhindern ist.

ich benutze im groben folgendes Konstrukt:

AssignFile(SourceFile,OpenDialog1.FileName);
Reset(SourceFile);

while not eof(SourceFile)....
read(SourceFile, lb);


Für Ideen und Anregungen im Vorraus vielen Dank

[The-X]

1. Binärdateien liest man normalerweise nicht mit read(f,bytevar); sondern mit wie folgt

Delphi-Quellcode:

Procedure ConvertFiles(Var Source,Dest:String);
Var Fsource,FDest:File;
    bRead,bWrit:Integer;
    i:Integer;
    Buf:Array[0..1023]of Byte;
Begin
 AssignFile(FSource,Source);Filemode:=FmOpenRead;Reset(Fsource,1); //Quell-Datei lesen
 AssignFile(FDest,Dest);Filemode:=FmOpenWrite;Rewrite(FDest,1); //Ziel-Datei erstellen

 Repeat
  BlockRead(FSource,Buf,Sizeof(buf),bRead);
  For I:=0 to bRead do buf[i]:=buf[i] xor 255; // "Konvertierung"
  BlockWrite(FDest,Buf,bRead,Bwrit);
 Until (bread=0) or (bRead<>bWrit);

 CloseFile(FDest);
 CloseFile(FSource);
end;

^^ (Splatter-Source... nur zur Verdeutlichung, Keine Laufgarantie !!!)

Wenn du mit Typisierten Dateien Arbeitest bricht Eof beim ersten Aufkommen von $1A auf zu lesen
($1A war/ist das Hier-ist-die-Datei-zuEnde-Zeichen)
daher bei Binär Dateien besser mit Blockread/Write arbeiten .. ;)

wenn du als Ausgabe eine Textdatei hast kannst du aus FDest eine TextFile machen und wie gehabt mit Write[ln]/Read[ln] arbeiten...

[trid]

Danke für die schnelle Antwort, habs gerade rausgefunden, als ich sah, daß dann auch nur noch $1A gelesen wird. :wall:

[Matze]

:hi: trid

Bitte entferne den Hinweis, dass es sich um eine offene Frage handelt, da diese ja nun gelöst ist. Danke. ;)

[generic]

warum arbeitet hier bei dp niemand mit tfilestream ?

[Stevie]

Zitat:

Zitat von generic

warum arbeitet hier bei dp niemand mit tfilestream ?

Ich tu's... :roll: Aber es hat halt beides seine Vorteile

[The-X]

Der TFileStream hat AFAIK einen entscheidenden Nachteil... er lädt zuerst die komplette Datei in den Speicher bevor man damit arbeiten kann... was bei der AssignFile-Variante nicht der Fall ist...
Es werden nur die Bytes gelesen die man wirklich braucht.
(habe das mal bei einem MP3-Tag-Demo festgestellt...
TFileStream.Seek dauerte bei einer 15Mb Datei etwa 3-4 mal so lange wie ein AssignFile/Seek/Blockread-Konstrukt (unter gleichen Bedinungen ... habe jeweils voher neugestartet)
und das bei der gleichen Datei)

ein Vorteil von TFileStream scheint mir die Fehlerüberprüfung zu sein welche man bei AssignFile u.a. komplett selber implementieren muss.

[Christian Seehase]

Moin The-X,

Zitat:

Zitat von The-X

TFileStream.Seek dauerte bei einer 15Mb Datei etwa 3-4 mal so lange wie ein AssignFile/Seek/Blockread-Konstrukt (unter gleichen Bedinungen ... habe jeweils voher neugestartet)
und das bei der gleichen Datei)

:shock:

Beide Seek Routinen greifen intern auf die API SetFilePointer zu.
Das TFileStream etwas langsamer ist kann ich mir noch vorstellen (Overhead wg. Objekt), aber so. :gruebel:

Was heisst 3-4 mal so lange absolut?

[The-X]

ich meinte damit das Auslesen des Id3Tags bei der 15Mb-Datei...

ohne TFileStream dauerte das reine Auslesen knapp eine Sekunde,
mit TFileStream etwa 3-4 Sekunden da, wie ich vermute, zuerst die komplette Datei in den Speicher gelesen wird bevor die Open/Create-Funktion endet :roll:

und das ist für mich ein Grund keine TFileStreams zu nutzen wenn es sich irgendwie vermeiden lässt