これを行う方法があると思いますが、方法がわかりませんか？基本的に、圧縮データを解凍しようとすると、crc エラーが発生する圧縮プログラムを作成していました。通常、これはデコンプレッサが実際に私のデータが正しい形式であると認識して解凍したことを意味しますが、結果を CRC によって示される予想される長さと比較すると、それらは同じではありませんでした。
ただし、比較の理由から、実際に出力を確認して、それが単なる連結の問題であるかどうかを確認したいと思います (解凍された出力が意味不明ではなく、単に間違った順序である場合、比較的明白なはずです)。
「解凍」と言いましたが、質問には「gzip」と書かれています。それはどれですか？これらは、2 つの異なるフォーマットで動作する 2 つの異なるプログラムです。gzip と仮定します。また、長さは「CRC で示される」ものではありません。gzip トレーラーには、CRC と圧縮されていない長さ (モジュロ 2 32 ) が含まれていますが、これらは 2 つの異なるものです。
このgzipコマンドは、有効な deflate データをすべて解凍し、crc をチェックする前に書き出します。したがって、たとえば、.gzファイルを取得して、最後の crc (または長さ) だけを破損した場合は、次のようにします。
gzip -dc < corrupt.gz > result
結果は、圧縮されていない正しいデータ ストリーム全体になります。gzipを変更して再コンパイルしたり、独自の ungzipper を作成したりする必要はありません。gzip は crc について文句を言いますが、それでもすべてのデータが書き込まれます。
As far as I'm aware, the CRC check is part of the GZIP wrapper, not part of the actual compressed data in DEFLATE format.
So you should be able to take literally just the bytes that are the compressed data stream, ignoring the GZIP header and CRC at the end, and pass it through an Inflater.
In other words, you need to take just the bytes corresponding to those referred to as "compressed blocks" in the GZIP File format specification and try to decompress using a Java Inflater object. A little bit of work but possibly less than re-compiling the GZIP code as Greg suggests (though his option would also work in principle).