GZ を XZ に変換

これから開くファイルを圧縮し直す人はいません。ここに来る人が見ているのは、すでに積み上がったもの——1 年分のローテーションされたログ、監査のために保管しているデータベースのダンプ、四半期に一度しか読まない研究データセット、誰も消していない CI の成果物です。gzip は書き出した当時は正しい選択でした。速く、どこにでもあり、ログローテーションの設定にすでに組み込まれていたからです。ですがファイルの後半生には向いていません。

gzip は書く瞬間と読む瞬間に最適化され、XZ はその間の何年もの期間に最適化されています。あわてて誰かが展開する予定があるなら、あるいはメモリーの少ない機器で開くなら、そのままにしておいてください。ほとんど読まれずに寒冷保管される予定なら、この変換はほぼタダで得をする話で、1 ファイルずつではなくフォルダーごとやる価値があります。

1996 年に RFC 1952 として標準化された gzip は、DEFLATE を使い履歴窓は 32 KB です。100 万バイト目を圧縮しているとき、96 万 8000 バイト目までしか遡れません。それより前に出た繰り返しは、初めて見たかのようにまた圧縮されます。2009 年生まれの XZ は最大 64 MB の辞書を持ち、2000 倍遠くまで見渡せます。

この差が、ある入力では劇的に効き、別の入力ではまったく効かない理由です。1 年分のログは同じ 40 種類程度のメッセージテンプレートを何ギガバイトも繰り返し、gzip はそれを何千回も再発見しますが、XZ は 1 回学べば済みます。SQL のダンプは行ごとに列名を繰り返します。ソースツリーはライセンスヘッダーやインポート文、定型コードを何百ファイルにもわたって繰り返します。一方、写真や動画が入った GZ には長距離の繰り返しがありません。JPEG や H.264 が gzip に渡す前にすでに冗長性を取り除いているためで、どれほど強力な圧縮機でも存在しない構造は作れません。

圧縮時間はわかりやすいコストですが、いちばん重要ではありません。あなたを待たせずに 1 回だけ払われるコストだからです。XZ は同じ作業でも gzip よりはるかに遅く、辞書が 2000 倍大きいことの直接の結果です。夜間バッチで一括圧縮するような用途なら、最適化する価値のある問題ではありません。

実際に効いてくるのは展開時のメモリーです。gzip は展開に 32 KB あれば足り、実質ゼロに等しいのに対し、XZ は圧縮時の辞書サイズに応じたバッファーが必要です。ノートパソコンやサーバーでは何も問題になりません。ルーターや小型組み込み機器、メモリー制限のあるコンテナー、制約の厳しいビルドエージェントでは、アーカイブが開けるかプロセスが強制終了されるかの分かれ目になります。展開する機械のほうを確認してください。圧縮する機械ではありません。

どちらの形式も 1 本のストリームだけを圧縮するので、ディレクトリという概念を知りません。実際には .gz のほとんどが .tar.gz であり、名前とフォルダーを持つ TAR に gzip をかぶせたものです。この変換は両方の層を外したあと、両方を作り直します——中身を新しい TAR にまとめ、それを xz で圧縮します。

知っておくべきなのは、元が tarball ではなかった場合です。単なる access.log.gz は 1 個の普通のファイルですが、再構築するとやはり TAR で包まれるので、出てくるのは access.log を含む tarball です。tar xJf で展開すれば問題なく、unxz を使おうとすると output.tar というファイルが出てきて戸惑うことになります。単独の圧縮ストリームを前提にしたツールを使うなら、この点を織り込んでおいてください。

gzip ストリームは元のファイル名をヘッダーに持てます。Unix で dump.gz を展開すると拡張子に何も書いていなくても dump.sql が返ってくるのはこのためです。XZ にはこの項目がなく、データがどこから来たかについては何も保存しません。

これはこの変換機で実際に起きたバグの原因でもありました。gzip は名前を保存し xz は保存しないため、内側の tarball は GZ からならそれらしい名前で、XZ からなら抽出処理が決めた名前で出てきます。修正では名前から推測するのではなく tar かどうかを中身から強制的に判定するようにしました。使う側にとっての教訓はもっと単純です。ダウンロードしたファイルに付ける拡張子だけが、以後ずっと残るラベルになります。something.tar.xz と、意味を持たせて名付けてください。

どちらの形式も自己検証を持っており、この変換を無人で走らせても安全な理由の 1 つです。gzip ストリームは末尾に CRC-32 と展開後の長さを持ち、XZ ストリームは既定で CRC-64 の検査を展開データ全体に対して持ちます。どちらも、途中で切れたダウンロードやビットの反転があれば、黙って短いファイルを返すのではなくエラーになります。

どちらにもできないのは、どのファイルが壊れているかを教えることです。この層にはファイルという概念がないからです。ZIP や 7Z はエントリーごとにチェックサムを持ち、40 個中 1 個だけが壊れていると報告できますが、圧縮ストリームは「ストリーム全体が壊れている」としか言えません。一部が傷んでも残りを復旧したいなら、ストリーム圧縮はそもそも向いていない入れ物です。

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

ジョブごとにメモリー上の一時領域が割り当てられ、成功しても失敗しても終了時に削除されます。60 秒を超えて動いているものは強制終了されます。壊れた形式のアーカイブは失敗するより無限ループに陥ることのほうが多いためです。無料枠は 1 ファイルあたり 25 MB で、ログのアーカイブなら十分な量のテキストですが、データセットには現実的な上限です。

「gzip では縮みが足りない」に対するもう 1 つの伝統的な答えが BZ2 ですが、ほとんどのテキストでは現在 XZ に圧縮率でも展開速度でも劣ります。この形式がレガシー扱いされているのはそのためです。唯一の利点は、メモリーの話の裏返しです。bzip2 は最大 900 KB のブロック単位で動くので、展開に大きなメモリーを必要としません。

つまり選択の軸は圧縮率ではありません。展開する機械が普通のコンピューターなら XZ を、そうでなければ——古い機器、制約のあるコンテナー、xz が本当に入っていないシステムなら——BZ2 を選んでください。圧縮率だけで BZ2 を選ぶのは、もう長らく正しくない 2005 年ごろの判断です。

まず 1 ファイルだけ試して 2 つのサイズを見比べてください。どんな経験則よりも、代表的な 1 ファイルのほうが残り全部の結果を正確に教えてくれます。答えを決めるのは形式ではなく中身だからです。ログアーカイブを半分にする同じ変換が、写真フォルダーにはまったく効きません。最初の 1 ファイルがほとんど変わらないなら、そこで止めてください。データに長距離の重複がなく、どんな圧縮機を使っても見つからないということです。

サイズだけでなく一覧も確認してください。結果に tar tJf をかけ、元の GZ のエントリー数とパスを突き合わせます。特にトップレベルに注意してください。あるディレクトリの中から作られたアーカイブと、その親から作られたアーカイブでは、すべてのパスの先頭フォルダーが 1 つずれます。この違いは何ヶ月も経ってから、誰も変換のことを覚えていないころにスクリプトを壊します。一覧が一致し、サイズが期待どおりになったら、元のファイルの役目は終わっています。