TAR を GZ に変換

無圧縮の TAR は gzip 済みのものより珍しく、出どころも見分けがつきます。docker save が書き出すもの、圧縮を指示されずにまとめるだけ指示されたバックアップスクリプト、圧縮を別の段階で行う NAS やテープの運用、そして tar cf と tar czf の違いは一文字だけなのに片方しかファイルを小さくしないため、うっかりできてしまうもの。

できあがるのは、中身の合計に驚くほどのオーバーヘッドを足しただけのアーカイブです。ローカルディスクに置くだけなら問題ありませんが、それ以外の場面では代償を伴います。回線の遅いアップロード、ギガバイト単位で課金されるバケット、メールの添付上限、毎回のビルドで取得される CI キャッシュ。このサイトの再パッケージ変換のなかでも、ほぼ確実に「やるべき」と言えるのがこの組み合わせです。互換性上の代償がなく、.tar.gz は素の .tar よりずっと広く理解されているからです。

TAR の構造は 1979 年のもので、単純そのものです。ファイルを説明する 512 バイトのヘッダー、続いて 512 バイトの倍数まで詰め物された中身、次のヘッダー、そして末尾に終わりを示す 2 つのゼロブロック。何も圧縮されず、何も索引されません。テープドライブ向けに設計され、固定サイズのブロックがまさに目的でした。

そのコストは小さいファイルで表面化します。1 バイトのファイルは TAR の中で 1,024 バイトを占めます。ヘッダーブロックとデータブロックがまるまる 1 つずつ必要だからです。数百バイト程度の設定ファイルやソースファイル、JSON 文書が 1 万個あれば、何の情報も持たないヘッダーと詰め物だけで数メガバイトになります。gzip はまさにこれが得意で、ゼロの連続はほとんど何もないところまで縮みます。小さいファイルが多いアーカイブの節約分は、中身の圧縮よりオーバーヘッドの除去によるところが大きいのです。

gzip は 32 KB の履歴窓を持つ DEFLATE を使います。この数字がこの変換のすべてを決めます。32 KB の範囲内であれば繰り返した文字列を参照に置き換え、残りをハフマン符号化します。文章やコード、ログ、XML、JSON、設定ファイルではこれが大きく確実な節約になります。

見逃すのは長距離の繰り返しです。同じライセンスヘッダーが 40 MB の tarball に散らばる 200 個のファイルに現れても、gzip は 2 つを同時に見ることができないので 200 回別々に圧縮します。これが XZ や 7Z が埋めようとしている隙間で、似たファイルが多いアーカイブでは両者が gzip を大きく上回る理由です。gzip の強みは速さとストリーミング性、そしてほぼすべての機械に入っていることです。保管より移動が目的のファイルには、こちらのほうが有利な取引になることが多いです。

これは、既存のファイルにそのまま包みが付くと思っている人には意外に映るので、はっきり書いておく価値があります。この変換はアップロードされた TAR を展開したあと、取り出した中身から新しい TAR を作り、それを gzip で圧縮します。中のファイルは 1 バイトも変わりませんが、それを包む tarball 自体は新しく作られたものです。

これには 2 つの帰結があります。まず、元の TAR に対して計算されたチェックサムはここでは何とも一致しません。手元にあるのはもう元の TAR ではないからです。ハッシュを検証する必要があるなら、自分の機械で gzip コマンドを使ってください。tarball 自体には手を触れずに済みます。次に、元のコンテナーが記録していた情報が変わる可能性があります。このペアのレジストリの注記もそのとおりで、リスクがあるのは権限とタイムスタンプです。ソースの束や文書アーカイブなら問題になりませんが、デプロイの成果物なら話が違います。

gzip ストリームは元のファイル名を持つヘッダーフィールドを持っています。Unix 機で gunzip backup.gz を実行すると、コマンドに何も書いていなくても backup.tar が返ってくるのはこのためです。形式が持つちょっとした親切であり、名前をまったく保存しない xz や bzip2 と比べて gzip のファイルがやや匿名性の低い理由でもあります。

重要な用途では頼らないでください。多くのツールがそのフィールドに汎用的な名前を書き込み、多くのツールが展開時にそれを無視します。アーカイブを書き換えるシステムを経由すれば完全に消えることもあります。実際に読まれるラベルはダウンロードに付けた拡張子です。.gz ではなく .tar.gz にして、受け取った人が謎のファイルを解きほぐす手間を省いてください。

gzip ストリームは固定 32 KB の窓で先頭から末尾へ復号され、索引を持ちません。これは制約に聞こえますが、実は最大の強みの源です。届く端から消費できるということだからです。curl https://… | tar xzf - はディスクに一切触れずダウンロードを展開しますし、バックアップはそのまま gzip に流し込んでリモートホストへ送れますし、ログ収集システムはデータ量を知らないままその場で圧縮できます。

これはレジストリでも形式自体の特性として明記されています。20 年にわたって、これより強力な方式に置き換えられずに済んだ理由です。大きな辞書を使う形式はそれに比例したメモリーを必要とし、末尾に目次を持つ形式は先頭を一覧する前にファイルの末尾が必要です。tarball をパイプで流したり、HTTP で配信したり、小さな機器で展開したりするなら、gzip は妥協ではなく正しい選択です。

3 つに優劣があるわけではなく、同じ曲線上の異なる点に位置しています。gzip は圧縮も展開も最速で、節約幅は最小です。XZ はテキストで圧倒的に大きく縮みますが、圧縮時間と展開に必要なメモリーの代償が大きいです。BZ2 は圧縮率ではその中間にありながら展開が遅く、レジストリではレガシー扱いです。

判断はファイルがこのあとどう使われるかで決めてください。あなたが管理していない機械から、パイプ経由で繰り返し取得・展開されるなら gzip。何年も寒冷保管され、ほとんど読まれないなら XZ。ビルドシステムがすでに期待している成果物名に合わせる必要があるなら、その名前が指定するもので、理由を考える必要はありません。tarball の変換は安く済むので、両方試してサイズを比べるのも十分に現実的な決め方です。

ブラウザーの中ではありません。このサイトの多くのツールは端末側でファイルを処理しますが、アーカイブの再構築は 7-Zip と gzip という本物のプログラムを必要とする例外です。ファイルは暗号化された通信でコンテナーへ送られ、そのコンテナーは自前の外向きインターネット接続を持ちません。

ジョブごとにメモリー上の一時領域が割り当てられ、成否にかかわらずジョブ終了時に削除されます。60 秒を超えて動いているものは、力尽きるまで待たれるのではなく強制終了されます。無料枠は 1 ファイルあたり 25 MB で、このペアはその上限がもっとも厳しく効く組み合わせです。TAR は無圧縮なので、25 MB の TAR は 25 MB の実データそのものであり、25 MB の 7Z がその 10 倍の中身を持つこともあるのとは対照的です。

tar xzf archive.tar.gz は macOS、Linux、BSD で両方の層を 1 回で処理し、最近の Windows も PowerShell やコマンドプロンプトから同じことができる tar を備えています。Windows のグラフィカルなアーカイバーの多くは gzip の層だけを外して .tar を残すので、単一の入れ物で済む形式を探す人が出てくるのはこのためです。

元のファイルを消す前に、一覧を比較してください。結果に対する tar tzf と、元のファイルに対する tar tf で、件数とパスが一致するかを見ます。特に注意すべきはトップレベルです。あるディレクトリの中から作られたアーカイブと、その親から作られたアーカイブでは、すべてのエントリーの先頭フォルダーが 1 つずれ、その違いは何ヶ月も経ってから誰も覚えていない理由でスクリプトを壊します。2 つの一覧が一致したら、無圧縮の TAR にはもう役目がありません。