zlib解凍に失敗する

Question

私は別のアプリケーションで圧縮されたデータを解凍する必要があるアプリケーションを作成しています（これは私のコントロール外です - ソースコードを変更することはできません）。プロデューサアプリケーションは、zlibを使用してz_streamメカニズムを使用してデータを圧縮します。それはZ_FULL_FLUSHを頻繁に使用します（おそらくあまりにも頻繁に、私の意見では、別の問題です）。このサードパーティのアプリケーションでは、独自のデータを解凍することもできるため、データそのものが正しいと確信しています。私のテストで

、私は（16進数）は、次の単純なテキストファイルを圧縮するために、このサードパーティのアプリを使用しています：

48 65 6c 6c 6f 20 57 6f 72 6c 64 21 0d 0a

を私はアプリから受け取った圧縮バイトは、（再び、このようになります、16進数）：

：私は、同じデータを試してみて、圧縮した場合

78 9c f2 48 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 00 00 00 ff ff

、私は非常によく似た結果が得られます0

78 9c f3 48 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 00 24 e9 04 55

私が見ることができる2つの違いがあります。

まず、4番目のバイトではなくF3よりも、F2ので、デフレート「最後のブロック」ビットが設定されていません。これは、ストリームインターフェイスが着信データの終わりを知ることがないので、そのビットを決して設定しないと仮定します。

最後に、外部データの最後の4バイトは00 00 FF FFですが、私のテストデータでは24 E9 04 55です。私の周りに検索することは、これは同期またはフルフラッシュの署名であることを...このページに

http://www.bolet.org/~pornin/deflate-flush.html

を見つけました。

decompress()機能を使用して自分のデータを解凍しようとすると、すべて正常に動作します。しかし、外部データを試して解凍すると、decompress()ファンクションコールは、壊れたデータを示すZ_DATA_ERRORの戻りコードで失敗します。

私はいくつかの質問があります：

1. 私はz_stream方式で圧縮されたデータを解凍するためにzlibの「解凍」機能を使用することができるはずですが？

2. 上記の例では、最後の4バイトの意味は何ですか？外部圧縮データストリームと私自身のテストデータストリームの長さが同じであれば、最後の4バイトは何を表していますか？

乾杯

Answer 1

のzlibの作者のおかげで、私は答えを発見しました。CA 49 51 E4、E5 02 00 00 00 FF FFの

2F

78 9C F2 48 CD C9 C9 57 08 CFを：サードパーティ製のアプリが正常に終了していないzlibのストリームを生成していますこれは、部分的なzlibストリームです。 は、zlibヘッダーと部分的に収縮するストリームの部分から構成されます（ ）。 2つの ブロックがあり、どちらも最後の ブロックではありません。 2番目のブロックは空の 格納されたブロックで、 のフラッシュ時にマーカーとして使用されます。 zlibデコーダは、そこにあるものを が正しくデコードすると、 の後にデータを探し続けます。 CA 49完全ZLIBストリーム、ZLIBヘッダからなる 、単一で51 E4 E5 02 00 24 E9 04 55

2F

78 9C F3 48 CD C9 C9 57 08 CF最後のブロックとしてマークされたブロック と、 zlibの予告編です。予告編は、圧縮されていない データの Adler-32チェックサムです。

私の解凍が失敗しています - おそらくCRCがないか、解凍コードが存在しないデータを探し続けている可能性があります。

Answer 2

溶液はここにある： http://technology.amis.nl/2010/03/13/utl_compress-gzip-and-zlib/

これは78（c）署名 圧縮データベースブロブ（またはストリーム）で開始するための解凍および圧縮機能です。