RAR (4.x) ファイル形式
RAR 1.5〜4.x 形式の RAR アーカイブ。
- MIME タイプ
- application/x-rar-compressed
- 拡張子
- .rar
- カテゴリ
- アーカイブ・圧縮
マジックナンバー（ファイル署名）
| 0x00000000 | 526172211A0700 | Rar!··· | 'Rar!' RAR4 signature |
RAR (4.x) 形式について
RAR 4.x は WinRAR 1.5 から 4.20 が生成していた旧世代の形式で、互換性優先を指定すると今でも書き出されます。ファイル内のすべてがブロックであり、どのブロックも 16 ビット CRC、1 バイトのタイプ、16 ビットのフラグ、16 ビットのサイズという同じ 4 フィールドで始まります。オフセット 0 の 7 バイトマーカーが単なるマジックナンバーではなくブロックそのものなのはこのためです。形式は独自仕様で、展開側は公開されている一方で圧縮側は公開されていません。だからフリーのツールは RAR 4 を読めても書けません。
ヘッダーの構造（バイト単位）
| オフセット | 長さ | フィールド | 意味 |
|---|---|---|---|
| 0 | 7 | Marker block (MARK_HEAD) | 常に 52 61 72 21 1A 07 00 で、'Rar!' に 1A 07 00 が続きます。裸のマジックナンバーではなく、中身がたまたま定数になっている通常の RAR ブロックです（HEAD_CRC 0x6152、HEAD_TYPE 0x72、HEAD_FLAGS 0x1A21、HEAD_SIZE 0x0007）。RAR5 は最初の 6 バイトをそのまま使って 01 00 を足しただけなので、オフセット 6 のバイトが 2 世代を分ける唯一の違いです。 |
| 7 | 2 | Archive header CRC (HEAD_CRC) | このブロックの残り全体に対する CRC-32 の下位 16 ビットです。RAR のブロックはすべてこれを持つので、破損があってもアーカイブ全体を諦めずにブロック単位まで絞り込めます。 |
| 9 | 1 | Archive header type (HEAD_TYPE) | 0x73 が MAIN_HEAD、つまりアーカイブ全体のヘッダです。他によく出会うのは 0x74（ファイル）、0x75（コメント）、0x7A（サブブロック）、0x7B（アーカイブ終端マーカー）です。 |
| 10 | 2 | Archive header flags (HEAD_FLAGS) | リトルエンディアンのビットフィールド。0x0001 = セットの 1 巻、0x0002 = アーカイブコメントを内包、0x0004 = 変更ロック済み、0x0008 = ソリッド、0x0010 = 新しい name.partN.rar 式のボリューム命名、0x0040 = リカバリレコードあり、0x0080 = ブロックヘッダ自体が暗号化済み、0x0100 = 最初のボリューム。 |
| 12 | 2 | Archive header size (HEAD_SIZE) | 既に読んだ 6 バイトを含む、このブロック全体の長さです。素の場合は 0x000D（13 バイト）なので次のブロックはオフセット 20 から始まります。コメントや認証レコードが入るとこれが大きくなり、以降すべてが後ろへずれます。 |
| 14 | 2 | RESERVED1 | 予約領域。リリースされたすべてのバージョンがゼロを書きます。歴史的には、ごく初期のビルドでボリューム番号の上位ワードを入れていました。 |
| 16 | 4 | RESERVED2 | 予約領域でゼロが入ります。アーカイブヘッダをおなじみの 13 バイトに保つための 4 バイトのパディングです。 |
| 20 | 2 | First file header CRC | 最初の FILE_HEAD ブロックの先頭 — ただし上のアーカイブヘッダが最小の 13 バイトだった場合に限ります。20 を無条件に信じるのではなく、オフセット 12 の HEAD_SIZE を読んで 7 に足してください。以下の行のオフセットもすべて同じ前提の上に乗っています。 |
| 22 | 1 | File header type (HEAD_TYPE) | 0x74。ここが 0x7B ならアーカイブは空です。そのバイトはアーカイブ終端ブロックだからです。 |
| 23 | 2 | File header flags | 0x0001 = 前のボリュームからの続き、0x0002 = 次のボリュームへ続く、0x0004 = パスワード保護、0x0100 = 64 ビットサイズの上位ワードあり、0x0200 = 名前をローカルコードページに加えて UTF-16 でも格納、0x0400 = 名前の後ろに 8 バイトの salt が続く。 |
| 25 | 2 | File header size (HEAD_SIZE) | このヘッダ全体の長さで、32 バイトの固定フィールドに名前と、あれば salt や拡張タイムスタンプを足したものです。圧縮データはこの直後から始まります。 |
| 27 | 4 | PACK_SIZE | このエントリの圧縮後バイト数の下位 32 ビット。4 GiB を超えるファイルは上位ワードを ATTR フィールドの直後に別途持ちますが、これはフラグ 0x0100 が立っているときだけです。 |
| 31 | 4 | UNP_SIZE | 元のバイト数の下位 32 ビットで、4 GiB の抜け道も同じです。ソリッドアーカイブでも、そのエントリ単独では展開できないにもかかわらず、ここには実際の値が記録されます。 |
| 35 | 1 | HOST_OS | エントリを作成したシステム: 0 = MS-DOS、1 = OS/2、2 = Windows、3 = Unix、4 = Mac OS、5 = BeOS。この値が、後ろにある 4 バイトの属性をどう解釈するかを決めます。 |
| 36 | 4 | FILE_CRC | 非圧縮の中身に対する CRC-32。WinRAR が出す「チェックサムエラー」の正体はこの数値であり、リカバリレコードが修復を狙っている対象でもあります。 |
| 40 | 4 | FTIME | MS-DOS のパック形式の日付と時刻です。1980 年起点の年 7 ビット、月 4 ビット、日 5 ビット、続いて時 5 ビット、分 6 ビット、2 秒刻みの秒 5 ビット。タイムゾーンなし、分解能は 2 秒、1980 年より前は表現できません。 |
| 44 | 1 | UNP_VER | 必要な展開側の最小バージョンを 10 倍した値です。20 なら 2.0 のアルゴリズム、29 なら WinRAR 3.x / 4.x が使う 2.9 のもの。今の展開ツールはすべて実装しているので、このバイトが効いてくるのは古いツールがファイルを拒否したときです。 |
| 45 | 1 | METHOD | 0x30 = 無圧縮、0x31 = 最速、0x32 = 高速、0x33 = 標準、0x34 = 高圧縮、0x35 = 最高圧縮。0x30 のエントリはヘッダの後ろがファイルそのものなので、壊れたアーカイブからでも手作業で切り出せます。 |
| 46 | 2 | NAME_SIZE | 固定フィールドの後ろに続く名前のバイト長です。フラグ 0x0200 が立っているときは、この領域にローカルコードページの名前、ゼロバイト、そして同じ名前を圧縮した UTF-16 形式が順に入ります。 |
| 48 | 4 | ATTR | ファイル属性。HOST_OS に従って解釈され、Windows なら DOS の属性ビット、Unix なら Unix の mode ワードです。RAR がフォルダのエントリ（データを一切持たない）を示すのも、ここのディレクトリビットです。 |
| 52 | variable | FILE_NAME | NAME_SIZE バイトのパス。区切りはスラッシュではなくバックスラッシュです。ドライブレターで始まる名前や .. を含む名前はパストラバーサルの試みなので、まともな展開ツールなら拒否します。 |
似た形式との見分け方
| 紛らわしい形式 | 見分け方 |
|---|---|
| RAR5 | 2 世代は 6 バイトを共有し、7 バイト目で分かれます。RAR 4 は 7 バイトの 52 61 72 21 1A 07 00、RAR 5 は 8 バイトの 52 61 72 21 1A 07 01 00。どちらも拡張子は .rar で出どころも WinRAR なので、2005 年のツールで開けるアーカイブと開けないアーカイブを分けているのは、オフセット 6 のこのバイトだけです。中身のほうは RAR 5 でブロックレイアウトごと可変長整数に置き換わったため、マーカーより下は何も引き継がれていません。 |
| ZIP | バイト単位では紛らわしい点は皆無で、52 61 72 21 対 50 4B 03 04 です。それでも混同され続けるのは、どちらも「圧縮フォルダ」だからでしょう。実務上効くのは構造の違いのほうです。ZIP は末尾にディレクトリを持ち、最後の数百バイトから一覧できます。RAR は先頭からブロックの鎖をたどるので、末尾が切れた RAR は正しく一覧できるのに、ZIP はできません。 |
| 7-Zip | 7-Zip のアーカイブは 37 7A BC AF 27 1C で始まります。ソリッド圧縮も強力な暗号化もどちらの形式にもあり、しかもアプリの 7-Zip は両方を扱うので混乱が始まります。.7z の形式はオープンで誰でも実装できますが、RAR の圧縮はそうではありません。.7z を作れるツールが .rar も作れるとは限らないということです。 |
| Self-extracting RAR | SFX アーカイブは Windows の実行ファイルの後ろに RAR データをくっつけたものなので、オフセット 0 は 4D 5A（'MZ'）で、'Rar!' マーカーは数千バイト先に現れます。それでも完全に正当なアーカイブです。まともな展開ツールを向ければ、オフセット 0 にこだわらず前方へマーカーを探しに行きます。 |
よくある壊れ方
- マルチボリュームセットの 1 巻が欠けている。各パートはそれ自体が整形式の RAR なので、hex ダンプではマーカーもブロック CRC も綺麗に見えます。それでも展開に失敗するのは、0x0002 フラグの付いたエントリが「そこにないパート」へ続いているからです。見分け方は、オフセット 10 のアーカイブヘッダでビット 0x0001 が立っていて、かつ .partN.rar の番号に抜けがあること。
- ダウンロードの途中切れ。RAR はオフセット 7 から前方へブロックをたどるので、切れた位置までは普通に展開でき、失敗は最後のエントリだけに現れます。リカバリレコードがある場合（アーカイブヘッダのフラグ 0x0040）、WinRAR は失われた部分を驚くほど復元できます。RAR が ZIP に対して保ち続けている唯一の実質的な優位です。
- テキストモード転送。ASCII モードの FTP クライアントは圧縮ストリーム内の 0D 0A をすべて書き換えますが、マーカーもオフセットも無傷のままです。だから一覧は完璧に表示され、その後で各エントリがオフセット 36 の FILE_CRC で失敗します。これがパスワード間違いと取り違えられる典型的な症状です。
- ヘッダ暗号化を破損と勘違いする。-hp を使うとブロックヘッダ自体が暗号化されるため、オフセット 20 から先の hex ダンプはノイズにしか見えず、ファイル名も一切出てきません。本物の破損と区別する手がかりはオフセット 10 のアーカイブヘッダフラグ 0x0080 で、これが立っているアーカイブはまったく無傷です。
- ブロックヘッダ内の 1 バイト反転。オフセット 25 の HEAD_SIZE が次のブロックの開始位置を示しているため、このフィールドが壊れると 1 エントリが壊れるでは済みません。走査そのものが脱線し、以降のブロックが全部でたらめな位置から読まれます。読み手が迷子になる前にそれを捕まえるのが 16 ビットの HEAD_CRC です。
この形式の現在地
RAR 4 は惰性と、たった 1 つの本物の技術的優位によって延命されているレガシー形式です。比重が大きいのは惰性のほうで、1998 年から 2012 年あたりに出回った大量のリリース、古いバックアップセット、そのほとんどが RAR 4 のマルチボリュームです。そしてそれらが再パックされることはまずありません。優位のほうはリカバリレコードで、光学メディアのビット腐食や不安定な転送をアーカイブが生き延びられる。ZIP にも 7z にも tar.gz にもできない芸当です。それ以外の軸では負けています。7-Zip も Zstandard も圧縮率で上回り、しかもオープンです。RAR の圧縮は依然として独自仕様なので、.rar を吐くビルドパイプラインは 1 社のツールに縛られたことになります。2013 年に RAR 5 が 64 ビットサイズ・より強い暗号化・高速なリカバリレコードを引っさげて置き換え、WinRAR も既定では RAR 5 を書きます。今 RAR 4 を選ぶのは、受け取る側の展開ツールが古いと分かっているときだけです。
RAR (4.x) ファイルをこのサイトで開く
どれもブラウザ内で動きます。ファイルが端末から出ることはありません。
関連する形式
RAR (4.x) と混同しやすい形式です。先頭バイトを見比べてください。