Datei an Datei anhängen

[MiniMax]

Woher weiß den der Code, wie lang der Text ist und das jpg? Der kennt doch nur die gesamt länge?

[rollstuhlfahrer]

Siehe Edit obendrüber: Es werden die einzelnen Längen in die Datei geschrieben und wieder ausgelesen.

Bernhard

[SirThornberry]

Such in dem Quelltext mal nach lDataSize. Das ist die Variable welche die Länge der Daten enthält und in die Datei geschrieben wird und umgekehrt.

Das Prinzip beim Speichern ist folgendes:
- Platz lassen für Größe der folgenden daten
- Daten schreiben
- Schauen wie groß die geschriebenen Daten waren
- Größe der geschriebenen Daten am Anfang platzieren wo wir Platz dafür gelassen haben.

[MiniMax]

ah jetzt hab ich es Verstnanden! Werde es eben Ausprobieren

[xZise]

Moin,
das Trennzeichen hat aber den Vorteil, dass die Länge nicht begrenzt ist. Außerdem braucht man mit 4 Byte am Anfang, wenn gar kein Text drin steht, sondern nur 1 oder 2 (je nach Kodierung).

Und es gibt viele die nicht das Rad neu erfinden: jars, Open Document, Office Open XML Dokumente verwenden alle *.zip zum komprimieren.

MfG
Fabian

[mkinzler]

Wenn man die Länge aber kennt, könnte man, wenn man die 2. Datei Einlesen will, direkt den Datensatzzeiger richtig positionieren.

[rollstuhlfahrer]

Also bitte: 4 GB Text und 4 GB als JPEG sind auch in fernerer Zukunft so schnell noch nicht erreicht. Selbst wenn: Dann ändert man Cardinal auf Int64 und hat die Probleme bis in alle Ewigkeit verschoben.

Bernhard

[Sir Rufo]

Zitat von xZise:

Moin,
das Trennzeichen hat aber den Vorteil, dass die Länge nicht begrenzt ist. Außerdem braucht man mit 4 Byte am Anfang, wenn gar kein Text drin steht, sondern nur 1 oder 2 (je nach Kodierung).

Und es gibt viele die nicht das Rad neu erfinden: jars, Open Document, Open Office XML Dokumente verwenden alle *.zip zum komprimieren.

MfG
Fabian

Selbst MS nutzt das ZIP-Format für die neuen Office-Dokumente

[xZise]

Zitat von Sir Rufo:

Zitat von xZise:

[...]Und es gibt viele die nicht das Rad neu erfinden: jars, Open Document, Open Office XML Dokumente verwenden alle *.zip zum komprimieren.[...]

Selbst MS nutzt das ZIP-Format für die neuen Office-Dokumente

Argh ein Verdreher, aber Office Open XML ist das neue Format von Office (docx etc.).

Und wegen der Länge: Wenn die JPG im Stream drin ist, dann ist sie ja fertig kodiert etc. das heißt man kennt schon deren Größe. Ein anderer Weg wäre die Länge hinten zu speichern. Bei Schreiben wird dann direkt hintereinander weg geschrieben, und beim lesen wird die letzte Größe gelesen, soweit nach vorne gesprungen und dann eingelesen werden:

Code:

i := Lese letzten Cardinal
Mache solange
  Springe i Bytes - Cardinalbreite * 2 zurück
  j := Lese Cardinal (= Länge von den Daten davor)
  Lese i Bytes
  Springe (i + j) Bytes - Cardinalbreite * 2 zurück
  i := j;
bis Position <= 0

Der aktuelle Weg wäre auch mit einem Pufferstream möglich. Darein kopiert man den Inhalt nimmt die Länge, schreibt sie, und kopiert dann den Inhalt des Pufferstreams in den echten Dateistream.

[redbox]Statt Image1.SaveToStram mach mal lieber Image1.Picture.SaveToStream. Das TImage zeigt nur ein TPicture an, das heißt speichern kann nur das Bild selber (und nicht der "Anzeiger").[/redbox]

[redbox #2]TImage selber geht nicht zu speichern, nur das Bild, was es geladen hat.[/redbox #2]

MfG
Fabian

[Luckie]

Zitat von xZise:

Moin,
das Trennzeichen hat aber den Vorteil, dass die Länge nicht begrenzt ist.

Und den Nachteil, dass man es beim Einlesen suchen muss. Will ich nur das JPEG haben, kann ich direkt an den Anfang des JEPGS springen und es auslesen. Ich denke die Vorteile überwiegen hier die Nachteile.

Aber warum das nachträgliche schreiben der Textlänge? Die kann ich doch schon vorher ermitteln und gleich schreiben.