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は以下のような特徴を持ちます。

• 主要なOS(ファイルシステム)との互換性が配慮されており、 特定のプラットフォームに依存しない。 そのかわり、ファイル名やディレクトリ名の文字種・文字数の制限が厳しい。
• 読み取り専用という特徴を生かし、 パステーブルによる検索の高速化を図ったり、 ファイルの部分共有を可能にしたりしている。
• 複数のディレクトリ階層・ファイル分割・インタリーブ記録・ 拡張属性・関連ファイルなどの拡張機能を使用できる。

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

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

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

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

• システムエリア(16セクタ)
• ボリューム記述子群
• パステーブル群
• ディレクトリとファイル

2.1 システムエリア

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

2.2 ボリューム記述子

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

• 基本ボリューム記述子(Primary Volume Descriptor, PVD)(§6.7.1.1)

  ボリュームに関する基本的な情報を含みます。 識別子はd文字・ a文字を使って記述します。

• 副ボリューム記述子(Supplementary Volume Descriptor, SVD)(§6.7.1.2)

  PVDとほとんど同じ構造を持ちます。 PVDで指定した以外のディレクトリ階層を構築したい場合や、 d文字・a文字以外の文字集合で 識別子を記述したい場合に記録します。

  SVDをもつCD-ROMを読み出す場合、必要に応じてPVDの代わりにSVDを使うことができます。 たとえば、MS-DOS用のISO 9660サポートモジュールであるMSCDEXでは、 /Kスイッチ(シフトJIS漢字サポート)を指定した場合、 CD-ROM上にシフトJISを使用したSVDがあれば、PVDの代わりにそれを使います。

• ボリューム区画記述子(§6.7.1.3)

  ボリューム区画の情報を含みます。

• 起動レコード(§6.7.1.4)

  CD-ROMブートのための情報を含みます。

• ボリューム記述子集合終端子(§6.7.1.5)

  ボリューム記述子群の最後を示します。

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 ディレクトリ

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

• ファイル識別子/ディレクトリ識別子

  いわゆるファイル名/ディレクトリ名です。ファイル識別子(§7.5)は、

  ファイル名.ファイル拡張名;ファイル版数番号
  

  という形式です。 ファイル名とファイル拡張名に使える文字は、 d文字またはd1文字です。 最大文字数は、水準1ではMS-DOS FATファイルシステムと同様の8.3形式、 水準2と3では計30文字です。 ファイル名またはファイル拡張名のどちらか一方がなくてもかまいませんが、 区切りのピリオドは常に必要です。

  ファイル版数番号とは、 DECのVMSのようにファイルの履歴を保存できるシステムで使われるもので、 1〜32767の数値を数字で記述します。通常は1です。 DOS/Windows、MacOS、UNIXなど多くのシステムでは、 ファイルの履歴を保存できませんので、版数番号は意味がありません。 そのため、この部分を隠蔽してユーザーから見えないようにしているのが普通です (HP-UXを除く)。

  ディレクトリ識別子(§7.6)は、d文字またはd1文字で記述します。 最大文字数は、水準1では8文字、水準2と3では31文字です。 水準1の場合、ファイル識別子と違って、拡張名をつけることはできません。

  なお、特別なディレクトリ識別子として、00と01があります。 これらはそれぞれ、DOSやUNIXでいうところの.と..に相当します。 すなわち、ディレクトリ中の最初のディレクトリレコードは、 そのディレクトリ自身を表し、ディレクトリ識別子の先頭バイトは00となります。 また、2番目のディレクトリレコードは、親ディレクトリを表し、 ディレクトリ識別子の先頭バイトは01となります(§6.8.2.2)。

• エクステントの位置

  データの先頭のセクタ番号です。

• データ長

  データの占めるバイト数です。

• ファイルフラグ

  各種の属性を保持します(ファイル/ディレクトリの別、隠し属性、 関連ファイルの有無、パーミッションの有無など)。

• 記録日時
• その他

ファイルはエクステントに記録され、 読み取り専用のためフラグメンテーションも起きないので、 ファイルの位置を特定する情報としては、 先頭のセクタ番号とファイルサイズだけでよく、 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 データ型の表記

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

• 数値

  数値の型名

  型名	幅	型	§
  uint8	8ビット	8ビット符号なし数値	7.1.1
  sint8	8ビット	8ビット符号つき数値	7.1.2
  uint16le	16ビット	16ビット符号なし数値(リトルエンディアン)	7.2.1
  uint16be	16ビット	16ビット符号なし数値(ビッグエンディアン)	7.2.2
  uint16both	16ビット×2	16ビット符号なし数値(リトル&ビッグエンディアン)	7.2.3
  uint32le	32ビット	32ビット符号なし数値(リトルエンディアン)	7.3.1
  uint32be	32ビット	32ビット符号なし数値(ビッグエンディアン)	7.3.2
  uint32both	32ビット×2	32ビット符号なし数値(リトル&ビッグエンディアン)	7.3.3

• 文字列
  • dstr(n) : nバイトのd文字またはd1文字の文字列
  • astr(n) : nバイトのa文字またはa1文字の文字列
• ファイル/ディレクトリ識別子

  fileid(n) : nバイトのファイル/ディレクトリ識別子(§7.5、7.6)

• 日時
  • datetime_l : ボリューム識別子と拡張属性レコード中の日時情報(§8.4.26.1、表5)

    日時情報(長形式)

    オフセット	型	内容	範囲
    0〜3	dstr(4)	西暦年	"0000"〜"9999"
    4〜5	dstr(2)	月	"01"〜"12"
    6〜7	dstr(2)	日	"01"〜"31"
    8〜9	dstr(2)	時	"00"〜"23"
    10〜11	dstr(2)	分	"00"〜"59"
    12〜13	dstr(2)	秒	"00"〜"59"
    14〜15	dstr(2)	1/100秒	"00"〜"99"
    16	sint8	UTCからの偏差(15分単位)	-48〜+52 (-12時間〜+13時間)

  • datetime_s : ディレクトリレコード中の日時情報(§9.1.5、表9)

    日時情報(短形式)

    オフセット	型	内容	範囲
    0	uint8	西暦年-1900	0〜255(1900年〜2155年)
    1	uint8	月	1〜12
    2	uint8	日	1〜31
    3	uint8	時	0〜23
    4	uint8	分	0〜59
    5	uint8	秒	0〜59
    6	sint8	UTCからの偏差(15分単位)	-48〜+52 (-12時間〜+13時間)

3.2 ボリューム記述子

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

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

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

3.2.2 ボリューム区画記述子

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

3.2.3 起動レコード

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

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

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

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)は常にルートディレクトリになることに注意してください。

ここで、たとえば/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)。

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

3.4 ディレクトリレコード

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

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

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

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

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)。

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

この許可条件は、所有者・グループ情報とともに、 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で記録する場合、以下のような問題点があります。

• ファイル名/ディレクトリ名の文字種と文字数の制限が厳しい。
• ディレクトリ階層のレベルに制限がある。
• シンボリックリンクが記録できない。
• 所有者・パーミッションなどは拡張属性に記録できるが、 拡張属性はファイル本体の近くに置かれるため、 ls -lなどを実行すると大量のシーク動作が発生して遅くなるおそれがある。

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マスタリングソフトなどで作成できます。 特徴は以下のとおりです。

• 1バイト文字で128文字までの長いファイル名を記録できる。
• 長いファイル名はWindows 95以降とWindows NT 3.51以降で読み取り可能。
• ISO 9660水準2のファイル名も記録されており、他のシステムでも読みとれるが、 水準1ではないので、DOSなどでは読み取れない可能性がある。

5.2 Joliet Extensions

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

• Unicodeで64文字までの長いファイル名を記録できる。
• 長いファイル名はWindows 95以降とWindows NT 4.0以降でのみ読み取り可能。
• ISO 9660水準1のファイル名も記録されているので、 他の多くのシステムでも読み取り可能。

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.

伊藤隆幸のホームページへ