Ärger mit ZLibs "CompressBuffer"

[Daniel]

Meine Güte ... offenbar sehe ich den Wald vor lauter Bäumen nicht. Ich möchte eine Handvoll Daten komprimieren. Ich reserviere mir Speicher, kloppe die Daten dort hinein und übergebe das Ganze dann an die Funktion "CompressBuf()". Da ich im Endeffekt nur .... randomisierte Daten ... herausbekomme, jedoch kein gültiges Archiv, schreibe ich die Daten vorher und nachher mal in eine Datei - nur testhalber:

Delphi-Quellcode:

pOut:= NIL;  // wird von CompressBuf behandelt
sWrite:= 0;  // wird von CompressBuf behandelt

assignfile( f, './.cache/test_out_before.xml' );
rewrite( f, 1 );
blockwrite( f, pIn^, sSize );
closefile( f );

// An dieser Stelle angekommen stehen meine Ausgangsdaten
// korrekt in der eben erzeugten Datei

CompressBuf( pIn, sSize, pOut, sWrite );


assignfile( f, './.cache/test_out_after.gz' );
rewrite( f, 1 );
blockwrite( f, pOut^, sWrite );
closefile( f );

// An dieser Stelle angekommen steht nur "Käse" in der
// erzeugten Datei - sie ist eben kein gültiges Archiv

Auf das Problem gestoßen bin ich, als ich eigentlich etwas dekomprimieren wollte und das auch nicht so ganz prächtig lief. Offenbar mache ich hier etwas Prinzipielles mit der ZLib falsch. :oops: Nur was? :gruebel:

[Der_Unwissende]

Hi,
welche ZLib benutzt du denn genau? Hab gerade ZLib123 und ZLib (dll + .h) gefunden, doch keine von beiden bietet die Funktion CompressBuf.

Gruß Der Unwissende

Ok, wohl die die Delphi beiliegt, peinlich. Gut, gucken wir doch mal

[Der_Unwissende]

Äh, doch ich glaube die Frage stellt sich mir immer noch. Welche ZLib benutzt du denn? Bei Delphi 7 Pro ist eine Unit Zlib integriert, aber ich habe nur einen Compression Stream. Der hat dann auch keine Methode CompressBuf.

[Der_Unwissende]

Ok, hab das ganz mal über den Compress und Decompress-Stream gemacht, aber dabei gemerkt, dass es in der Unit wohl auch die Methoden gibt, die du meinst. Das du kein gültiges Archiv bekommst stimmt denke ich nur bedingt. Es handelt sich nur offenbar um ein Format, dass nicht weiter bekannt ist (also keinem Packer den ich kenne). Vielleicht wird auch nur kein header mitgeschrieben sondern du erhälst halt nur die Rohgepackten Daten, aber mit der Decompress Routine von ZLib kannst du das gepackte wieder lesen.
Aber ich persönlich würde dir zu einer anderen Komponente für's packen raten. ZLib scheint nicht gerade viel zu können (oder ich hab einiges an Information übersehen).
Aber mehrere Dateien in einem Stream wiederfinden oder Ordner mitpacken ist wohl so direkt eher nicht drin? Da gibt es doch mit Sicherheit ne Menge besserer Tools.

Gruß Der Unwissende

[retnyg]

falls du nur was packen willst kannst es ja auch mal mit retcompress probieren

[Daniel]

Halli hallo,

zuerst mal meinen Dank für die Antworten. Ich benutze die ZLib-Unit, die bei Delphi (2005) direkt dabei ist. (zlib_Version = '1.0.4').

Zitat:

Zitat von Der_Unwissende

[...]
Es handelt sich nur offenbar um ein Format, dass nicht weiter bekannt ist (also keinem Packer den ich kenne).

hmm.. Also dann hole ich doch mal etwas weiter aus: Ich lese mit einer Delphi-Anwendung XML-Daten von diesem Server. Client-seitig sitzen da die Indys dran (Version 9.x). Der Server (Apache) komprimiert auf Wunsch, wenn man diese Information im Header der Anfrage mitschickt. Es handelt sich hierbei um ein Standard-gzip. Schreibe ich diese Rohdaten auf die Platte, so kann ich diese mit jedem Packer öffnen, der gzip versteht.

Nun habe ich also die komprimierten Daten in meinem Stream stehen und muss logischerweise wieder zu den unkomprmierten Daten kommen. Die Indys in Version 10 haben hier diverse Möglichkeiten, bei der 9er-Serie habe ich noch keine Automatik entdecken können. Also griff ich zur ZLib und zuerst zum "TDecompressionStream" - aber wie ich es auch drehe und wende, ich kann den Quatsch nicht dekomprimieren. Ich kann jetzt erstmal ohne Komprimierung weiterarbeiten, aber gerade bei XML ist es ja ein Jammer, wenn man nicht komprimiert.

Eine Anfrage mittels Google vermittelte mit den Eindruck, dass die ZLib-Unit sehr wohl in der Lage sein müsste, gzip-Daten zu verarbeiten. Ist das etwa ein Trugschluss?

Ein Letztes noch: Aus verschiedenen Gründen möchte ich vorerst bei der 9er-Serie der Indys bleiben - ein Wechsel auf Version 10.x ist also nicht meine erste Wahl.

[Daniel]

...hupsa...
:oops:

Zitat:

Why does gzip give an error on a file I make with compress/deflate?

The compress and deflate functions produce data in the zlib format, which is different and incompatible with the gzip format. The gz* functions in zlib on the other hand use the gzip format. Both the zlib and gzip formats use the same compressed data format internally, but have different headers and trailers around the compressed data.

:angel2:

Hätte mir das nicht irgendwer früher sagen können? :mrgreen:

[Der_Unwissende]

Na ja, wenigstens kein Fehler deinerseits! :wink:
Und eine GZip-Unit findet sich bestimmt irgendwo

[Daniel]

Okay - jetzt habe ich es. Mit der ZLib-Unit. :-)

GZIP ist Dateiformat, das zugehörige Kompressionsverfahren läuft unter dem Namen Deflate. Sagt man dem Server also, man hätte die Daten gerne in Form von "Deflate", so lässt er das ganze Schnüdeldüdel, das "GZip" mitbringt weg und man hat die reinen Nutzdaten. Und mit diesen wiederum kommt die ZLib-Unit von Delphi ganz hervorragend klar.

[Der_Unwissende]

Hey, das ist doch schön, jetzt wurde doch glatt mal gezeigt dass viel Text durchaus sinnvoll ist (wenn ihn jmd. liest). Ist hier zwar OT, aber da war doch ein Thread, grübel.

Aber gut zu wissen! Muss ich mir merken.