gzip(.gz)インスペクター

使い方

1. .gz、.tgz、その他の gzip ストリームを枠にドロップします。解析も展開もページ内で行い、アップロードはしません。
2. まず概要を見ます。ファイルに実際いくつメンバーがあるか、本当の展開後合計、そして CRC32 がすべて一致したかがわかります。
3. メンバーを開いてヘッダーを確認します。5 つのフラグビット、MTIME、XFL、OS バイト、保存されたファイル名、コメント、FEXTRA サブフィールドが並びます。
4. トレーラーの 2 組を比べます。トレーラーの CRC32 とデータの実際の CRC32、ISIZE と実際の展開後サイズです。両方一致することが、まさに gzip -t の検査内容です。
5. 複数メンバーのファイルでは、gzip -l の数値を引用する前に、その値と実際の合計との差を確認してください。

よくある質問

gzip -l がこのページと違うサイズを表示するのはなぜですか。

gzip -l は展開を一切行わないからです。ファイル末尾の 4 バイトへシークし、その ISIZE を読んで展開後サイズとして表示します。メンバーが 1 個なら正しい値です。ところがメンバーを連結して作ったファイル（cat a.gz b.gz、アーカイブに追記したログ、独立ブロックを書く pigz や bgzip）では、その 4 バイトは最後のメンバーしか説明しないため、それ以前のメンバーの分がまるごと欠けます。このページは代わりに全メンバーを展開し、実際に出てきたバイト数を合計するので、はるかに大きな値になることがあります。その代わり gzip -l は一瞬で終わり、このページはそうではありません。正直な答えの代金が展開時間です。

MTIME が 0 とはどういう意味で、この値はいつの時刻ですか。

MTIME は元ファイルの更新時刻を UTC の Unix エポック秒で保持します。圧縮を実行した時刻でも、ディスク上の .gz のタイムスタンプでもありません。0 は時刻が得られなかったか、保存しなかったという意味です。gzip -n は意図的に 0 を書き、再現可能ビルドも同じことをします。同じ内容をビルドしてもバイトが変わる典型的な原因がタイムスタンプだからです。パイプから圧縮した場合も、時刻を取る元ファイルがないので 0 になります。項目は 4 バイトなので 2106 年より後は表現できず、2^31 を超える値を遠い未来と見るか負の値と見るかは実装によって異なります。

元のファイル名が文字化けして見えます。ファイルが壊れているのですか。

壊れているのは仕様のほうです。RFC 1952 は FNAME を ISO-8859-1 の文字列と定めていますが、Linux や macOS の gzip はロケールが生成した名前のバイト列をそのまま書きます。今日ではたいてい UTF-8 です。そのため ASCII 以外の名前は、同じエンコーディングを使うシステム間でしか正しく往復しません。UTF-8 で書いた名前を Latin-1 として読むと、おなじみの崩れた文字が出てきます。このページは仕様どおりにデコードした値を示し、同じバイト列が有効な UTF-8 でもあり別の読みになる場合は、その UTF-8 読みを並べて表示します。両方の候補を見て、書き手の意図した名前を判断できます。

CRC32 の不一致は何を証明し、一致は何を証明しないのですか。

不一致は、deflate ストリームから出てきたバイトが、書き込み時に入ったバイトと違うことを意味します。保存中に反転したビット、途中で切れて継ぎ足された転送、圧縮データへの改変などです。gunzip が「invalid compressed data — crc error」と報告するのと同じ失敗で、ただしここでは出力をどこにも書かずに確認できます。一方、一致が証明するのはデータが圧縮器の見たものと同じだということだけです。CRC32 は 32 ビットの誤り検出符号であって署名ではありません。偶発的な破損は非常に高い確率で捕まえますが、データを書き換えられる者は CRC も計算し直せます。真正性の確認には、トレーラーではなくファイル全体に対するハッシュや署名が必要です。

.tar.gz の中のファイル一覧は見られますか。

見られませんし、gzip だけを読むツールでは不可能です。gzip は 1 本のバイトストリームを圧縮するだけで、その中身を知りません。目次もファイルごとのエントリーもなく、前を全部展開せずに 1 ファイルだけ取り出す方法もありません。.tar.gz は、そうした構造を持つ tar アーカイブをまとめて gzip に通したものです。このページが伝えられるのは gzip 層が記録した内容だけです。メンバーがいくつあるか、各ヘッダーの元ファイル名（多くは archive.tar）、タイムスタンプ、そして出てくるデータ量です。エントリーを一覧するには、展開後のストリームを読む tar リーダーが必要です。

FEXTRA サブフィールドは何に使われますか。

FEXTRA は拡張点です。長さが前置されたサブフィールドの並びで、各サブフィールドは 2 バイトの ID と自分の長さ、ペイロードから成り、ID を知らないリーダーは読み飛ばさなければなりません。実際の用途はほとんどが gzip ストリームをシーク可能にすることです。bgzip とゲノミクスのあらゆる BAM ファイルの土台である BGZF は「BC」サブフィールドに各ブロックのサイズを書き、ブロック境界へ直接跳べるようにします。dictzip も同じ理由で「RA」の下にチャンク長の表を置きます。どちらも gunzip が普通に読める通常の gzip ファイルのままであり、それがこの仕組みの要点です。見慣れないサブフィールドがあれば、そうしたツールが書いたファイルだという手がかりになります。

関連ツール