ZIP を XZ に変換

圧縮の時間は 1 台の機械が 1 回だけ払うコストです。転送は取得する人全員が毎回払うコストで、従量課金のバケットや CDN では時間だけでなくお金でも払います。この非対称こそが XZ を選ぶ理由のすべてで、ソースリリースやパッケージのダウンロードで標準になった理由でもあります。

これは、いつ手間をかけるべきでないかも教えてくれます。同僚が 1 回だけ開くアーカイブには、最適化すべき経済性がありません。圧縮に費やす数秒が、そのファイルの一生で唯一かかる時間で、gzip ならとっくに終わっています。ファイルに閲覧者やミラー、CDN の請求、長い保存期間があるときこそ XZ を使い、受け取り手が 1 人だけならそのままにしてください。ディストリビューションが何年も前にパッケージアーカイブを xz に切り替えた理由も、11 分だけ生きるビルド成果物をわざわざ圧縮しない理由も、同じ論理です。

XZ はアーカイブ形式ではなく圧縮方式です。単一メンバーのストリーム形式で、ディレクトリ構造を持たないことが弱点として記録されています。.xz ファイルには名前もパスも権限ビットも入る場所がありません。

そのため ZIP の中身はまず TAR にまとめられ、その TAR を XZ が 1 つのまとまりとして圧縮します。これはこの変換機のために考え出された回避策ではなく、Unix 全体が使ってきた組み合わせです。どのソースリリースの拡張子も素の .xz ではなく .tar.xz になっているのはそのためです。2 つの層はそれぞれ独立した役割を担っており、あとで圧縮方式を xz から別のものに変えても TAR の中身には何の影響もありません。アーカイブの構造は、いま決めてしまう必要のある選択ではないということです。

この数字がすべてを物語ります。ZIP も gzip も使う DEFLATE は、直近 32 KB の範囲内で繰り返しを参照します。XZ の LZMA2 は最大 64 MB 遡って参照でき、これは 2000 倍の距離です。しかも DEFLATE のハフマン符号より少ないビット数で済むレンジコーダーで符号化します。

これが効くのは、繰り返しが散らばっているアーカイブです。同じライセンスヘッダーが 200 個のファイルの冒頭にあるソースツリー、似た CSV の書き出しを集めたデータセット、1 つのテンプレートから作られた文書のフォルダー。逆にもっとも効かないのは、写真や動画を含む ZIP です。中身はアーカイブされる前にすでに圧縮されていて、長い窓を持っても見つけるものが残っていないからです。

大きな辞書は展開する側にとってタダではありません。展開ツールは参照を解決するためにその窓をメモリーに保持しておく必要があるので、必要なメモリーはファイル自体の大きさより、圧縮時の辞書設定に近い量になります。

デスクトップやサーバーではまったく問題になりません。ルーターやマイクロコントローラー級のボード、制約のあるビルドエージェントといった小型のハードウェアでは無視できなくなり、そこでは gzip の控えめな 32 KB の窓が制約ではなく利点になります。アーカイブの行き先が小型の機器だとわかっているなら、.tar.gz も一緒に公開しておく理由になります。

両者は同じ圧縮方式を使い、辞書も最大 64 MB で同じなので、圧縮率にはほとんど差がありません。違うのは圧縮データの周りにあるものです。7Z はエントリーの目次や独自の暗号化、独自のチェックサムを持つコンテナーです。XZ は 1 本のストリームを包む圧縮方式にすぎません。

配布用には慣習の面でストリームのほうが有利です。Linux や macOS には tar と xz がほぼ必ず入っていますが、7-Zip が標準で入っている機械はほとんどありません。保管して閲覧するためのアーカイブなら 7Z のほうが向いています。2 つの層を外さなくても一覧を見て 1 ファイルだけ取り出せるからです。圧縮方式は同じでも、使い勝手はまったく逆です。

どちらの形式も自己検証を持ちます。ZIP はエントリーごとに CRC を持つので、壊れたメンバーは展開時に検出されます。XZ は書かれ方に応じて CRC-32、CRC-64、SHA-256 のいずれかで圧縮ストリーム全体を検査し、一致しないデータは渡しません。

違うのは検証の粒度です。ZIP では検査がファイル単位なので、1 個の壊れたエントリーは 1 個の壊れたファイルで済みます。.xz ではストリーム単位なので、損傷はアーカイブ全体の問題として報告され、その中の tar が損傷箇所より先を回復できないこともあります。公開するものなら、ダウンロードに添える外部のチェックサムファイルは、それでもわずか数行の価値があります。

gzip ストリームは元のファイル名を記録できますが、XZ ストリームには相当するものがありません。検査方式とフィルターを記述するヘッダーだけの圧縮方式で、名前やタイムスタンプを置く場所はどこにもありません。

つまりファイルを説明する責任は、付けた名前がすべて背負うことになります。ダウンロードは元のファイル名の本体部分に目的の拡張子を付けて返されるので、release-1.4.zip は release-1.4.xz として返ってきます。公開する前に release-1.4.tar.xz にリネームしておくかどうかが、見てすぐわかるダウンロードと、中身を探らないといけないダウンロードの分かれ目です。変換後にできるもっとも有効な一手です。

この変換はブラウザーの中ではなく変換機側で動きます。ZIP は暗号化された通信でアップロードされ、7-Zip で展開されたあと tar 化・xz 圧縮されて返送されます。アップロード、中間生成物、出力結果は、ジョブが終わるとすべて削除されます。作業領域はメモリー上にあり、使い終わったコンテナーごと消えます。

結果として、無料枠は 1 ファイルあたり 25 MB、処理時間は 60 秒まで、展開後 2 GB を超えると宣言されたアーカイブは拒否され、パスワード保護された ZIP は固まるのではなくきちんと失敗します。アーカイブが本当に機密性の高いものなら、xz-utils と 7-Zip はどちらも自分の機械でオフラインに同じ作業ができます。

ここをきちんとやっているプロジェクトは 2 つのファイルを配布します。.tar.xz はシェルやスクリプトで展開する人向けで、小さいダウンロードが実際の帯域の節約になり、ツールは OS が入った時点からすでにそろっています。ZIP は Windows でダブルクリックして中身を見たいだけで、圧縮アルゴリズムのことなど考えたくない人のために残しておきます。どちらも同じツリーから作られていて、どちらも妥協ではありません。

これは優柔不断ではなく、制約がまったく違う 2 つの層への配慮です。片方だけでは、もう片方を不利にせずに済ますことができません。成果物を 1 個しか出さないなら、実際にダウンロードする人が開けるほうを出してください。誰も展開できない見事な圧縮率のアーカイブは、圧縮率の優れたサポートチケットにすぎず、節約したバイト数は「.tar.xz とは何ですか」という問い合わせに何倍にもなって跳ね返ってきます。

ZIP がビルドの一部で再現性が求められるなら、再パッケージが中立な操作ではないことに注意してください。中身のバイトは正確に保たれますが、それを包むアーカイブ自体は新しく書かれるので、エントリーの順序やタイムスタンプ、圧縮方式自体の選択は、アップロードしたアーカイブではなく、パッケージ作業を行った機械に由来します。同じ ZIP を 2 回変換すると、どちらも正しいのに結果が異なることがあります。

これが問題になるのは、中身ではなくアーカイブ自体をチェックサムしている場合だけです。ダウンロードと一緒にハッシュを公開するリリースパイプラインは、そのハッシュを実際に配布するファイルから、最終的な再パッケージのあとに生成するべきで、以前の成果物から使い回してはいけません。実行ごとにバイト単位で同一の出力が必須なら、それは Web 上の変換機ではなく、圧縮設定を自分で固定できるローカルの決め打ちツールチェーンの中で解決すべき要件です。