XE2: gzip-Datei mittels System.ZLib dekomprimieren

[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 von 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...

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!

[Bernhard Geyer]

Zitat von Satty67:

€: 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).

[MatthiasR]

Zitat von Bernhard Geyer:

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 von MatthiasR:

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 von Satty67:

- Setzt den Delphi 2 Byte Header

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