ZIP を TAR に変換

保存のために TAR へ変換する人はいません。変換するのは、後段の処理が tarball しか読まないからです。コンテナのビルドコンテキスト、デプロイのスクリプト、tarball を前提にしたインポート用のエンドポイント、1998 年に書かれて今も静かに使われ続けているツール。TAR は 1979 年に生まれ POSIX.1-2001 ustar として標準化されており、多くのインフラがこれを前提にしているのは、それらのソフトが書かれた当時、アーカイブといえば tarball のことだったからです。

この変換は PDF が文書の互換性のために存在するのと同じ意味での互換性の変換です。アーカイブの中身を何か改善しているわけではなく、どのプログラムが受け入れてくれるかを変え、その代償をバイト数で払っています。結果を評価する基準は、後段のツールが文句を言わなくなったかどうかであり、生成されたファイルのサイズではありません。ビルドや取り込みが終われば、TAR のほうは使い捨てにしてよいことが多く、保存しておく価値があるのは変換前の ZIP です。

これはこの組み合わせについて語られる文章の多くが省いている点です。ZIP は保持するすべての項目に DEFLATE をかけますが、TAR は何にも圧縮をかけません。片方から片方へ変換するというのは、圧縮を解除するだけで別の圧縮に置き換えるわけではないので、出力は入力の何倍にもなることがよくあります。

テキストの多いアーカイブほどこの倍率は大きくなります。ソースコードや CSV の書き出し、ログ、XML はどれもよく圧縮できるので、それを元に戻すのは高くつき、何倍にもなり得ます。JPEG や MP4、PDF ばかりの ZIP なら差はわずかです。すでに圧縮されたファイルをアーカイブに詰めていただけで、ZIP がしていたことがそもそも少なかったからです。この先ファイルをどこかへ送る予定があるなら、どちらの場合にあたるかをダウンロードの前に見積もっておく価値があります。ファイルを 4 倍にする変換は、ローカルディスクなら問題なくても、ネットワーク越しでは高くつきます。

TAR は固定 512 バイトのブロックの連なりです。各メンバーは名前、サイズ、モード、タイムスタンプを持つヘッダーブロック 1 つと、512 の倍数に切り上げられた本体が続き、アーカイブの末尾はゼロで埋められた 2 ブロックで終わります。索引も圧縮テーブルも中央ディレクトリもありません。

この構造は小さなファイルが大量にあるアーカイブで目立ちます。1 キロバイトのファイルが 500 個あれば、それぞれに少なくともヘッダー 1 個と本体 2 ブロックがかかるため、パディングだけでも無視できない量になります。ソースツリーの TAR が、元の ZIP と比べて不釣り合いに大きく見える理由のひとつで、これは取り除かれた圧縮とは別に起きることです。

TAR はファイルのモードやユーザー、グループを記録できます。Unix のツール群がこの形式を好むのはそのためです。ただし、記録できることと、その値を作り出せることは別の話です。値はこのコンバーターが ZIP を展開した結果として得られるものであり、そのファイルが元々あった機械から来るものではありません。

そのため出力の中の権限は「保たれている」のではなく「未指定」だと考え、何かがそれに依存しているなら展開後に明示的に設定してください。スクリプトの実行ビットがいちばんよくある被害者です。このサイトのアーカイブ変換全体に共通する一般的な注意は、メンバーはバイト単位で同一だが、コンテナが中身「について」持っていた情報は失われる危険があるというものです。

この組み合わせを探す人の多くは実際には圧縮された tarball を必要としています。手順書に書かれていた指示がそういうものだったからです。行き先がダウンロードやリリースの成果物、ネットワークを渡るものであれば、圧縮していない TAR は答えの半分にすぎません。

代わりに ZIP を GZ に変換すれば、まさにその答えが得られます。1 つのファイルしか保持できない行き先——GZ、BZ2、XZ——はすべて、まず TAR を作ってからそれを圧縮するという手順で作られ、これは .tar.gz という慣習がずっと意味してきたことです。ツールが tarball を求めているなら TAR を、人がダウンロードするなら GZ を選んでください。

アーカイブの詰め替えは、このサイトの中で本物の機械を必要とする処理のひとつなので、ファイルは実際に移動します。暗号化された接続でこのサイトのコンバーターへ送られ、7-Zip が ZIP を展開して TAR を書き出し、結果が戻ってきたら、アップロードされたファイルも出力もジョブの終了とともに削除されます。スクラッチディレクトリはメモリー上にあり、コンテナと一緒に破棄されます。

上限もこの構成に合わせたものです。無料枠は 1 ファイルあたり 25 MB で、1 ジョブあたり 60 秒という明確な打ち切りがあります。この規模の詰め替えとしては 60 秒は十分な余裕があり、これは意図的に壊されたアーカイブが失敗ではなく処理を空回りさせ続けることへの防御として設けられています。

事前に知っておく価値のある拒否が 2 つあります。展開後のサイズが 2 GB を超えると申告しているアーカイブは、1 バイトも書き込まれる前に拒否されます。これはファイルシステムを埋め尽くすために作られた ZIP への防御です。中身が空だった ZIP には、空の tarball ではなく明確なメッセージが返ります。

暗号化された ZIP もここで止まります。展開ツールにはあえて空のパスワードが渡されるため、保護されたアーカイブは決して答えられないプロンプトを待つのではなく、読み取れるエラーですぐに失敗します。パスワードは手元で外してから、平文のアーカイブを変換してください。

長期保存という点で、TAR には圧縮された形式が持たない性質があります。損傷が局所にとどまることです。圧縮していない tarball の一部が壊れても、その部分のファイルを失うだけで、それ以降は読み続けられます。構造がヘッダーと本体の連なりにすぎず、メンバー同士に共有される状態がないからです。ブロックを辿るツールは損傷を飛び越えて先へ進め、テキストエディターでもどのファイルが影響を受けたかくらいはわかります。

圧縮されたアーカイブはこれほど寛容ではありません。連続したストリームの前のほうで壊れたバイトが 1 つあると、それ以降の後続の参照がすべて依存しているため、あとの内容がすべて失われることがあります。これは、圧縮版の代わりにではなく、圧縮版と並べて圧縮していない TAR も保存しておく正当な理由になります。移動には圧縮ファイル、生き残るには無圧縮ファイルというわけで、多くの人がこのページに来た理由——ツールの要求——とはまったく別の理由です。