gzip

ヘッダー・DEFLATEデータ・CRC32・元大きさで一つのメンバーを作る複数メンバーは完全な単位のまま前後へ連結できる

一つのメンバーを構成する部分

DEFLATEそのものではない

DEFLATE（デフレート）は圧縮データのビット列形式です。gzipはその周囲へヘッダーと末尾情報を付けます。zlib形式もDEFLATEを包みますが、ヘッダーとチェックサムが異なります。

HTTPで歴史的にdeflateと書かれたデータはzlibラッパーを指す規則です。生のDEFLATE、zlib、gzipを拡張子や「同じ圧縮方式」という理由で交換しません。

連結メンバー

gzipファイルはメンバーを前後へそのまま連結できます。対応展開器は順に展開し、出力を連結します。単に二つの.gzをバイト連結しても有効なgzipストリームになる性質です。

ただし各メンバーにファイルディレクトリーや階層の索引はありません。「複数メンバー」と「複数ファイルを名前付きで取り出せる保管」は別です。ツールが連結メンバーをすべて読むかも確認します。

.gzは通常一つのストリームを圧縮する

report.csv.gzはCSVストリームをgzipで包んだ形です。元のファイル名をヘッダーへ入れられますが、ディレクトリー構造、権限、複数ファイル一覧を管理する目的ではありません。

.tar.gzまたは.tgzは、tar保管をgzip圧縮したものです。展開はgzipを外してtarを読み、二つの形式を順に処理します。

HTTPのgzipコンテンツ符号化

ブラウザーはAccept-Encodingへgzip対応を示し、サーバーが選べば応答へContent-Encoding: gzipを付けます。Content-Type: text/html等は展開後の本文形式を示したままです。

HTTP 本文はgzip形式に近いメンバーで運ばれ、クライアントが展開してからHTML等として解釈します。保存ファイルの元名や更新時刻を配るためではなく、表現の転送表現として使います。

CRC32とISIZEの限界

展開器はCRC32を再計算し、末尾情報と比較して破損を検出できます。しかし攻撃者がデータとCRCを両方作り直せるため、真正性は保証しません。信頼が必要なら暗号学的ハッシュを認証済み経路で配るか、署名・MACを使います。

ISIZEは32ビットで一周するため、巨大メンバーの完全な大きさを単独では表せません。展開前の容量予約に盲信せず、実際の出力へ上限を設けます。

再現可能なビルドとランダムアクセス

ヘッダーに元ファイル名や更新時刻を入れると、同じ内容でも生成時刻によってgzipバイト列とハッシュが変わります。再現可能な生成物が必要ならメタデータを固定・省略できるツール選択肢を使います。

通常のgzipストリームは途中から独立して展開しにくく、後半だけ読むにも先行状態が必要です。巨大ログの部分参照には、メンバー分割、外部索引、独立チャンク等を設計します。

gzipはDEFLATEデータをヘッダー・CRC32・ISIZEで包むメンバー形式です。.gzと保管、gzip・zlib・生のDEFLATE、HTTPコンテンツ符号化と保存ファイルを区別します。

gzip member・header・trailer・CRC32・ISIZE：RFC 1952／HTTP gzip content coding：RFC 9110