ISO 9660 CD-ROMファイルシステムの概要

最終更新: 1999.2.5


目次

  1. はじめに
  2. ボリューム構造とファイルシステムの概要
  3. メタデータの構造
  4. その他の機能
  5. 拡張仕様
  6. 混成フォーマット
  7. CD-ROMブート

表目次

  1. 情報交換の水準
  2. 数値の型名
  3. 日時情報(長形式)
  4. 日時情報(短形式)
  5. 基本ボリューム記述子・副ボリューム記述子
  6. ボリューム区画記述子
  7. 起動レコード
  8. ボリューム記述子集合終端子
  9. パステーブルレコードの順序の例
  10. パステーブルレコード
  11. ディレクトリレコード
  12. ファイルフラグ
  13. 拡張属性レコード
  14. 許可条件

1. はじめに

本稿では、ISO 9660に規定されたCD-ROMのファイルシステムと、関連する 諸仕様について技術的に解説します。

ISO 9660は以下のような特徴を持ちます。

以下のように情報交換の水準(§10)が定められています。水準3がフルスペッ クとなります。一般に使われているのは水準1です。

情報交換の水準
水準 1 2 3
ファイル識別子 8+3文字 30文字 30文字
ディレクトリ識別子 8文字 31文字 31文字
ファイル分割 不可 不可

2. ボリューム構造とファイルシステムの概要

ここでは、ISO 9660の基本的な内容について解説します。 通常あまり使われない機能については、後述します。

CD-ROMのボリュームは、先頭から順に以下のような要素で構成されます。

2.1 システムエリア

先頭の16セクタはシステム用に予約されています(§6.2.1)。

2.2 ボリューム記述子

システムエリアに続いていくつかのボリューム記述子が並びます(§6.7)。 各ボリューム記述子は1セクタを占める構造体で、 ボリュームに関する情報(ボリュームや作成者の名前、 パステーブルやルートディレクトリの位置、 ブート情報など)を保持します。

PVDとボリューム記述子集合終端子は必須です。 同じ内容の記述子が重複して記録される場合もあります。

2.3 パステーブル

パステーブル(Path Table)とは、 ボリューム中の全ディレクトリの情報(ディレクトリ名、位置、親ディレクトリなど)を 幅優先検索(breadth first search)順に並べたテーブルで、 高速なディレクトリ検索のために利用されます。 CD-ROMはシークが遅いので、サブディレクトリを検索する際、 一般のファイルシステムのように、 散在する各サブディレクトリを順に一つずつたどっていったのでは、 非常に時間がかかってしまいます。 パステーブルはコンパクト(通常は1〜数セクタ程度)なので、 常時キャッシュしておくことにより高速にアクセスできます。 また、パステーブル中のディレクトリの配列も高速検索に適した配列になっています。 さらに、もし書き込み可能なメディアであれば、 ディレクトリの作成・削除・リネーム・移動などのたびに パステーブルを動的に再構築しなくてはなりませんが、 CD-ROMは読み取り専用ですから、 マスタリング時に静的に作成するだけで済みます。

パステーブルには、L形とM形があります。 両者は基本的に同じものですが、記録される数値のバイトオーダーが異なります (L形はリトルエンディアン、M形はビッグエンディアン)。 通常、両方のパステーブルが存在し、 読み出すシステムが都合の良い方を使えるようになっています(§6.9.2)。

また、L形とM形のそれぞれについて、コピーを1個余計に置くことができま す。これを任意パステーブル(Optional Path Table)といいます(§6.9.2)。

ボリューム中のパステーブルの位置はとくに規定されていませんが、 通常はボリューム記述子群の直後に置かれます。

2.4 ディレクトリ

ディレクトリは、一般のファイルシステムと同様、 ファイルやサブディレクトリに関する以下のような情報を保持します。

ファイルはエクステントに記録され、 読み取り専用のためフラグメンテーションも起きないので、 ファイルの位置を特定する情報としては、 先頭のセクタ番号とファイルサイズだけでよく、 FATのようなリンク情報は必要としません。

ディレクトリ階層の深さは、ルートディレクトリをレベル1として、 レベル8まで許されます。 また、ファイル名を含むフルパス名の長さは255バイトまでです(§6.8.2)。 もっとも、水準1では以下の通り82バイトが最長です。

/LEVEL_02/LEVEL_03/LEVEL_04/LEVEL_05/LEVEL_06/LEVEL_07/LEVEL_08/FILENAME.EXT;32767

2.5 ファイル

水準1と2では、各ファイルは、 単一のエクステントに記録されます。


3. メタデータの構造

ボリュームおよびファイルシステムを構成するメタデータの具体的なフォーマットを示します。

3.1 データ型の表記

ここではデータ型を以下のように表記します。

3.2 ボリューム記述子

3.2.1 基本ボリューム記述子(PVD)・副ボリューム記述子(SVD)

PVDとSVDの構造は以下の通りです(§8.4、8.5、表4、表5)。

基本ボリューム記述子・副ボリューム記述子
オフセット 内容・備考
0 uint8 ボリューム記述子種別 1(PVD)/2(SVD)
1〜5 dstr(5) 規格識別子(*) "CD001"
6 uint8 ボリューム記述子版数 1
7 8ビット ボリュームフラグ(SVDのみ) ビット0 : ISO 2375登録外のエスケープシーケンスが含まれる(1)/ 含まれない(0)
ビット1〜7 : 予約
8〜39 astr(32) システム識別子
40〜71 dstr(32) ボリューム識別子 DOS等ではボリュームラベルとして見える
72〜79 8バイト (未使用)(*) 0
80〜87 uint32both ボリューム空間の大きさ(*) ボリューム空間の論理ブロック数
88〜119 string(32) エスケープシーケンス(SVDのみ) G0/G1図形文字集合を指示(ESC省略)
120〜123 uint16both ボリューム集合の大きさ(*)
124〜127 uint16both ボリューム順序番号(*)
128〜131 uint16both 論理ブロック長(*) 論理ブロックのバイト数(通常2048)
132〜139 uint32both パステーブルの大きさ パステーブルのバイト数
140〜143 uint32le L形パステーブルの位置 先頭LBN
144〜147 uint32le 任意L形パステーブルの位置 先頭LBN
148〜151 uint32be M形パステーブルの位置 先頭LBN
152〜155 uint32be 任意M形パステーブルの位置 先頭LBN
156〜189 ディレクトリレコード ルートディレクトリ用ディレクトリレコード
190〜317 dstr(128) ボリューム集合識別子
318〜445 astr(128) 出版者識別子 _で始まる場合はファイル識別子
446〜573 astr(128) データ編集者識別子 _で始まる場合はファイル識別子
574〜701 astr(128) 応用システム識別子 _で始まる場合はファイル識別子
702〜738 fileid(37) 著作権ファイル識別子
739〜775 fileid(37) 抄録ファイル識別子
776〜812 fileid(37) 書誌ファイル識別子
813〜829 datetime_l ボリューム作成日付及び時刻(*)
830〜846 datetime_l ボリューム更新日付及び時刻(*)
847〜863 datetime_l ボリューム失効日付及び時刻(*)
864〜880 datetime_l ボリューム発効日付及び時刻(*)
881 uint8 ファイル構造版数(*) 1
883 1バイト (予約)(*) 0
884〜1394 511バイト 応用システム用 --
1395〜2047 653バイト (予約)(*) 0

(*)これらの欄の内容は、ボリューム中のすべてのPVDおよびSVDで同一 でなければならない。

3.2.2 ボリューム区画記述子

ボリューム区画記述子の構造は以下の通りです(§8.6、表7)。

ボリューム区画記述子
オフセット 内容・備考
0 uint8 ボリューム記述子種別 3
1〜5 dstr(5) 規格識別子 "CD001"
6 uint8 ボリューム記述子版数 1
7 1バイト (未使用) 0
8〜39 astr(32) システム識別子
40〜71 dstr(32) ボリューム区画識別子
72〜79 uint32both ボリューム区画の位置 先頭LBN
80〜87 uint32both ボリューム区画の大きさ 論理ブロック数
88〜2047 1960バイト システム用

3.2.3 起動レコード

起動レコードの構造は以下の通りです(§8.2、表2)。

起動レコード
オフセット 内容・備考
0 uint8 ボリューム記述子種別 0
1〜5 dstr(5) 規格識別子 "CD001"
6 uint8 ボリューム記述子版数 1
8〜38 astr(32) 起動システム識別子
39〜70 astr(32) 起動識別子
71〜2047 1977バイト 起動システム用

3.2.4 ボリューム記述子集合終端子

ボリューム記述子集合終端子の構造は以下の通りです(§8.3、表3)。

ボリューム記述子集合終端子
オフセット 内容・備考
0 uint8 ボリューム記述子種別 255
1〜5 dstr(5) 規格識別子 "CD001"
6 uint8 ボリューム記述子版数 1
7〜2047 2041バイト (予約)

3.3 パステーブル

ISO 9660の特徴の一つであるパステーブルは、 ボリューム中の全ディレクトリについて、 パステーブルレコードを作成し、これを並べたものです。 各レコードには1からの通し番号が暗黙のうちに振られ、 親ディレクトリを示すのにこの番号を使います。 並べ方の規則は以下の通りです(§6.9.1)。

  1. ディレクトリ階層のレベル(1〜8)の順。
  2. 同じレベルの中では、親ディレクトリのディレクトリ番号の順。
  3. 同じ親ディレクトリを持つものの中では、ディレクトリ識別子の文字コードの順。

例えば、以下のようなディレクトリ階層がある場合、

/BIN
/USR/BIN
/USR/LOCAL
/USR/TMP
/VAR/LOG
/VAR/SPOOL
/VAR/TMP
/ETC

パステーブルレコードの順序は以下のようになります。 先頭(番号1)は常にルートディレクトリになることに注意してください。

パステーブルレコードの順序の例
番号 レベル 親の番号 (パス) 識別子 フルパス
1 1 1 (/) 00 /
2 2 1 (/) BIN /BIN
3 ETC /ETC
4 USR /USR
5 VAR /VAR
6 3 4 (/USR) BIN /USR/BIN
7 LOCAL /USR/LOCAL
8 TMP /USR/TMP
9 5 (/VAR) LOG /VAR/LOG
10 SPOOL /VAR/SPOOL
11 TMP /VAR/TMP

ここで、たとえば/USR/TMP/README.TXT;1というファイルを検索する手順は、以下のようになります。

  1. レベル1のパステーブルレコード群の中で、ルートディレクトリを検索する。 番号は1である。(実際にはここは自明なので省略可能)
  2. レベル2のパステーブルレコード群の中で、番号1を親に持ち(レベル2の親はすべてルートなのでここも自明)、 USRという識別子のものを検索する。その番号は4である。
  3. レベル3のパステーブルレコード群の中で、番号4を親に持ち、 TMPという識別子のものを検索する。その番号は8である。
  4. /USR/TMPを表す8番のパステーブルレコードから、 ディレクトリ本体が格納されている位置を取得し、ディレクトリ本体を読み出す。
  5. 読み出したディレクトリレコード群の中から、 README.TXT;1というファイルを検索する。

このように、ディレクトリの検索はパステーブルを先頭から順に検索するだけで済み、 ディスク上に散在するサブディレクトリを一つずつたどる必要はありません。

パステーブルレコードの構造は以下の通りです(§9.4、表11)。

パステーブルレコード
オフセット 内容・備考
0 uint8 ディレクトリ識別子の長さ(LEN_DI)
1 uint8 拡張属性レコードの長さ
2〜5 uint32le/be(*) エクステントの位置
6〜7 uint16le/be(*) 親ディレクトリの番号
8〜 fileid(LEN_DI) ディレクトリ識別子
8+LEN_DI uint8 埋込み LEN_DIが奇数の場合のみ

(*)L形パステーブルではle、M形パステーブルではbeを使用

3.4 ディレクトリレコード

ディレクトリは、一般のファイルシステムと同様、 ディレクトリレコードと呼ばれるデータ構造を並べたものです。 ディレクトリ中のディレクトリレコードは、あらかじめソートしておきます。 ソートの優先順位は以下の通りです(§9.3)。

  1. ファイル名の文字コードの順(昇順)
  2. ファイル拡張名の文字コードの順(昇順)
  3. ファイル版数番号の順(降順)
  4. 関連ファイル→主ファイル
  5. ファイル中のファイル分割の順

ディレクトリレコードの構造は以下の通りです(§9.1、表8)。

ディレクトリレコード
オフセット 内容・備考
0 uint8 ディレクトリレコードの長さ(LEN_DR)
1 uint8 拡張属性レコードの長さ
2〜9 uint32both エクステントの位置
10〜17 uint32both データ長
18〜24 datetime_s 記録日付及び時刻
25 8ビット ファイルフラグ
26 uint8 ファイルユニットの大きさ
27 uint8 インタリーブ間隙の大きさ
28〜31 uint16both ボリューム順序番号
32 uint8 ファイル識別子の長さ(LEN_FI)
33〜 fileid(LEN_FI) ファイル/ディレクトリ識別子
33+LEN_FI uint8 埋め込み LEN_FIが偶数の場合のみ

LEN_SUバイト システム用 任意、偶数バイト

ファイルフラグの形式は以下の通りです(§9.1.6、表10)。

ファイルフラグ
ビット位置 ビット名 内容・備考
0 存在 不可視ファイル(1)/可視ファイル(0)
1 ディレクトリ ディレクトリ(1)/ファイル(0)
2 関連ファイル 関連ファイル(1)/主ファイル(0)
3 レコード ファイルがレコード形式をもつ(1)/もたない(0)
4 保護 許可条件有効(1)/無効(0)
5〜6 確保 予約(0)
7 複数エクステント ファイルの最終ディレクトリレコードでない(1)/ある(0)

4. その他の機能

ここでは、今までに解説しなかった機能について簡単に見ていきます。

4.1 関連ファイル

ISO 9660には、関連ファイル(associated file)という機能があります(§6.5.4)。 この機能そのものを説明する前に、まずはその利用例から考えてみましょう。

MacOSのファイルは、データフォーク・リソースフォークと呼ばれる2つの構成要素からなります。 前者はファイルのデータそのものであり、後者はMacOSに特有のリソースと呼ばれる付加情報(アイコンなど)です。 MacOS上では、両者をまとめて一つのファイルとして扱い、ユーザーがその区別を意識することはありません。 しかし、リソースフォークはMacOS上でしか意味をもちませんので、 他のシステムとのデータ交換の際には、データフォークのみを交換するのが普通です。

ISO 9660によるクロスプラットフォームの情報交換を考えた場合、 MacOSとの情報交換を容易にするためには、 データフォークとリソースフォークをそれぞれ別個のファイルとして記録しておき、 MacOSでは両者を一つのファイルとして扱い、 他のシステムではデータフォークだけを扱うことができると便利です。 しかも、この2つは独立した無関係なファイルではなく、 特別な関係をもったファイルであることを示す必要があります。 関連ファイルの機能を使うと、このようなことを実現できます。

関連ファイルとは、CD-ROM上のある特定のファイルに対して、 別のあるファイルを「関連づけ」する機能のことであり、 また、関連づけしたファイルそのもののことです。 関連ファイルに対して、もう一方の、関連づけの対象となった方のファイルのことを、 ここでは主ファイルと呼ぶことにします。 二つのファイルは同じファイル識別子を持ち、 同一ディレクトリ中に隣接して配置され(関連ファイル→主ファイルの順)、 ディレクトリレコード中のファイルフラグの関連ファイルビットによって区別されます。 「関連づけ」が具体的にどのような意味を持つかは、ISO 9660では規定せず、 上位のOSやアプリケーションに任されます。

上記の例にあてはめると、データフォークを主ファイルとし、 リソースフォークを関連ファイルとして関連づけます。 MacOSでは関連ファイルと主ファイルの両方をまとめて一つのファイルのように取り扱い、 その他のシステムでは主ファイルのみを取り扱うことにすれば、問題なくデータ交換が実現できます。

このように、関連ファイルは、MacOSのリソースフォークを収容するために導入されたものと思われ、 これを利用した拡張仕様をAppleが規定していますが、 実際のMacOS用CD-ROMでは、ISO 9660を使わずにHFSをそのまま記録するのが一般的なので、 関連ファイルはほとんど使われていないようです。

関連ファイルは、MS-DOS/Windowsからは見えません。 FreeBSDでは、ファイル名の先頭に=がついた形で見えます。

4.2 拡張属性レコードと許可条件

拡張属性レコード(XAR)とは、ファイルに付加することのできる追加の属性情報です。 主に、UNIX(POSIX)風の属性情報と、ファイル本体のレコードの情報を含んでいます。

拡張属性レコードは、ファイル分割の前に置かれ、 その構造は以下の通りです(§9.5、表12)。

拡張属性レコード
オフセット 内容・備考
0〜3 uint16both 所有者識別情報
4〜7 uint16both グループ識別情報
8〜9 16ビット 許可条件
10〜26 datetime_l ファイル作成日付及び時刻
27〜43 datetime_l ファイル更新日付及び時刻
44〜60 datetime_l ファイル失効日付及び時刻
61〜77 datetime_l ファイル発効日付及び時刻
78 8ビット レコード形式
79 8ビット レコード属性
80〜83 uint16both レコード
84〜115 astr(32) システム識別子
116〜179 64バイト システム用
180 uint8 拡張属性レコードの版数
181 uint8 エスケープシーケンスの長さ(LEN_ESC)
182〜245 64バイト (予約) 0
246〜249 uint16both 応用システム用欄の長さ(LEN_AU)
250〜 LEN_AUバイト 応用システム用
250+LEN_AU〜 LEN_ESCバイト エスケープシーケンス

許可条件は以下の通りです(§9.5.3、表13)。

許可条件
ビット位置 ユーザーのクラス 内容・備考
ビット0 システム 読み取り可能(0)/不能(1)
ビット1 1
ビット2 実行可能(0)/不能(1)
ビット3 1
ビット4 所有者 読み取り可能(0)/不能(1)
ビット5 1
ビット6 実行可能(0)/不能(1)
ビット7 1
ビット8 グループ 読み取り可能(0)/不能(1)
ビット9 1
ビット10 実行可能(0)/不能(1)
ビット11 1
ビット12 その他 読み取り可能(0)/不能(1)
ビット13 1
ビット14 実行可能(0)/不能(1)
ビット15 1

この許可条件は、所有者・グループ情報とともに、 UNIXのファイルパーミッションを表すために導入されたものと思われます。 しかし、実際のUNIX用CD-ROMでは、この機能を使わず、 RockRidge拡張によって規定された方法でパーミッション情報を保持するのが一般的です。

4.3 レコード

(§6.10)

4.4. ファイル分割

4.5 インタリーブモード

(§6.4.3)


5. 拡張仕様

ISO 9660はファイル名などに強い制限があるため、 他のファイルシステムの情報をもれなく収容するためには、 ISO 9660を拡張する必要が生じます。 ここでは、そのような拡張のうち、主なものをとりあげます。

5.1 RockRidge Extensions

RockRidge Extensions (RockRidge Interchange Protocol)とは、 UNIX(POSIX)のファイルシステムの情報を収容するための仕様です。

UNIX(POSIX)のファイルをISO 9660で記録する場合、以下のような問題点があります。

RockRidgeを使用すると、 ISO 9660との互換性を保ちながら上記の問題点を解決することができます。 現在、RockRidgeは主要なUNIXシステムでサポートされており、 多くのUNIX用CD-ROMで使われています(OSのブートCDなど特殊なものを除く)。

なお、RockRidgeのCD-ROMには、各ディレクトリにTRANS.TBLというファイル(または似たような名前のファイル)があり、 RockRidgeによるファイル名とISO 9660水準1のファイル名の対応が記録されています。 ただし、このファイルは、RockRidgeに対応していないシステムに便宜を図る目的で用意されているもので、 RockRidgeに対応したシステムでは参照されません。

5.2 Romeo Extensions

Romeo Extensionsとは、Windows 95やWindows NTの長いファイル名を収容するための仕様です。 AdaptecののCD-Rマスタリングソフトなどで作成できます。 特徴は以下のとおりです。

5.2 Joliet Extensions

Joliet Extensionsとは、Romeo Extensionsと似た仕様ですが、 長いファイル名にUnicodeを使用します。Microsoftが提唱しています。 特徴は以下の通りです。


6. 混成フォーマット

6.1 ハイブリッドCD-ROM

6.2 マルチセッション

6.3 ミックスモードCDとCD Extra

別記事を参照してください。


7. CD-ROMブート

CD-ROMからのブートは、UNIXワークステーションでは当然の機能ですが、 PCでは長らく実現していませんでした。 最近になってようやく仕様が策定され、対応したシステムやCD-ROMが登場してきました。 ここでは、PCにおけるCD-ROMブートの仕様であるEl Torito仕様について簡単に解説します。


参考文献

Data Interchange on Read-only 120 mm Optical Data Disks (CD-ROM) (ISO 10149, ECMA 130)

CD-ROMの物理的なフォーマットについて。

Volume and File Structure of CD-ROM for Information Interchange (ISO 9660, ECMA 119, JIS X 0606)

本稿で解説した、CD-ROMのボリューム構造とファイル構造について。

CD-R FAQ

CD-Rに関するFAQリスト。

Young Minds, Inc.

RockRidge Interchange Protocol 1.12とSystem Use Sharing Protocol 1.12のドラフト。

Joliet Specification
Developers spell relief J-o-l-i-e-t.

Jolietの仕様書。

ISO 9660 (& High Sierra) CD-ROM Format

ISO 9660またはHigh SierraフォーマットのCD-ROMがMacOSでうまく扱えない場合の原因をあげています。

Apple Extensions to ISO 9660

MacOSのファイルをISO 9660フォーマットのCD-ROMに格納するための拡張について。

El Torito Bootable CD-ROM Format Specification

El Torito仕様の仕様書。

The UN-Official Boot CD FAQ
Bootable CDの作り方
How To Make a Bootable CD

El Toritoによるブート可能CDの作り方など。

Caffarelli & Straughan: Publish Yourself on CD-ROM
邦訳: 岩谷宏訳、 マルチメディアクリエイターのためのCD-ROMメイキングマニュアル、 VC出版局

CD-ROMタイトルのオーサリングに関するガイド。ISO 9660について本稿と同じような解説があります。

mkhybrid

UNIXやWin32でISO 9660/RockRidge/Jolietイメージを作成するツールmkisofsを、 Mac HFSとのハイブリッド対応にしたツールです。

Multimedia Storage

CD-ROM関連のPDF文書が集積されています。


用語集

論理セクタ(§6.1.2)

CD-ROMの物理セクタ(通常2048バイト)上に構成する論理的なセクタ。 論理セクタのサイズは、 物理セクタサイズが2048バイト以上の場合はそれを超えない最大の2048の倍数、 物理セクタサイズが2048バイト未満の場合は2048バイトとなる。 後者の場合、論理セクタは複数の物理セクタにまたがる。 いずれの場合も論理セクタの先頭は物理セクタの先頭に整列される。 現実には、論理セクタサイズはほとんどの場合2048バイトである。

論理ブロック(§6.2.2)

論理セクタをさらに分割した単位。 サイズは512バイトの倍数で、論理セクタサイズ以下である。 サイズは基本/副ボリューム記述子に記録されている。 通常は、論理セクタ=論理ブロック=2048バイトなので、 本稿では簡便のため両者を厳密に区別していない。

エクステント(§4.6、6.4)

連続する論理ブロックの集まり。 データエリア中のパステーブル、ディレクトリ、ファイルなどはそれぞれエクステントとして記録される。

ファイル分割(file section)(§4.8)
d文字、d1文字、a文字、a1文字(§7.4)

d文字とd1文字は、ファイル識別子、ディレクトリ識別子、 ボリューム識別子などに使うことのできる文字である。 a文字とa1文字は、その他の記述的な識別子に使うことのできる文字である。

d文字とa文字は、基本ボリューム記述子およびそこからたどれるパステーブルとディレクトリ中で用いる。 d1文字とa1文字は、副ボリューム記述子およびそこからたどれるパステーブルとディレクトリ中で用いる。

d文字は、ASCIIの英大文字・数字・アンダースコア(_)で、 a文字はd文字に以下の文字を加えたものであり、 ISO 646 invariantsから英小文字を除いたものに等しい。

2列の文字 ! " % & ' ( ) * + , - . /
3列の文字 : ; < = > ?

副ボリューム記述子のエスケープシーケンスで指示された文字集合をc文字といい、 d1文字およびa1文字は以下の関係にある。

d1文字 ⊂ a1文字 ⊂ c文字

d1文字およびa1文字の具体的な内容は、情報交換当事者の合意による。


Copyright (C) 1998 ITO Takayuki, All rights reserved.

伊藤隆幸のホームページ