XZ を ZIP に変換

XZ は単に、上流のプロジェクトが公開に使っている形式というだけです。ソースリリース、ディストリビューションのパッケージ、カーネルのツリー、言語のツールチェーン一式まで、圧倒的に .tar.xz で配布されます。何千回もダウンロードされ、ビルドは 1 回だけだからこそ、節約できる 1 メガバイトが何度も効いてきます。

この慣習はシェルを使う人たちの間で形成されました。tar -xJf を打てば両方の層が 1 コマンドで外れ、何も入れる必要がなく、そもそも問題になりません。そこから外れた場所では役に立ちません。Windows は未知のファイルとして表示し、macOS も特に何もしてくれず、ダウンロードは「何かの 4 メガバイト」としてフォルダーに置かれたままになります。この形式を選んだ人たちは、この問題に出会うことがない立場の人たちで、それには十分な理由がありますが、あなたの都合とは関係がありません。だからこの変換があります。上流が ZIP を公開すべきだったという議論の代わりに。

XZ は 1 本のストリームだけを圧縮し、それ以外は何もしません。単一メンバーのストリーム形式で、ディレクトリ構造を持たないことが弱点として知られています。.xz ファイルには名前もパスも権限ビットも入れる場所がありません。

ファイル名はその下の TAR にあります。ファイルごとのヘッダーブロックと中身が順に並び、それ自体の圧縮も索引もありません。XZ は自分が圧縮しているバイト列がファイルを表しているとすら知りません。フォルダーを取り戻すには 2 つの層を別々に外す必要があり、片方だけを外すと Windows では変換前のファイルと同じくらい開けない .tar が残ります。多くの人がここで「何かがおかしい」と感じます。このページの変換が外側の包みだけを外すツールと違うのはここです。

LZMA2 は最大 64 MB 前のストリーム内容への参照として繰り返しを符号化し、DEFLATE のハフマン符号より少ないビット数で済むレンジコーダーでそれを符号化します。ZIP の 32 KB の窓と比べると、およそ 2000 倍の到達距離です。

ソースツリーではこの効果が劇的です。同じライセンスヘッダーが 200 個のファイルの冒頭に、同じ import 文が、同じ生成された定型コードが、同じインデントが散らばっているからです。プロジェクトのリリース tarball が展開後のごく一部のサイズに収まっているのはこのためであり、このページから返ってくる ZIP がアップロードしたファイルに比べて驚くほど大きく見えるのもこのためです。どちらの数字も間違っていません。20 年と 3 桁の差がある圧縮方式で、同じ中身を測った 2 つの正直な数値です。

展開が始まる前に、アーカイブが何を含むと宣言しているかが確認され、2 GB を超える宣言は明確なメッセージとともに拒否されます。多くのアーカイブの組み合わせでは、この防御は意図的な悪意あるファイル向けで、実物のファイルで発動することはまずありません。

このペアは例外です。強力な圧縮を大きなツリーにかければ、アップロードに支障のないサイズのファイルに 2 GB を優に超える中身を詰め込めるので、まったく悪意のない普通のソースアーカイブが拒否されることがあります。これは失敗ではなく意図的な制限です。この変換機は容量が限られたメモリー上の作業領域と 60 秒の時間予算しか持たず、その規模のアーカイブはローカルツールの仕事だからです。

相対的にかなりの代償です。ZIP は各エントリーを 32 KB の窓で独立に圧縮し、目次を書き出すだけなので、ファイルの境界をまたぐ重複はおろか 64 MB 遡ることもできません。長い辞書が見つけたものはすべて、あらためて代金を払うことになります。

リリースの中身を見たいだけの人にとっては、これは妥当な取引です。ZIP はソフトなしで開け、容量が問題になるのはダウンロードフォルダーに置いている間だけだからです。保管や転送が目的なら、割の悪い取引です。より良い答えは、.tar.xz を上流が公開した形のまま保ち、ローカルのツールで開くことです。標準的なデスクトップが読める形式で、これほど強く縮むものはほかにありません。

LZMA2 を展開するには、圧縮時に使われた辞書を保持しておく必要があるので、必要なメモリーは圧縮ファイルの大きさではなく、その設定に追随します。大きな辞書で書かれた小さな .xz ファイルは、見かけのサイズより展開が重くなります。

ノートパソコンやサーバーではまったく問題になりません。ルーターや小型組み込みボード、メモリー制限のあるビルドエージェントといった制約のある環境で初めて現実の問題になります。2026 年になっても gzip の控えめな 32 KB の窓が優位性を持ち続けている数少ない技術的な理由の 1 つで、.tar.gz を .tar.xz と並べて公開しているプロジェクトが今もある理由でもあります。

すべての xz ファイルが tarball というわけではありません。1 個の圧縮されたディスクイメージ、1 個の大きなログ、1 個のデータベースダンプ——xz を 1 ファイルに使うのもこの形式の設計どおりの使い方で、TAR はどこにも関わりません。

この変換機は xz の層から出てきたものを TAR として解釈しようとし、失敗すればそれを 1 個のファイルとしてそのまま扱い、ZIP にはそのファイルが入ります。xz は bzip2 と同じく元の名前を保存しない（gzip とは違う）ので、エントリー名はアーカイブが覚えていたものではなく、処理過程で付けられたものになります。渡す前に意味のある名前を付け直してください。

この変換はページの中ではなくサーバー側で行われます。ファイルは暗号化された通信でアップロードされ、展開・分離されたあと、展開先ディレクトリの中から ZIP として再構築されて送り返されます。アップロードされたファイル、中間生成物の tar、出力結果は、ジョブが終わると同時にすべて削除されます。

作業領域はメモリー上にあり容量が決まっていて、使い終わったコンテナーごと破棄されます。無料枠のアップロードは 25 MB まで、各ジョブは 60 秒で強制終了され、パスワード保護されたアーカイブは表示される場所のないプロンプトを待つのではなく、メッセージとともに失敗します。ファイルの中身は何も保持されず、誰にも読まれません。

アーカイブの送り先が Linux の機械やビルドエージェント、コンテナーイメージなら、変換はあらゆる面で後退です。送り先にはすでに xz が入っており、ZIP のほうが転送に大きく、TAR が持っていたモードや所有権は ZIP への移行の途中で失われます。ソースリリースを ZIP に変換してからビルドすると、まさにこの理由で失敗することがあり、それはアーカイブではなくプロジェクト自体の問題のように見えてしまいます。

変換すべきなのは、デスクトップの人が中身を見る必要があるとき、アップロードフォームが ZIP を要求して譲らないとき、あるいはアーカイバーを一切入れない相手に中身を転送するときです。.tar.xz が定期的に届くなら、7-Zip や Keka はどちらの層もローカルで、容量の上限もアップロードもなく処理できますし、最近の Windows にはターミナルから同じことができる tar コマンドが標準で入っています。それが変換機よりも長期的にはよい答えです。

ソースリリースには通常チェックサムのファイルが添えられ、しばしば分離署名も添えられます。どちらも上流が書き出したままの .tar.xz を対象にしています。何かを変換する前に、必ず元のダウンロードに対して検証してください。再パッケージした ZIP はどちらとも一致しません。中身のファイルは同一でも、それを包むアーカイブ自体は別のツールが別の瞬間に書いた新しいものだからです。

これは変換の欠陥ではなく、検証というものの本来の姿です。正しい順序は、取得したファイルの署名を確認し、プロジェクト由来であることに納得してから、ZIP が必要な用途のために再パッケージすることです。先に変換してから検証すると、驚くほど不安になる不一致が出ますが、それ自体には何の意味もありません。まったく問題のないダウンロードが改ざんされたと誤解する、実によくある経路です。