Zitat von
Christian.Ossi:
Wie das genau funktioniert mit den Seek-Nummern und hintereinander speichern würde mich mal interessieren
Also eigentlich sind das nur die Grundlagen eines TStream Objekts. Wenn dir hier die
OH anschaust
TStream wirst du schon so ziemlich alles finden was es zu wissen gibt. Die Idee ist einfach, du hast einen Stream ich bezeichne ihn einfach mal als ein völlig dynamisches Array von Bytes. Und du kennst die aktuelle Position auf der du dich befindest. Jede Aktion, die du ausführst ist immer relativ zu dieser Position. Schreibst du etwas, so wird es nicht automatisch hinten rangehangen, du schreibst einfach die Anzahl der angegebenen Bytes an die aktuelle Position (und ff). Gleiches gilt für das Lesen. Auch hier darfst du nicht davon ausgehen, dass du deine aktuelle Position bei 0 beginnt. Insbesondere gilt dies, wenn du die Position auf 0 setzt, einen Wert einliest und diesen nun überschreiben möchtest. Zum Überschreiben müsstest du nun erst zurück zur 0!
Da du als kleinste Einheit, die du speichern kannst ein Byte hast, wird die Anzahl der zu lesenden bzw. zu schreibenden Bytes angegeben. Ein Stream speichert alle Bytes die man ihm gibt (typ ist const, also beliebig), hat aber deshalb keine Größeninformationen. Möchtest du etwas speichern und wieder einlesen, so wird häufig der Trick angewendet, dass man erst die Anzahl der Bytes angibt, gefolgt von dem Datensatz. Die Anzahl der Bytes muss dann dabei in einer festen Größe (z.B. 4 Byte = Cardinal/Integer) abgelegt werden:
Delphi-Quellcode:
var stream : TStream;
data : TByteDynArray;
begin
// data füllen
...
stream := TMemoryStream.Create;
// wichtig, verwende einen Ressourcenschutzblock
try
stream.Position := 0;
stream.write(length(data), sizeOf(Integer));
stream.write(data[0], length(data));
// weitere Daten hinzufügen und speichern des Streams
...
finally
stream.Free
end;
finalize(data);
setLength(data, 0);
end;
Hier soll nur einfach gezeigt werden, wie du das speichern würdest. Du weißt nun, dass deine Datei mit 4 Byte beginnt (die Länge des Arrays). Hast du die Länge x ausgelesen, sind die nächsten x Byte also das hier gespeicherte Array. Dahinter kommt dann die nächste Länge und das nächste Array.
Natürlich wäre es jetzt sehr nervig, wenn du jedesmal über die gesamte Datei laufen müsstest, um all diese Informationen zu holen. Ein weiteres Problem, du hast wenig Flexibilität. Wenn du mehr Meta-Infos benötigst als die Größe, so kannst du die nicht einfach einfügen, du kannst sie ja nicht von den Daten einer alten Datei unterscheiden. Also müsstest du die alten Dateien komplett neu anlegen.
Deshalb gibt es verschiedene Alternative Möglichkeiten. Da sich unabhängig von den Metadaten die Nutzdaten nicht ändern, kannst du einfach zwei Dateien verwalten. Die eine ist dann nur ein Stream, in dem die Nutzdaten einfach nur hintereinander stehen. Damit du nun weißt an welcher Stelle was steht und wie viel Bytes es einnimmt, speicherst du diese Informationen seperat in einer zweiten Datei.
Weitere Alternativen sind Dateiheader. Hier schreibst du die Metadaten an den Anfang (oder unüblicher an das Ende) der Datei. Wenn du diesen Bereich (beliebiger Größe) als solchen Kennzeichnest (spezielle Bytefolgen), so weißt du wo der Header anfängt und wo er endet. Die Erreichte Flexibilität hängt dann nur noch davon ab, wie geschickt der Header implementiert ist. Tiffs zum Beispiel haben ein sehr flexibles Containerformat, dass einem so ziemlich alles ermöglicht (man kann Multipage-Tiffs erstellen, die dann wirklich mehr als ein Bild enthalten, man könnte aber auch noch zusätzlich eine Zip Datei, ein Avi und ein Windowsimage in die Datei packen. Die letzteren Fälle müssten nur nicht von einem Standardkonformen Programm verstanden werden, doch das Tiff wäre valide).
Natürlich hast du die volle Flexibilität wenn du ein Stream verwendest. Aber ein Virtuelles Dateisystem und ein Archiv sind letztlich auch nur Kapselungen vom Selbigen. Ich bleib hier einfach mal bei einem Zip-Archiv. Hier wird intern auch nur ein Stream mit sehr speziellen Headern erzeugt, aber du musst dich nicht darum kümmern. Wo genau ein abgelegtes File anfängt und wo es endet weiß das Archiv, du sagst nur, leg die Datei ab und hol mir die Datei wieder. Natürlich kann ein Archiv noch etwas mehr, du hast automatisch eine Verschlüsselung (Zip-Passwort) oder eben nicht (kein Passwort), du hast eine Checksumme für die Konsistenzprüfung und natürlich wenn du möchtest Kompression. Was du davon verwendest ist dann deine Sache.
Ich will dir hier gar nicht von Streams abraten, nur braucht man von Zeit zu Zeit nicht das
Rad neu erfinden...