http://www.parfiles.net
パリティ・ボリューム・セット 仕様書 2.0
マイケル・ナハス
ピーター・クレメンス
ポール・ネトル
リャン・ギャラガー
2003年 5月 11日

改訂履歴
改訂版 1.0 | 2001年 10月 14日
関連する仕様、発想
改訂版 2.0 | 2003年 5月 11日
新しい仕様、最初の公開と形式
著作権 (c) 2003 著者一同 | GNU Free Documentation License バージョン 1.2 または Free Software Foundation によって公開された より新しいバージョンの文言に基づいて； 各欄が不変で、表紙の文章無しで、裏表紙の文章無しで、 この説明をコピー、配布、または修正することを許可を与える。 ライセンスのコピーは「 GNU Free Documentation License 」という名前の章に含まれています。

内容一覧

紹介 |
慣例 |
説明 |
| Main packet
| File Description packet
| Input File Slice Checksum packet
| Recovery Slice packet
| Creator packet
結論 |
A. 選択制の PAR 2.0 パケット
| Unicode Filename packet
| ASCII Comment packet
| Unicode Comment packet
| Input File Slice packet
| Recovery File Slice Checksum packet
| Packed Main packet
| Packed Recovery Slice packet
B. アプリケーションに特有のパケット型を追加する方法
C. GNU Free Documentation License
| PREAMBLE
| APPLICABILITY AND DEFINITIONS
| VERBATIM COPYING
| COPYING IN QUANTITY
| MODIFICATIONS
| COMBINING DOCUMENTS
| COLLECTIONS OF DOCUMENTS
| AGGREGATION WITH INDEPENDENT WORKS
| TRANSLATION
| TERMINATION
| FUTURE REVISIONS OF THIS LICENSE
| ADDENDUM: How to use this License for your documents

概念
スティファン・ウェルスその他による パリティ・ボリューム・セット 仕様書 1.0 [2001/10/14] を元にしてます。

紹介
この説明文はファイル・セットに対して冗長性データを格納するファイル形式を記述します。
操作中に、ユーザーは冗長性データが作り出されるファイル・セットを選択します。 それらは 入力ファイル として知られて、 そのセットは リカバリ・セット として知られています。 ユーザーはこの説明文の仕様に合致するファイルを生成するプログラムにそれを与えます。 そのプログラムは PAR 2.0 クライアント または短く クライアント として知られて、 生成されたファイルは PAR 2.0 ファイル または PAR ファイル として知られています。 もしリカバリ・セット内のファイルが損傷すれば ( 例えば、変換された時や失敗しやすいディスクに格納されたりして ) 、 クライアントは損傷した入力ファイルを読み取って、 ( 損傷してるかもしれない ) PAR ファイルを読み取って、 本来の入力ファイルを再生成します。 もちろん、全ての損傷を修復できるわけではありませんが、多くのはできます。
ユーザーは損傷しても回復させない入力ファイルを名付けることもできます。 それらの入力ファイルは ノン・リカバリ・セット として知られています。 この機能はPAR 1.0 の機能と同じ仕様を保っています。
PAR ファイル内の冗長性データはリード・ソロモン符号を使って計算されます。 その符号は同じ大きさのデータ・ブロックのセットを受け取って、 同じ大きさのリカバリ・ブロックを作り出します。 そして、本来のデータ・ブロックの一部といくつかのリカバリ・ブロックを与えられて、 本来のデータ・ブロックを再度作り出すことが可能です。 消失したブロックの数がリカバリ・ブロックの数を上回らない限り リード・ソロモン符号はこの修復を行うことができます。 この仕様のリード・ソロモン符号の設計は ジェームズ・S・プランク の A tutorial on Reed-Solomon coding for fault-tolerance in RAID-like systems という題名のテネシー大学の技術論文に基づいています。 その技術論文は間違いを含んでるので、 問題を修正するために設計は少し変更されています。 PAR 2.0 は 16ビットのリード・ソロモン符号を使って、32768個のブロックに対応してます。
リード・ソロモン符号のための同じ大きさのブロックは リカバリ・セット内の入力ファイルの スライス から来てます。 そのスライスは各ファイルの連続した同じ大きさの塊です。 もしファイルが塊で一杯にならなければ、 言い換えるなら、もしスライスの途中で終わったなら、 スライスの残りは 0バイトで埋められたものとして扱われます。
PAR 2.0 ファイル自体は パケット、自分自身のチェックサムを伴う自己含有部品、で作られます。 この設計により、ファイルの一部の損傷がそのファイル全体を使用不可能にすること、は防がれます。
パケットには型がありそれぞれのパケット型が異なる目的に使用されます。 あるものはファイルを記述します。 他のものはファイルのスライスのチェックサムを含みます。 他のものはどのファイルがリカバリ・セットに入っていて、 どのファイルがノン・リカバリ・セットに入ってるのかを述べます。 そして更に他のものは リカバリ・スライス、 リード・ソロモン符号によって作り出されたリカバリ・データを含みます。
PAR 2.0 ファイルは、ただ一つの特定のパケットを含むことを要求されるだけです、 そのパケットとはファイルを作成したクライアントの型を識別するものです。 この方法により、クライアントがどういう方法でか仕様書に合致しないファイルを作成したら、 それを追跡することができます。
リカバリ・セットとノン・リカバリ・セットのパケットは 複数のファイルにまたがって分割することができます。 ファイルは重複したパケットを含むことができ、実際には、 入力ファイルを記述するものや どのファイルがリカバリ・セットに入ってるかを述べるもののような、 重要なパケットにはそれが推奨されています。 パケットはファイル内でどのような順序で現われることもできます。

慣例
この仕様書の設計には数多くの慣例があります。
データは 4バイトごとに並んでいます。 どの領域もファイル内の 4で割ると 0になる場所 ( つまり、アドレス % 4 = 0 ) から開始されます。 これは、32ビット量が 4バイトごとに並んでるといくつかのメモリー・システムが高速だからです。 ファイルが破損 ( バイトが挿入されたり削除されたり ) して並びから外れることもありえる、 ということに注意すべきです。 将来のバージョンは 8バイトごとに並ぶことができるように、この仕様は設計されています。
このバージョンの仕様の全ての整数は、4 か 8 バイトのいずれかの長さの符号なし整数です。
文字列は null文字で終了しません。 これは、ハッカーがスタック・オーバーフロー攻撃を使えないようにするためです。 文字列を 4バイトごとに並べる為に、1〜3個の 0バイトが追加されます。 ( ユニコード文字列の場合は 2バイトです。 ) もし、Nバイトの領域が配列を含むのなら、 Nバイトの領域を長さ N + 1 の文字配列にコピーすることで、 null文字で終了する文字列を作り、 N + 1 の文字を '\0' にします。
配列と文字列の長さはしばしば暗黙的です。 例えば、領域が 32バイトだと知られていて、 領域が 8バイト整数と文字列を含むのなら、 その文字列は 24バイトまでだとわかります。 そうすると、その文字列は最低でも 21バイトの長さです。 なぜなら、24バイトは終端に 0〜3バイトの null文字の埋め込みを含むからです。
「根幹部分」の仕様の文字列は全て ASCII です。 これは、ユニコードがツールによって十分にサポートされてるわけではないから選ばれました。 ユニコード文字列をサポートする仕様の選択制の部分も存在します。
ファイルとファイル部分の長さは 8バイト整数に決定されました。 これは、4GB 以上のファイルを扱うことができる OS をサポートする為です。
全ての整数は Intel-endian です。( これは little endian のことです。)
リカバリ・セット ( と、存在するならノン・リカバリ・セット ) は、 Recovery Set ID として知られる 16バイトの値で識別されます。 リカバリ・セットに関する PAR ファイルの全部分はその Recovery Set ID を含みます。 このバージョン 2.0 においては、 Recovery Set ID は決まった値の MD5 ハッシュとして算出されます。 この値を算出する方法は将来のバージョンで変更されるかもしれません。
ファイルもまた 16バイトの値で識別されます。 このバージョン 2.0 においては、 それは名前と長さと先頭 16KB の MD5 ハッシュの MD5 ハッシュです。 この値を算出する方法は将来のバージョンで変更されるかもしれません。
PAR ファイルの全てのバイトは指定されています。 どんな値でもとりうるゴミのようなバイトを放置する場所はありません。 必要な場所への埋め込みは 0バイトであるべきだと定められています。 全ての配列内の項目の順序は指定されています。
二つのクライアントが同じパラメーターでパケットを生成すれば、 そのパケットは同じになる ( クライアント識別やクライアント特有のを除いて ) ように、 仕様書は設計されています。 それゆえ、クライアントを書く人は、一バイトずつパケットを比べることにより、 標準実装例に対して自分のプログラムの出力を比較することができます。

説明
PAR 2.0 ファイルは一連の「パケット」で構成されています。 パケットは固定サイズのヘッダーと可変長の内容を持ちます。 パケット・ヘッダーはパケットのチェックサムを含みます、 パケットが損傷すれば、そのパケットは無視されます。 パケット・ヘッダーはまたパケット型も含みます。 もしクライアントがそのパケット型を理解しないなら、そのパケットは無視されます。 この仕様に従う為には、クライアントは「根幹部分」のパケットを理解しなくてはなりません。 クライアントは選択制のパケットを処理したり、 自分のアプリケーション特有のパケットを作成してもいいです。
パケット・ヘッダーは：
表 87、Packet Header

長さ (バイト) | 型 | 説明
8 | byte[8] | 識別文字です。(訳注 1) パケットの位置をすぐに識別する為に使われます。 値 = {'P', 'A', 'R', '2', '\0', 'P', 'K', 'T'} (ASCII)
8 | 8バイトの uint | パケット全体の長さです。 4の倍数でなければなりません。 ( 要注意、ヘッダーの長さも含みます。)
16 | MD5 ハッシュ | パケットの MD5 ハッシュです。 パケットのチェックサムとして使われます。 Recovery Set ID の最初のバイトから計算を始めて、 内容の最後のバイトで終了します。 識別文字、長さ、またはこの領域を含まないようにしてください。 要注意、 定義によると MD5 ハッシュは、 まるでパケットに追加されたように長さを含みます。
16 | MD5 ハッシュ | Recovery Set ID です。 一緒にある全てのパケットは同じ Recovery Set ID を持ちます。 ( どうやって算出するかについては「 main packet 」の所を見てください。)
16 | byte[16] | 型です。何でも可能です。 "PAR " (ASCII) で始まるものは、 仕様で定義されているパケットのために確保されています。 アプリケーション特有のパケットは、 クライアントの ASCII での名前で始めることを推奨されています。
? * 4 | ? | パケットの内容です。 4バイトの倍数でなければいけません。

様々な型のパケットが存在します。 「根幹部分」のパケット、 全てのクライアントが認識して処理しないといけないパケット、 は次の一覧にあります。 それぞれについて、 パケットの内容と共に「型」領域の値も列記されています。

> Main packet
> Main packet はスライスの大きさとリカバリ・セット内の全てのファイルの File ID を含みます。 Main packet の内容の MD5 ハッシュが、 セットの全パケットのパケット・ヘッダーに含まれる、 Recovery Set ID として使われます。 ファイルを読み取るクライアントは、 全てのパケットで Recovery Set ID が同じか調べるだけにすべきで、 それが正しい値に計算されてるかは確かめるべきではありません。 なぜなら、Recovery Set ID を計算する方式は将来のバージョンで変更されるかもしれないからです。
> Main packet の型の値は "PAR 2.0\0Main\0\0\0\0" (ASCII) です。 パケットの内容は次のものを含みます。
> 表 126、Main packet

> 長さ (バイト) | 型 | 説明
> 8 | 8バイトの uint | スライスのサイズです。4の倍数でなければいけません。
> 4 | 4バイトの uint | リカバリ・セット内のファイルの数です。
> ? * 16 | MD5 ハッシュの配列 | リカバリ・セット内の全てのファイルの File ID です。 ( File Description packet の所を見てください。) これらのハッシュは数字の値として ( 16バイトの符号無し整数として扱って ) 並び替えられ ます。
> ? * 16 | MD5 ハッシュの配列 | ノン・リカバリ・セット内の全てのファイルの File ID です。 ( File Description packet の所を見てください。) これらのハッシュは数字の値として ( 16バイトの符号無し整数として扱って ) 並び替えられ ます。

> File Description packet
> File Description packet は 各入力ファイル、修復可能や修復不可能のもの、のためにあります。 パケットの最初のものは File ID で、 PAR ファイル内のファイルを独特なものとして識別します。(訳注 2) そしてパケットは、MD5 ハッシュ、ファイルの先頭 16KB の MD5 ハッシュ、 ファイルの長さ、そしてファイル名を含みます。 名前が変更されていた場合にクライアントがファイル全域を読むこと無しに、 クライアントがそのファイルを識別することができるように、 ファイルの先頭 16KB の MD5 ハッシュは含まれています。 ( もちろん、それは先頭 16KB が損傷してなかったり失われていないことを仮定してます。)
> このバージョンの File ID は、このパケット内容の最後の 3領域 ( MD5-16k と長さと ASCII ファイル名 ) の MD5 ハッシュとして計算されます。 注意、長さと MD5-16k が含まれるのは、 Recovery Set ID は File ID のハッシュで、 Recovery Set ID は名前だけでなくファイル内容の働きをするべきであるからです。
> ファイル名は大文字と小文字を区別してどんな長さでも可能です。 ファイル名の大文字と小文字を区別しなかったりファイル名の長さに制限がある オペレーティング・システム上でクライアントが修復を行うのならば、 ファイルやディレクトリの名前を変更するかはクライアントによります。 ファイルのディレクトリが存在しなければ、 クライアントはそれを作成しなければなりません。
> File Description packet の型の値は "PAR 2.0\0FileDesc" (ASCII) です。 パケットの内容は次のものを含みます。
> 表 158、File Description packet の内容

> 長さ (バイト) | 型 | 説明
> 16 | MD5 ハッシュ | File ID です。
> 16 | MD5 ハッシュ | ファイル全域の MD5 ハッシュです。
> 16 | MD5 ハッシュ | MD5-16k ハッシュです。 これは、ファイルの先頭 16KB の MD5 ハッシュのことです。
> 8 | 8バイトの uint | ファイルの長さです。
> ? * 4 | ASCII 文字の配列 | ファイルの名前です。 この配列は null で終了することを保証しません！ サブ・ディレクトリは HTML スタイルの '/' ( 言い換えるなら UNIX 斜線 ) で示されます。 ファイル名は唯一無二で独特なものでなければいけません。

> Input File Slice Checksum packet
> このパケット型は入力ファイル内の全てのスライスに対するチェックサムを含みます。 それは、スライスの位置を素早くつきとめるための CRC32 チェックサムと 修正されてないかを検証するための MD5 チェックサムを含みます。 この CRC32 は CCITT で指定されてるもので、 Ethernet パケット ( そして PKZIP、FDDI、その他 ) のと同じです。 もしファイルがスライスの途中で終わるなら、 スライスの残りは 0の値のバイトで一杯にされます。
> Input File Slice Checksum packet の型の値は "PAR 2.0\0IFSC\0\0\0\0" (ASCII) です。 パケットの内容は次のものを含みます。
> 表 193、Input File Slice Checksum packet の内容

> 長さ (バイト) | 型 | 説明
> 16 | MD5 ハッシュ | 対応するファイルの File ID です。
> ? * 20 | {MD5 ハッシュ, CRC32} の配列 | ファイルのスライスの MD5 ハッシュ と CRC32 の組み合わせです。 ハッシュと CRC の組は、 ファイル内の連続したスライスの並び順と同じようになってます。 配列の要素においては、ハッシュが CRC の前に来ます。

> Recovery Slice packet
> Recovery Slice packet はリカバリ・データのスライスを一つ含みます。 リカバリ・データは、 生成値 0x0001100B での16ビットのガロア体 ( GF ) を使って生成されます。
> リカバリ・スライスを算出するアルゴリズムは、ジェームズ・S・プランク の A tutorial on Reed-Solomon coding for fault-tolerance in RAID-like systems という題名のテネシー大学の技術論文に基づいています。 インプット・スライスは順序だてられて割り当てられた 16ビットの定数です。 リカバリ・スライスは割り当てられた 16ビットの係数です。 リカバリ・スライスの 2バイト単位は各インプット・スライスから寄せられた総和です。 各インプット・スライスから寄せられたものは、インプット・スライスの 2バイト単位に、 インプット・スライスの定数をリカバリ・スライスの係数で増大させたものを掛けたものです。 これら全ての計算 ( 足し算、掛け算、乗数演算 ) は、 16ビットのガロア体上の演算を使って行います。
> リカバリ・データを生成する為に、入力ファイルのスライスは定数に割り当てられます。 これは、Main packet 内で File ID が現われる順序に基づいていて、 更にファイル内でスライスが現われる順序に基づいています。 なので、Main packet 内の最初のファイルの最初のスライスは、 最初の定数に割り当てられます。 最初のファイルの二番目のスライスは、二番目の定数に割り当てられます。 そうやって次々にやります。 最初のファイルの最後のスライスが N 個目の定数となるのならば、 二個目のファイルの最初のスライスは (N + 1) 番目のに割り当てられます。 そうやって続きます。
> PAR 2.0 仕様がプランクの論文と異なる点がここにあります。 プランクの論文では、最初の定数は 1 で、二番目は 2 で、三番目は 3 などとなります。 いくつかの定数は 65535 よりも小さい基数をもつので、これは悪いやりかたです。 ( つまり、ガロア体上では N の 65535 乗よりも小さな乗数が 1 になってしまう、定数の N が存在します。） そういう定数は修復用の行列が逆行列計算可能であることを邪魔して、 それゆえ、修復が止まってしまいます。 この仕様はそのような定数を使いません。 それで、最初の定数は 65535 を基数とする 2 の最初の乗数です。 二番目の定数は 65535 を基数とする 2 の次の乗数です。 そうやって続きます。 係数を 3, 5, 17, 257 で割った余りが 0 でなければ、 2 の乗数は 65535 を基数とします。 C コードでいうと、 それは (n%3 != 0 && n%5 != 0 && n%17 != 0 && n%257 != 0) みたいになるでしょう。 注意、これは試される 係数 であって、定数自体ではありません。 32768個の適切な定数が存在します。 その最初のいくつかは：
> ・ 2
> ・ 4
> ・ 16
> ・ 128
> ・ 256
> ・ 2048
> ・ 8192
> ・ 16384
> ・ 4107
> ・ 32856
> ・ 17132 ・・・
> Recovery Slice packet の型の値は "PAR 2.0\0RecvSlic" (ASCII) です。 パケットの内容は次のものを含みます。
> 表 232、Recovery Slice packet の内容

> 長さ (バイト) | 型 | 説明
> 4 | 4バイトの uint | リカバリ・データを生成するのに使われた係数です。
> ? * 4 | バイト配列 | リカバリ・データ

> Creator packet
> このパケットはファイルを作成したクライアントを識別するために使われます。 これは全ての PAR ファイルの中にあることが 要求 されます。 クライアントがリカバリ・セットを処理することができないならば、 Creator packet の内容がユーザーに表示され なければいけません。 クライアントのいかなる互換性の問題も探知されてすぐに解決されることができるようにするのが目的です。
> Creator packet の型の値は "PAR 2.0\0Creator\0" (ASCII) です。 パケットの内容は次のものを含みます。
> 表 254、Creator packet の内容

> 長さ (バイト) | 型 | 説明
> ? * 4 | ASCII 文字の配列 | クライアントを識別する ASCII 文字列です。 これはまたクライアントの作者に連絡を取る方法を含むべきです。 URL とか電子メール・アドレスとか。 要注意、これは null 文字で終了する文字列ではありません！

> 全てのクライアントが認識して処理しなければならない「根幹部分」のパケットは、これで終わりです。

結論
これが正式な仕様です。 クライアントが同じように動作することを確実にするために、 次のクライアントの慣例が続きます。
PAR 2.0 ファイルは常に「 .par2 」で終わるべきです。 例えば、「 file.par2 」のようにです。 ファイルがリカバリ・スライスを含むのなら、 その「 .par2 」は「 .volXX-YY 」を前に置くべきです。 この XX から YY というのは、リカバリ・スライスの係数の範囲のことです。 例えば、「 file.vol20-29.par2 」のようにです。 (訳注 3) 必要とあれば 2個以上の数字を使うべきです。 最大の係数よりも少ない数字を含む係数の前には 0 を置くべきで、 そうすることで全てのファイル名は同じ長さになります。 例えば、「 file.vol075-149.par2 」のようにです。 係数は 0 から始まって増えていくべきです。
複数の PAR ファイルが生成されるのなら、 それらはファイル当りのスライスの数が同じ ( つまり、20, 20, 20・・・みたいに ) であるか、 スライスの数が乗数で増加していく ( つまり、1, 2, 4, 8・・・みたいに ) のでもいいです。 注意点として、1023個のスライスを格納するのに、 各ファイルが 20個のスライスを持つのなら 52個のファイルが必要ですが、 乗数の分布でやるならたったの 10個しかファイルが要りません。
複数の PAR ファイルを生成する時には、どんなスライスも含まなくて、 全ての Main packet、File Description packet、そして Input File Slice Checksum packet を含むファイルを一つ期待します。 その他のファイルも Main packet、File Description packet、そして Input File Slice Checksum packet を含むべきです。 これは修復できないデータを繰り返します。
注意：ファイルが usenet を通して変換されるものならば、 Main packet、File Description packet、そして Input File Slice Checksum packet を末尾に配置して、 同じ大きさの Recovery Slice packet を先頭に配置するのが最善でしょう。 そのような方法によって、 各 usenet メッセージ内に一つのリカバリ・スライスを置くことが可能になるかもしれません。
PAR ファイルがたった一個だけ生成されるのなら、 Main packet、File Description packet、そして Input File Slice Checksum packet は複数回繰り返されて ファイルの各地にばら撒かれることを期待します。 ( もう一度いいますが、修復できないデータを繰り返します。)
全てのファイルは Creator packet を含まなければいけないことを思い出してください。
Windows、Mac、または Linux システムで互換性のない名前で PAR ファイルを作成しようとする時は、 ユーザーに警告することを推奨します。 つまり、255文字以上の長さのファイルやディレクトリの名前、 ピリオド ( ． ) やダッシュ ( ， ) で始まったり、 ＜ ＞ ： ” ’ ‘ ？ ＊ ＆ ｜ ［ ］ ￥ ； や改行文字 ( \n ) を含むものです。
File Description packet が絶対パスを含むようなファイルを書き込む前に、 クライアントはユーザーに質問することを 強く 推奨します。 例えば、Windows では「 C:\ 」や「 // 」で始まるものです。 UNIX では「 / 」や「 // 」で始まるものです。 Mac では「 : 」で始まるものです。 これにより、出所が不明の PAR ファイルが、 システム・ファイルを上書きしてシステムをクラックしようとすることは防がれます。

選択制の PAR 2.0 パケット
クライアントはこれらのパケットを処理する必要はありません。 多くのクライアントがその機能性を実装しようと望んでいるかもしれなくて、 もしそうした場合に、お互いに互換性があるなら素晴らしいことだろう、 という訳でこの仕様に含まれています。

> Unicode Filename packet
> このパケットはファイルのもう一つの名前を提供します。 このパケットは File Description packet 内の規定値の「 ASCII 」の名前を 上書き します。
> Unicode Filename packet の型の値は "PAR 2.0\0UniFileN" ( 皮肉なことに ASCII で ) です。 パケットの内容は次のものを含みます。
> 表 A-7、Unicode Filename packet の内容

> 長さ (バイト) | 型 | 説明
> 16 | MD5 ハッシュ | 対応するファイルの File ID です。
> ? * 4 | Unicode 文字の配列 | ユニコードでのファイルの名前です。 要注意、これは null 文字で終了する配列ではありません！ この名前は File Description packet 内の ASCII でのファイル名の制限事項を全て承諾しなければなりません。

> ASCII Comment packet
> ASCII Comment packet は、あなたが信じてるように、ASCII 文字列でコメントを含みます！ これはユーザーに表示されるべきです。 同じコメントが複数見つかれば、一個だけを表示すればいいです。
> ASCII Comment packet の型の値は "PAR 2.0\0CommASCI" (ASCII) です。 パケットの内容は次のものを含みます。
> 表 A-28、ASCII Comment packet の内容

> 長さ (バイト) | 型 | 説明
> ? * 4 | ASCII 文字 の配列 | コメントです。 要注意、これは null 文字で終了する文字列ではありません！

> Unicode Comment packet
> Unicode Comment packet は、ユニコードの文字列でコメントを含みます。 これはユーザーに表示されるべきです。 同じコメントが複数見つかれば、一個だけを表示すればいいです。 もし同じコメントの類似した ASCII バージョンがファイルに含まれていれば、 ASCII のコメントは表示されるべきではありません。
> Unicode Comment packet の型の値は "PAR 2.0\0CommUni\0" ( 皮肉なことに ASCII で ) です。 パケットの内容は次のものを含みます。
> 表 A-45、Unicode Comment packet の内容

> 長さ (バイト) | 型 | 説明
> 16 | MD5 ハッシュ または 0 | もし ASCII Comment packet がファイル内に存在して、 それがこのコメントのユニコードの翻訳に過ぎないのなら、 これは ASCII Comment packet の MD5 ハッシュです。 さもなければ、0 です。
> ? * 4 | Unicode 文字 の配列 | コメントです。 要注意、これは null 文字で終了する文字列ではありません！

> Input File Slice packet
> Input File Slice packet は、ユーザーが PAR ファイルの内部に入力ファイルを含めたい時に使われます。 大量の小さなファイルを一つのファイルに纏めたり、 大きなファイルを小さなファイルに分割する ( そのスライスを複数の PAR ファイルに分配することにより) のに、 これを使うことができます。 スライスがファイルの終端によって途切れない限り、 スライスの長さは Main packet 内のスライス・サイズによって決まります。 パケットはスライスのインデックスを含み、 ファイルの終端に到達しないなら、 スライスは ( スライス・サイズ * インデックス ) から ( スライス・サイズ * インデックス + スライス・サイズ - 1 ) までのバイトを含みます。 注意：このインデックスは、リカバリ・スライスを作る際に使われるインプット・スライスの定数とは異なります。
> もしファイルがインプット・スライスを含むのなら、 ファイル名の「 .par2 」は、 「 .partXX-YY 」を前に置くべきで、 XX〜YY はスライスのインデックスのことです。 例えば、「 file.part00-09.par2 」となります。 インデックスは、 リカバリ・パケットを生成する際に割り当てられた定数の順番と同じ順番で割り当てられます。 「Main packet 内に現われる File ID の順番と、 そのファイル内に現われるスライスの順番に基づいて・・・ したがって、Main packet の最初のファイルの最初のスライスには最初の定数が割り当てられます。 最初のファイルの二番目のスライスには二番目の定数が割り当てられます。などと続きます。 最初のファイルの最後のスライスが N 番目の定数であるならば、 二番目のファイルの最初のスライスは (N + 1) 番目のが割り当てられます。などと続きます。」
> Input File Slice packet の型の値は "PAR 2.0\0FileSlic" です。 パケットの内容は次のものを含みます。
> 表 A-69、Input File Slice packet の内容

> 長さ (バイト) | 型 | 説明
> 16 | MD5 ハッシュ | 対応するファイルの File ID です。
> 8 | 8バイトの uint | スライスの番号です。 ( 上記の説明を見てください。)
> ? * 4 | バイト配列 | スライスです。 スライスの途中でファイルが終わるなら、 この領域は 4バイトごとの区切りで終わるように 0〜3バイトの 0で隙間を埋められます。

> Recovery File Slice Checksum packet
> これまでの所、PAR ファイルの入力とリカバリ・スライスを持ち、 外部ファイルのインプット・スライス ( すなわち、Input File Slice Checksum packet のこと ) を持ってます。 このパケットは組み合わせの最後の部品を補います・・・ 外部ファイル内にあるリカバリ・スライス ( すなわち、パケット・ヘッダーを持たない場合 ) のことです。 このパケット型は決して使われないかもしれませんが、完全性のために含まれています。
> そのファイルに対する File Description packet が存在します。 スライスは Recovery Slice packet のためのものと同じように生成されます。
> Recovery File Slice Checksum packet の型の値は "PAR 2.0\0RFSC\0\0\0\0" です。 パケットの内容は次のものを含みます。
> 表 A-94、Input File Slice packet の内容

> 長さ (バイト) | 型 | 説明
> 16 | MD5 ハッシュ | 対応するファイルの File ID です。
> ? * 24 | {MD5 ハッシュ, CRC32, 4バイトの uint} の配列 | そのファイル内のスライスに対する MD5 ハッシュ、CRC32、そして係数の三点です。 そのハッシュ / CRC / 係数の三点は、ファイル内のそれに対応するスライスと同じ順序になっています。 配列の要素の順序は、MD5 ハッシュ、CRC32、次に係数という順です。

> Packed Main packet
> クライアントが Packed Recovery Slice packet を生成する時に、 Packed Main packet は Main packet を置き換えます。 その Packed 形式はスライス・サイズよりも小さな単位での修復を可能にするので、 修復の可能性を増やすと共に 32768個よりも多くのファイルを可能にします。 ( Packed でない形式は、各ファイルに少なくとも一つのスライスを必要として、スライスの数は 32768個に制限されてるので。)
> Main packet との違いはサブスライスのサイズだけです。 ( これがどのように使われるのかは、Packed Recovery Slice packet の説明を見てください。)
> Packed Main packet の型の値は "PAR 2.0\0PkdMain\0" (ASCII) です。 パケットの内容は次のものを含みます。
> 表 A-115、Packed Main packet の内容

> 長さ (バイト) | 型 | 説明
> 8 | 8バイトの uint | サブスライスのサイズです。 4の倍数でなければいけません。 スライス・サイズを均等に分割しなくてはいけません。
> 8 | 8バイトの uint | スライスのサイズです。 4の倍数で、サブスライス・サイズの倍数でなければいけません。
> 4 | 4バイトの uint | リカバリ・セット内のファイルの数です。
> ? * 16 | MD5 ハッシュの配列 | リカバリ・セット内の全てのファイルの File ID です。 ( File Description packet の所を見てください。) これらのハッシュは数字の値として ( 16バイトの符号無し整数として扱って ) 並び替えられます。
> ? * 16 | MD5 ハッシュの配列 | ノン・リカバリ・セット内の全てのファイルの File ID です。 ( File Description packet の所を見てください。) これらのハッシュは数字の値として ( 16バイトの符号無し整数として扱って ) 並び替えられます。

> Packed Recovery Slice packet
> Packed Recovery Slice packet はリカバリ・データの一つのスライスを含みます。 そのリカバリ・データは、Recovery Slice packet と同じ様式で生成されます。 インプット・スライスからのデータがどのように配置されるかだけが異なる点です。
> ファイルはサブスライスごとに切り分けられて、 そのサブスライスは Recovery Slice packet 内でと同じような順序になります・・・ まず最初に Packed Main packet 内の File ID の順番で、そして次にファイル内のサブスライスの順番です。
> それらのサブスライスは、計算で使われる入力データのスライスを構成するためにいっしょに集められます。 スライス内のサブスライスの数が X 個であるならば、 最初の X 個のサブスライスは最初のスライス (修復用の定数は 2 になります) を構成します。 その次の X 個のサブスライスは二番目のスライス (定数は 4 になります) を構成します。 などなど。
> 要するに、インプット・スライスは、 スライス境界ではなくサブスライスの境界で始まるファイルからなる、 複数のファイルを一緒にまとめて作られます。 サブスライスのチェックサムは存在しませんが、 スライスよりも小さな不完全領域を検出する為に使うことのできる、 ファイルのチェックサムは存在することに注意してください
> Packed Recovery Slice packet の型の値は "PAR 2.0\0PkdRecvS" (ASCII) です。 パケットの内容は次のものを含みます。
> 表 A-151、Packed Recovery Slice packet の内容

> 長さ (バイト) | 型 | 説明
> 4 | 4バイトの uint | リカバリ・データを生成するのに使われた係数です。
> ? * 4 | バイト配列 | リカバリ・データです。

> この仕様書内の選択制のパケットはこれで終わりです。

B. アプリケーションに特有のパケット型を追加する方法
Say the author of "NewsPost" wanted to add his own packet type - one that identified the names of the Usenet messages in which the files are posted. That author can create his own packet type. For example, here is the layout for one where the Usenet messages are identified by a newsgroup and a regular expression which all matches the names of the usenet articles.
The packet has a type value of "NewsPostUsenet\0\0". (NB: Including the name of the client in the type is the recommended way to ensure unique type names.) The packet's body contains the following:
表 B-3、アプリケーションに特有のパケットの例

長さ (バイト) | 型 | 説明
16 | MD5 ハッシュ | The File ID of the file.
4 | 4バイトの uint | The length of the string containing the name of the newsgroup. Must be a multiple of 4.
? * 4 | ASCII 文字の配列 | The name of the newsgroup. For example, "alt.binaries.multimedia".
? * 4 | ASCII 文字の配列 | A regular expression matching the name of articles containing the file. For example, "Unaired Pilot - VCD,NTSC - (??/??)".

C. GNU Free Documentation License
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

> PREAMBLE
> The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
> This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
> We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

> APPLICABILITY AND DEFINITIONS
> This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
> A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
> A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
> The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
> The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
> A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".
> Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
> The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
> A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.
> The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

> VERBATIM COPYING
> You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
> You may also lend copies, under the same conditions stated above, and you may publicly display copies.

> COPYING IN QUANTITY
> If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
> If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
> If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
> It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

> MODIFICATIONS
> You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

> > Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
> > List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
> > State on the Title page the name of the publisher of the Modified Version, as the publisher.
> > Preserve all the copyright notices of the Document.
> > Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
> > Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
> > Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
> > Include an unaltered copy of this License.
> > Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
> > Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
> > For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
> > Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
> > Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.
> > Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.
> > Preserve any Warranty Disclaimers.

> If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
> You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
> You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
> The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

> COMBINING DOCUMENTS
> You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
> The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
> In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

> COLLECTIONS OF DOCUMENTS
> You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
> You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

> AGGREGATION WITH INDEPENDENT WORKS
> A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
> If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

> TRANSLATION
> Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
> If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

> TERMINATION
> You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

> FUTURE REVISIONS OF THIS LICENSE
> The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
> Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

> ADDENDUM: How to use this License for your documents
> To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

> > Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

> If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:
> with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
> If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
> If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

http://www.parfiles.net

訳注 1：原文では魔法の一続きですが、わかりにくいので。
訳注 2：ハッシュ値なので同じ File ID になる可能性はありますが、そういうセットは作らないようにすべきです。
訳注 3：実装例では XX + ZZ となっていて最初の係数 XX と断片の数 ZZ ( = YY - XX + 1 ) になってます。
仕様書の日本語版は 澤田 豊 によります。 2014年 10月 2日