
2026/02/27 16:39
**Gzpeek** *gzipメタデータを解析するツール*
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Summary:
Gzipファイルには、圧縮データだけでなく、オペレーティングシステムフラグ、修正時間(MTIME)、テキストファイルインジケーター(FTEXT)、圧縮レベルヒント(XFL)、元のファイル名、コメント、および任意の追加データなど、複数のメタデータフィールドが含まれています。これらのフィールドは、ファイル作成時に使用された環境や設定について手掛かりを与えることがありますが、その値はしばしばデフォルトに設定されます—多くのライブラリではOSに「unknown」または「Unix」を、MTIMEにはゼロを書き込みます。仕様ではタイムスタンプを1970年から2106年までに制限しており、将来的に問題になる可能性があります。zlib、.NET、Ruby、PHP、Java、JavaScript、Go、Zopfli、Apacheなどの異なるプログラミング言語やツールは、これらのヘッダー フィールドを一貫せずに扱います。一部は完全に無視し、他のものはさまざまな情報で埋め込みます。このような変動性のため、gzipメタデータに依存して起源や圧縮レベルを判断することは信頼できません。クロスプラットフォームツールを構築したり gzip ファイルを検証したりする開発者は、これらの不一致を認識し、ヘッダー フィールドを無視するか明示的に処理するようなソリューションを設計する必要があります。
Summary Skeleton
What the text is mainly trying to say (main message)
Gzipファイルは圧縮データだけでなく、作成時の環境や圧縮設定について情報を示す複数のメタデータフィールドを持つヘッダーを含むこと。
Evidence / reasoning (why this is said)
ヘッダーにはOSフラグ、MTIME、FTEXT、XFL、元ファイル名、コメント、および任意の追加フィールドが含まれ、それぞれの目的と典型的な値が記述されている。さまざまなライブラリがそれらを設定するか無視するかはテストで確認できる。
Related cases / background (context, past events, surrounding info)
zlib、.NET、Ruby、PHP、Java、JS、Go、Zopfli、Apache などの異なる言語とツールがこれらのフィールドを一貫していない。仕様でもタイムスタンプを1970〜2106年に制限しているため、将来のフォーマットで問題になる可能性がある。
What may happen next (future developments / projections written in the text)
MTIME の有限時間範囲は今後の潜在的な問題として指摘され、新しい圧縮形式ではより広いタイムスタンプサポートや異なるメタデータ処理が必要になる可能性を示唆している。
What impacts this could have (users / companies / industry)
メタデータはソースシステムと圧縮レベルのヒントになるものの、その信頼性が低いため、ユーザーやソフトウェアは正確な起源を保証できない。開発者はクロスプラットフォームツールを構築したり gzip ファイルを検証したりする際にこれらの不一致を考慮しなければならない。
本文
簡潔に言うと:
Gzip のストリームには、圧縮を行ったオペレーティング・システムなどのメタデータが含まれています。私はこのメタデータを読むためのツール ―
gzpeek を作りました。
ファイルフォーマット仕様を読んでいると、いつも小さな驚きが隠れているものです。
Gzip は「圧縮専用」だと思い込んでいたので、数バイトの管理情報、圧縮データ、そしておそらくチェックサムだけがあると考えていました。しかし仕様書を見るとヘッダーにもっと多くの項目があることがわかります。
| フィールド | 説明 |
|---|---|
| OS バイト | 圧縮を行った OS を識別します(0 = Windows、1 = Amiga、3 = Unix など)。多くの圧縮ツールはこの値を異なる方法で設定しています。zlib はホスト OS に基づいて設定し、.NET の 、Ruby の 、PHP の 、Java の 、JavaScript の 、Go の などは「unknown」(255)を使用します。Zopfli と Apache の は「Unix」をハードコードしています。実際にはこのフラグだけで元の OS を判断できるわけではありませんが、手掛かりになることがあります。 |
| MTIME | データの変更時刻または圧縮開始時刻です。符号なし 32 ビット Unix タイムスタンプ(1970‑01‑01〜2106‑02‑07)で保存されます。多くの実装では 0 に設定しますが、他には現在時刻やファイルの変更時刻を使用するものもあります( はこれです)。 |
| FTEXT | データが「おそらく ASCII テキスト」であることを示すブールフラグです。仕様書ではこのフラグを設定するアルゴリズムは明確にされていません。私のテストでは 0 以外を設定したものはありませんでした。 |
| XFL | 圧縮レベルを示す追加フラグです:2 = 最大圧縮()、4 = 高速、0 = その他。zlib や多くのツールは正しく設定しますが、一部は 0 をハードコードしています。この値は解凍時には使用されないため、実質的に重要ではありません。 |
| 元ファイル名 | のように実行した場合、ヘッダーに が格納されます。このオプションフィールドは省略されることが多いですが、 は を指定しない限り含めます。 |
| コメント | 任意のコメントフィールドで、ほとんど使われず解凍ツールでも無視されることが一般的です。 |
| 任意の拡張データ | さらにメタデータが必要な場合はサブフィールドを埋め込むことができます。各サブフィールドは 2 バイトの識別子と、0 バイト以上の情報で構成されます。 |
思ったよりも多くの情報が隠れていました!このメタデータに興味を持って
gzpeek を作りました。このコマンドラインツールは Gzip ストリームを調べて以下のような出力をします。
$ gzpeek my_file.gz # FTEXT: 0 # MTIME: 1591676406 # XFL: 2 # OS: 3 (Unix) # NAME: my_file.txt
gzpeek は上記すべてのフィールド(OS、元ファイル名、変更時刻など)を抽出します。さまざまな Gzip 実装を調査する際に頻繁に使用しました。
ぜひお試しください。そして、Gzip のメタデータで見つけた興味深い情報があれば教えていただけると嬉しいです!