XE2: gzip-Datei mittels System.ZLib dekomprimieren

[MatthiasR]

Ich möchte gern eine gzip-komprimierte Datei mithilfe der XE2-Bordmittel (Unit "System.ZLib") dekomprimieren. Leider funktioniert das nicht, ich erhalte immer einen "data error" beim Aufruf von "ZDecompressStr" und weiß nicht, was ich falsch mache. Die gz-Datei ist definitiv in Ordnung, ich kann sie problemlos mittels 7zip dekomprimieren. Hier der Code, den ich verwende sowie im Anhang das komplette Testprojekt. Vielleicht kann es ja mal jemand testen und sagen, was ich falsch mache. Mit "ZDecompress" und "ZDecompressStream" klappt es genauso wenig.

Delphi-Quellcode:

uses
  System.ZLib;

procedure TForm1.LoadButtonClick(Sender: TObject);
var
  InStream: TMemoryStream;
  CompressedFile: TBytes;
  UncompressedFile: string;
begin
  if OpenDialog1.Execute then
  begin
    InStream := TMemoryStream.Create;
    try
      InStream.LoadFromFile(OpenDialog1.FileName);
      InStream.Position := 0;
      SetLength(CompressedFile, InStream.Size);
      InStream.Read(CompressedFile[0], InStream.Size);
      UncompressedFile := ZDecompressStr(CompressedFile);
      UncompressedMemo.Text := UncompressedFile;
    finally
      InStream.Free;
    end;
  end;
end;

[Bernhard Geyer]

Schaut nach Standardfehler aus: Ab D2009 ist String = Unicodestring mit 1 Zeichen = 2 Bytes.
Dein Code setzt noch String = Ansistring mit 1 Zeichen = 1 Byte vorraus.

[MatthiasR]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1143729)

Schaut nach Standardfehler aus: Ab D2009 ist String = Unicodestring mit 1 Zeichen = 2 Bytes.
Dein Code setzt noch String = Ansistring mit 1 Zeichen = 1 Byte vorraus.

Das kann nicht sein, da der "data error" bereits beim Aufruf von "ZDecompressStr" auftritt und in keiner Zeile davor irgendetwas mit Strings veranstaltet wurde. Es wird ja kein String verschlüsselt, sondern ein Byte-Array entschlüsselt bzw. dekomprimiert.

[Bernhard Geyer]

Zitat:

Zitat von MatthiasR (Beitrag 1143735)

Das kann nicht sein, da der "data error" bereits beim Aufruf von "ZDecompressStr" auftritt und in keiner Zeile davor irgendetwas mit Strings veranstaltet wurde. Es wird ja kein String verschlüsselt, sondern ein Byte-Array entschlüsselt bzw. dekomprimiert.

Da bin ich um eine Zeile verrück gewesen. Wieso nennst du deine Variable UncompressedFile obwohl es ein String ist denn du dort haben willst:gruebel:

[MatthiasR]

??? CompressedFile ist doch auch nur ein Byte-Array, das die komprimierte Datei repräsentiert. Und UncompressedFile eben die dekomprimierte Datei, die eben eine Zeichenkette darstellt (das weiß ich schon vor dem dekomprimieren, dass es sich um eine Zeichenkette handelt).

Aber ist das bei einem simplen kleinen Testprojekt wirklich so relevant, wie ich eine Variable benannt habe?

[jaenicke]

Trotzdem ist das falsche Handling von Unicodestrings ziemlich sicher der Fehler:

Delphi-Quellcode:

      SetLength(CompressedFile, InStream.Size);
      InStream.Read(CompressedFile[0], InStream.Size);

Du hast einen Stream der Länge 400. Nun setzt du die Länge des Strings auf 400, sprich du hast dort 800 Byte in dem String. Dann packst du die 400 Byte aus der Datei in die ersten 200 Zeichen des Strings. Die anderen 200 Zeichen des Strings werden nicht beschrieben.

Was da ZDecompressStr draus macht, weiß ich nicht, aber sicher nix Gutes...

[Satty67]

Ist der UnicodeString hier nicht irrelevant. Es wird ja nur das Funktionsergebnis zugewiesen. Hoffe doch, dass das innerhalb der Funktion kein verändertes Verhalten auslösen sollte.

Vieleicht verwendet auch XE2 den Magic-Header, wie in den vorangegeangenen Versionen von ZLib. Wenn dieser fehlt, gibt es ein DataError. Siehe auch dieser Thread (letzter Post!)

[MatthiasR]

Zitat:

Zitat von jaenicke (Beitrag 1143742)

Trotzdem ist das falsche Handling von Unicodestrings ziemlich sicher der Fehler:

Delphi-Quellcode:

      SetLength(CompressedFile, InStream.Size);
      InStream.Read(CompressedFile[0], InStream.Size);

Du hast einen Stream der Länge 400. Nun setzt du die Länge des Strings auf 400, sprich du hast dort 800 Byte in dem String. Dann packst du die 400 Byte aus der Datei in die ersten 200 Zeichen des Strings. Die anderen 200 Zeichen des Strings werden nicht beschrieben.

Was da ZDecompressStr draus macht, weiß ich nicht, aber sicher nix Gutes...

:roll: Bitte schaut euch doch mein Codebeispiel mal etwas genauer an, Leute! Ich setze hier NICHT den String auf Länge 400, sondern die TBytes-Variable, also ein Array. Und das ist auch völlig in Ordnung so, weil da ja zu aller erst mal die Rohdaten reingepackt werden müssen, bevor das Array an die ZDecompressStr-Funktion übergeben wird.

[Bernhard Geyer]

Sind deine Quelldaten überhaupt Unicodestrings oder doch nur AnsiStrings (komprimierung von D2007 und früher)?

[Satty67]

Den String verwendet er doch nur hier:

Delphi-Quellcode:

  UncompressedFile := ZDecompressStr(CompressedFile);
  UncompressedMemo.Text := UncompressedFile;
  //bzw. gekürzt
  UncompressedMemo.Text := ZDecompressStr(CompressedFile);

@MatthiasR
Um die Sache mit dem Header schnell zu testen:

Erweitere den Instream nach dem Laden um 2 Byte. Verschiebe den Inhalt nach hinten und setzte die zwei Magic-Bytes davor wie im Thread beschrieben (mein letzter Post)

€: Sehe gerade, GZip hat einen 10 Byte Header. Der muss wohl weg und u.U. durch den Delphi 2 Byte Header ersetzt werden!

[MatthiasR]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1143748)

Sind deine Quelldaten überhaupt Unicodestrings oder doch nur AnsiStrings (komprimierung von D2007 und früher)?

Also wenn euch das mit den Strings jetzt so beschäftigt, dann schmeiß ich den eben komplett raus und arbeite nur mit Streams, kommt aufs gleiche raus (data error):

Delphi-Quellcode:

uses
  System.ZLib;

procedure TForm1.LoadButtonClick(Sender: TObject);
var
  InStream: TMemoryStream;
  OutStream: TMemoryStream;
begin
  if OpenDialog1.Execute then
  begin
    InStream := TMemoryStream.Create;
    try
      OutStream := TMemoryStream.Create;
      try
        InStream.LoadFromFile(OpenDialog1.FileName);
        InStream.Position := 0;
        ZDecompressStream(InStream, OutStream); // data error
      finally
        OutStream.Free;
      end;
    finally
      InStream.Free;
    end;
  end;
end;

Besser?

Das mit den Headern muss ich mal ausprobieren, einen ähnlichen verdacht hatte ich auch schon, aber einfach nur die ersten 10 Bytes (gzip-Header) abzutrennen brachte erstmal nichts.

[Bernhard Geyer]

Zitat:

Zitat von Satty67 (Beitrag 1143750)

€: Sehe gerade, GZip hat einen 10 Byte Header. Der muss wohl weg und u.U. durch den Delphi 2 Byte Header ersetzt werden!

Du musst unterschieden ob du GZIP als Filearchiv (Winzip und Co.) verwenden willst (10 Byte) Header oder einfach nur einen Stream komprimieren willst (2 Byte Header).

[Bernhard Geyer]

Zitat:

Zitat von MatthiasR (Beitrag 1143751)

Das mit den Headern muss ich mal ausprobieren, einen ähnlichen verdacht hatte ich auch schon, aber einfach nur die ersten 10 Bytes (gzip-Header) abzutrennen brachte erstmal nichts.

Äh Moment. Du willst diese Methode verwenden um ein Zip-Archiv zu entpacken. Wird nicht gehen. Die oben verwendete Funktion kann nur Streams (de)komprimieren. Bei einem GZip-Archiv gibt es noch Verwaltungsinformationen "Drum herum" um die einzelnen Datei im Archiv verwalten zu können.

[Satty67]

Bearbeite deinen Instream nach dem Laden mal so:

Delphi-Quellcode:

var
  AByteArray : PByteArray;
  i : Integer;
begin
  // gz header/footer replacement
  AByteArray := InStream.Memory;
  i := 10;
  while AByteArray[i] <> 0 do
    inc(i);
  AByteArray[i - 1] := $78;
  AByteArray[i] := $9C;
  InStream.Position := i - 1;
  InStream.Size := InStream.Size -8;

- Sucht das Header Ende (10 Byte Header + #0 terminated Filename)
- Setzt den Delphi 2 Byte Header
- Size -8 um 32bit CRC abzuschneiden
- Position auf Anfang des neuen Header

Bei mir geht es so. Mit einem kleinen Textfile (als gz via 7zip). Ist natürlich nicht fehlertolerant, nur zum Testen.

PS: Ich verwende TDecompressionStream etwas anders, ich hoffe Deine Variante ignoriert nicht InStream.Position.

[Bernhard Geyer]

Zitat:

Zitat von Satty67 (Beitrag 1143759)

- Setzt den Delphi 2 Byte Header

Ist kein Delphi 2 Byte Header sondern die Magic Bytes eines GZip Komprimierten Streams.

[MatthiasR]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1143756)

Zitat:

Zitat von MatthiasR (Beitrag 1143751)

Das mit den Headern muss ich mal ausprobieren, einen ähnlichen verdacht hatte ich auch schon, aber einfach nur die ersten 10 Bytes (gzip-Header) abzutrennen brachte erstmal nichts.

Äh Moment. Du willst diese Methode verwenden um ein Zip-Archiv zu entpacken. Wird nicht gehen. Die oben verwendete Funktion kann nur Streams (de)komprimieren. Bei einem GZip-Archiv gibt es noch Verwaltungsinformationen "Drum herum" um die einzelnen Datei im Archiv verwalten zu können.

Ich glaube, ich muss das nochmal etwas präzisieren...

Gegeben ist ein Byte-Array, von dem ich lediglich weiß, dass es "gzip-komprimiert" ist. Genauer kann ich es leider nicht sagen. Dieses Byte-Array schaut wie folgt aus:

Delphi-Quellcode:

RawData: array[0..447] of Byte = (
    $1F, $8B, $08, $00, $00, $00, $00, $00, $00, $00, $8D, $52, $DB, $4E, $E3, 
    $30, $10, $FD, $95, $C8, $EF, $8D, $93, $55, $5B, $DA, $AA, $31, $5A, $E8, 
    $0A, $2A, $01, $41, $ED, $72, $79, $AB, $4C, $32, $90, $08, $C7, $46, $1E, 
    $A7, $40, $BF, $97, $D7, $FD, $87, $9D, $12, $27, $DB, $AA, $AC, $C4, $4B, 
    $26, $3E, $97, $99, $63, $6B, $A6, $C7, $6F, $95, $0A, $D6, $60, $B1, $34, 
    $3A, $61, $71, $18, $B1, $00, $74, $66, $F2, $52, $3F, $25, $6C, $BE, $4C, 
    $7B, $A3, $D1, $60, $DC, $8B, $07, $2C, $40, $27, $75, $2E, $95, $D1, $90, 
    $B0, $77, $40, $76, $2C, $A6, $6B, $CC, $5F, $26, $37, $A7, $AB, $6B, $F2, 
    $1B, $D0, $AA, $CC, $0A, $B8, $DD, $F6, $A2, $6A, $1D, $90, $9C, $3E, $F7, 
    $97, $17, $01, $0D, $D1, $38, $D9, $CA, $13, $56, $38, $F7, $32, $E1, $FC, 
    $15, $C3, $27, $A8, $A4, $2B, $9F, $C3, $1C, $F8, $A3, $E4, $C4, $22, $FF, 
    $46, $33, $BE, $1E, $84, $31, $0B, $4E, $67, $97, $AB, $DB, $5F, $8B, $E5, 
    $3C, $BD, $4A, $18, $21, $94, $DC, $07, $DA, $31, $D9, $43, $48, $AF, $E6, 
    $33, $71, $1F, $C7, $51, $74, $74, $34, $1C, $F6, $A7, $FC, $4B, $41, $63, 
    $FB, $8C, $A2, $FD, $E1, $0C, $1E, $6A, $EB, $90, $62, $D4, $95, $88, $C7, 
    $C3, $7E, $D4, $FF, $31, $F2, $F6, $3D, $CE, $8F, $34, $56, $CB, $0A, $C4, 
    $8D, $B2, $65, $26, $DB, $31, $1E, $6C, $24, $57, $32, $2B, $3E, $8F, $A9, 
    $FB, $83, $E8, $3E, $1C, $0D, $EF, $9D, $58, $28, $A9, $3E, $10, $E7, $4D, 
    $9D, $AC, $CD, $81, $59, $A1, $20, $2B, $9C, $B8, $EB, $C6, $77, $50, $37, 
    $1C, $A5, $DB, $BC, $1A, $EB, $C4, $3A, $AC, $C3, $4D, $F8, $2F, $40, $47, 
    $B4, $21, $2A, $D0, $B8, $A9, $B7, $B0, $38, $91, $D6, $E8, $52, $77, $83, 
    $77, $A8, $46, $FD, $9B, $B2, $29, $71, $6D, $CD, $63, $18, $CC, $6C, $DB, 
    $B5, $41, $1B, $C5, $D2, $59, $89, $08, $FA, $67, $6E, $81, $6A, $FB, $92, 
    $06, $9D, $A2, $8B, $6D, $64, $A1, $44, $3C, $8A, $06, $63, $6F, $DD, $23, 
    $1A, $6D, $4A, $D9, $16, $04, $9B, $EC, $D9, $8B, $D2, $2E, $ED, $05, $ED, 
    $A0, $FF, $BD, $33, $85, $46, $32, $2A, $49, $BB, $01, $96, $76, $16, $C4, 
    $CC, $1B, $BE, $E2, $3C, $B5, $D3, $C1, $47, $15, $0B, $D0, $F4, $DE, $F4, 
    $C6, $4A, $01, $04, $B1, $17, $B6, $6C, $A3, $3D, $97, $35, $EA, $BA, $AA, 
    $B6, $2B, $C5, $FF, $83, $1C, $5C, $9D, $EF, $6D, $D1, $C1, $A6, $75, $C6, 
    $6F, $6C, $BD, $F8, $0B, $55, $D5, $C0, $47, $AA, $03, $00, $00
  );

Dieses Byte-Array hab ich mir mittels MemoryStream in einer "*.gz"-Datei gespeichert. Diese Datei kann ich mittels 7zip direkt dekomprimieren, sie wurde jedoch NICHT durch 7zip oder ein anderen gzip-fähiges Archivprogramm erzeugt. Es ist lediglich ein Speicherabbild des besagten Byte-Arrays. Daher kann ich auch nicht wirklich sagen, wieviele Byte nun zum Header gehören und ab wo die Rohdaten anfangen. Laut gzip-Spezifikation müssten es aber die ersten 10 Bytes sein:

Code:

Each member has the following structure:

+---+---+---+---+---+---+---+---+---+---+
|ID1|ID2|CM |FLG|     MTIME     |XFL|OS | (more-->)
+---+---+---+---+---+---+---+---+---+---+

Die ersten zwei Bytes ($1F, $8B) sind die gzip Magic Number.
Das dritte Byte ($08) signalisiert, dass deflate-Komprimierung verwendet wurde.
Darauf folgen 7 Null-Bytes ($00) und danach geht es mit den eigentlichen Rohdaten los.

@Satty67: Ich habe deine Routine zum Bearbeiten des InStreams mal ausprobiert, aber das brachte zumindest bei MEINEN Rohdaten nichts. Nach wie vor data error.

Ich habe nun jedoch entdeckt, dass die ZLibEx von http://www.base2ti.com eine spezielle "ZLibExGZ"-Unit beinhaltet, deren GZDecompressStream-Prozedur astrein funktioniert. Das Postfix "GZ" deutet ja schon darauf hin, dass die speziell auf gzip angepasst wurde. Muss mal schauen, was die intern anders machen, aber ich denke, auf die werde ich dann zurückgreifen.

[MSo]

Ich habe nach einer Lösung zum Entpacken eines GZ-Archivs gesucht und stieß auf diesen Thread.

Aus einem anderen Forum habe eine Lösung gefunden, die mit der unit zlib super funktioniert:

http://www.mombu.com/programming/pro...it-757071.html

Im Speziellen ist dabei der letzte Beitrag die Lösung.

In meinem Programm sieht die Prozedur dann so aus:

Delphi-Quellcode:

procedure unPackGZFile(aFileName: string);
var
  LInput, LOutput: TFileStream;
  LUnZip: TZDecompressionStream;
begin
  //Unpack
   { Create the Input, Output, and Decompressed streams. }
  LInput := TFileStream.Create(aFileName, fmOpenRead);
  LOutput := TFileStream.Create(ChangeFileExt(aFileName, '.xml'), fmCreate); //in meinem Beispiel ist die entp. Datei ein xml-file
  
LUnZip := TZDecompressionStream.Create(LInput,15+32); // '15+32' macht den Unterschied zwischen data-error und 'juhu'

  { Decompress data. }
  LOutput.CopyFrom(LUnZip, 0);

  { Free the streams. }
  LUnZip.Free;
  LInput.Free;
  LOutput.Free;

end;

P.S.: Verzeihung, dass ich mich wenig professionell ausdrücke, ich dachte aber, ich teile meine Entdeckung einfach mal hier, wo ich hier doch auch soviel Wissen bekomme.

[himitsu]

15+32 = 47

Nja, die ZLib ist nur für den "reinen" domprimierten Datenstream,
wärend GZip ein Dateiformat ist, welches unter Anderem noch einen Header (Zusatzdaten) enthält und dieser ist quasi zufällig 47 Byte groß.
Um nun GZip mit ZLib entpacken zu können, muß man diesen Header überspringen.

- Das kann man entweder mit einem zufällig stimmendem konstanten Index machen (was nicht immer stimmen muß),
- oder man interpretiert den Header und sucht sich dann dementsprechend die Position des Datenstroms.

Wobei man im Header noch so Dinge findet, wie den Dateinamen der gepackten Datei, einer CRC32-Checksumme, einem Timestamp/Datum
und vorallem womit wirklich gepackt wurde, denn es muß nicht immer per ZLib entpackbar sein.
www.onicos.com/staff/iz/formats/gzip.html

[MSo]

Den Header zu interpretieren scheint die ZLib als Fähigkeit schon mitzubringen.

Zitat http://www.zlib.net/manual.html

Zitat:

windowBits can also be zero to request that inflate use the window size in the zlib header of the compressed stream.

windowBits can also be –8..–15 for raw inflate. In this case, -windowBits determines the window size. inflate() will then process raw deflate data, not looking for a zlib or gzip header, not generating a check value, and not looking for any check values for comparison at the end of the stream. This is for use with other formats that use the deflate compressed data format such as zip. Those formats provide their own check values. If a custom format is developed using the raw deflate format for compressed data, it is recommended that a check value such as an adler32 or a crc32 be applied to the uncompressed data as is done in the zlib, gzip, and zip formats. For most applications, the zlib format should be used as is. Note that comments above on the use in deflateInit2() applies to the magnitude of windowBits.

windowBits can also be greater than 15 for optional gzip decoding. Add 32 to windowBits to enable zlib and gzip decoding with automatic header detection, or add 16 to decode only the gzip format (the zlib format will return a Z_DATA_ERROR). If a gzip stream is being decoded, strm->adler is a crc32 instead of an adler32.

Delphi-Quellcode:

LUnZip := TZDecompressionStream.Create(LInput,15+16);

funktioniert auch.

[himitsu]

Arg, dann hatte ich den code wohl falsch verstanden. Ich kenn Codes, wo man einfach nur den Header überspringt, also einen Offset benutzt.
Hier sind diese "WindowBits" wohl eher sowas wie Option-"Bits", aber dann wäre das "+" eigentlich falsch und es sollte besser ein "or" sein. :gruebel:

[gammatester]

Das ist das, was ich schon vor mehr als 6 Jahren geschrieben habe, und zwar nicht in dem letzen Beitrag des von Dir verlinkten Forums, sondern in dem davor (Bei der Schnickschnack-Forums-Darstellung verliert man leicht den Überblick, das Original ist in der Usenet-Group comp.lang.pascal.delphi.misc, eine mM bessere Darstellung in http://coding.derkeiler.com/Archive/.../msg00339.html).

Allerdings ist zu beachten, daß das nicht für alle zlib-Versionen gilt, sondern erst ab 1.2.x, viele Libraries verwenden noch 1.1.14.

Gruß Gammatester

[MSo]

Zitat:

Zitat von himitsu (Beitrag 1182874)

Arg, dann hatte ich den code wohl falsch verstanden. Ich kenn Codes, wo man einfach nur den Header überspringt, also einen Offset benutzt.
Hier sind diese "WindowBits" wohl eher sowas wie Option-"Bits", aber dann wäre das "+" eigentlich falsch und es sollte besser ein "or" sein. :gruebel:

Ich glaube das + ist wirklich ein + und als solches zu verstehen.

Anstelle von

Delphi-Quellcode:

LUnZip := TZDecompressionStream.Create(LInput,15+16);

geht ebenso

Delphi-Quellcode:

LUnZip := TZDecompressionStream.Create(LInput,31);

In der "Plus-Schreibweise" kann man später vielleicht einfach besser nachvollziehen, was man da addiert hat und warum.