はじめに

「tarで良いのでは？」

PAFについて投稿したところ、そういったコメントをいただきました。
正直、私自身も「tarで良い」と思っていたし、今でもtarはよく使っています。

それでも私は、新しいアーカイブ形式 PAF（Parallel Archive Format） を作りました。
なぜtarがあるのに、わざわざPAFを作ったのか？
本記事では、それでもPAFを開発した理由と設計思想を紹介します。

「tarで良い」と思っていた

まず最初に、tarは非常に優秀です。

アーカイブ形式として、tarはすでに完成されています。
だからこそ、最初にPAFを作ろうとしたときに思ったのは：

「tarでいいのでは？」

正直に言えば、最初はtarの代替を作るつもりではありませんでした。
ただ、アーカイブ形式を自分で作ってみたい、という思いがありました。

そうしたエンジニアとしての好奇心や創作意欲から、PAFの構想は始まりました。

最初は、tarをGUIやブラウザで扱えるようにする構想も考えていました。
ですが、実際に対応すべき要件を洗い出していく中で課題が見えてきました。

こうした要件を1つ1つ丁寧に満たしていくには、既存のtarベースよりも、
ゼロから設計したほうがシンプルで安全だと判断しました。

結果として、PAFは「技術的にも、構造的にもtarとは異なる道を選んだ」形式になりました。

以下に、よく使われる .zip, .tar, .paf の3つのアーカイブ形式の比較を示します。

項目	`.zip`	`.tar`	`.paf`
圧縮対応	✔（デフォルトで圧縮）	❌（圧縮は別途）	❌（非対応）
非圧縮時の展開速度	△（ZIP構造が複雑）	△（逐次走査）	◎（爆速：生バイナリ）
UTF-8対応	△（実装依存）	△（ロケール・実装依存）	◎（UTF-8固定）
`.gitignore` 互換除外	❌	❌	◎（`.pafignore`, `--ignore-from`）
部分抽出の効率	△（ZIP構造による）	❌（全体走査）	◎（インデックス構造）
所有者・パーミッション保存	△（一部対応）	◎（完全対応）	❌（あえて非対応）
CRCチェック	✔（ZIP標準）	❌	◎（各ファイルにCRC32）
トラバーサル保護	❌	実装依存	◎（明示的に対策済）
GUI/ブラウザ展開	◎（OS標準）	❌	◎（WASM・GUI設計中）
スクリプト互換性	◎	◎	○（C API / Python CLI）
向いている用途	一般的な圧縮共有	バックアップ・構成管理	高速配布・安全展開・GUI統合向け

PAFは、以下のような情報を保存しません：

PAFは再現性の高いバックアップ用途ではなく、
環境を問わず安全・高速に展開できる配布用アーカイブを目指しているためです。

「tarで良いのでは？」という声。
私も本当に同じように思っていました。

それでも、
tarとは違う方向からアーカイブを考えてみたくなった。
そして、自分の願望を形にしたPAFを作りました。

tarで良いのは間違いありません。
私も何かしらでアーカイブ化が必要になったらtarを使うと思います。
でも、tarとは別のアプローチもあっていい。

PAFが何か1つでも、現場での「あ、こういうの欲しかった」に届けばうれしいです。