X 0614：2015
（1）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目 次
ページ
1 一般······························································································································· 1
1.0 適用範囲 ······················································································································ 1
1.1 構成 ···························································································································· 2
1.2 適合性 ························································································································· 2
1.3 参照 ···························································································································· 3
2 基本制約及び基本要件 ······································································································· 8
2.1 第1部 一般 ··············································································································· 10
2.2 第3部 ボリューム構造 ································································································ 17
2.3 第4部 ファイル構造 ··································································································· 39
2.4 第5部 レコード構造 ··································································································· 51
3 システム依存要件 ············································································································ 51
3.1 第1部 一般 ··············································································································· 51
3.2 第3部 ボリューム構造 ································································································ 52
3.3 第4部 ファイル構造 ··································································································· 53
4 利用者インタフェース要件 ································································································ 77
4.1 第3部 ボリューム構造 ································································································ 77
4.2 第4部 ファイル構造 ··································································································· 78
5 参考情報························································································································ 85
5.1 記述子長 ····················································································································· 85
5.2 処理システム用領域の使用 ····························································································· 86
5.3 起動記述子（Boot Descriptor） ························································································ 86
5.4 未記録セクタの明確化（Clarification of Unrecorded Sectors） ················································ 86
6 関連する規定 ·················································································································· 87
6.1 UDF実体識別記述子······································································································ 87
6.2 UDF実体識別子値 ········································································································ 87
6.3 オペレーティングシステム識別子（OS識別子） ································································· 87
6.4 OSTA圧縮Unicodeの圧縮アルゴリズム ············································································ 89
6.5 CRC計算 ···················································································································· 91
6.6 ICB方策種別4 096のアルゴリズム ·················································································· 93
6.7 識別子翻訳アルゴリズム ································································································ 94
6.8 拡張属性ヘッダチェックサムアルゴリズム（Extended Attribute Header Checksum Algorithm） ··· 110
6.9 DVD-ROMに関する要件 ······························································································· 111
6.10 CD媒体に関する勧告 ·································································································· 113
6.11 異なる媒体への記録での共通側面 ·················································································· 116
6.12 DVD-R，DVD-RW及びDVD-RAMの交換可能性に関する要件 ··········································· 119
X 0614：2015 目次
（2）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ページ
6.13 DVD+R及びDVD+RW媒体に関する勧告 ······································································· 122
6.14 マウントレイニアフォーマット媒体に関する勧告 ····························································· 124
6.15 疑似上書き可能機構の導入 ··························································································· 124
6.16 Blu-ray Disc媒体に関する勧告 ······················································································ 127
6.17 UDF媒体フォーマット改正履歴 ···················································································· 130
6.18 開発者登録フォーム ···································································································· 133
6.19 DVD-R DL LJR（マルチボーダ記録）に関する勧告 ·························································· 133
6.20 HD DVDディスクに関する要件····················································································· 134
附属書JA（参考）商標又は登録商標 ······················································································ 136
X 0614：2015
（3）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
まえがき
この規格は，工業標準化法第12条第1項の規定に基づき，一般財団法人光産業技術振興協会（OITDA）
及び一般財団法人日本規格協会（JSA）から，OSTA（Optical Storage Technology Association）による団体規
格Universal Disk Format Specification Revision 2.60:2005を基に作成した工業標準原案を具して日本工業規
格を制定すべきとの申出があり，日本工業標準調査会の審議を経て，経済産業大臣が制定した日本工業規
格である。
この規格は，著作権法で保護対象となっている著作物である。
この規格の一部が，特許権，出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意
を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許権，出願公開後の特許出願及び実
用新案権に関わる確認について，責任はもたない。
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格 JIS
X 0614：2015
ユニバーサルディスクフォーマット（UDF）2.60
Universal Disk Format (UDF) 2.60
1
一般
1.0
適用範囲
この規格は，JIS X 0607規格類（JIS X 0607:2001，ISO/IEC 13346-2，ISO/IEC 13346-3，ISO/IEC 13346-4
及びISO/IEC 13346-5）の部分集合として，UDF 2.60を規定する。データ交換を最大限にすること，並び
にJIS X 0607規格類を実施するためのコスト及び複雑さを最小限にすることを，その主な目的とする。
注記1 この規格で点線の下線を施してある参考事項は，対応団体規格にはない事項である。
注記2 この規格では，JIS X 0607規格類に含まれるJIS X 0607:2001を第1部，ISO/IEC 13346-2を
第2部，ISO/IEC 13346-3を第3部，ISO/IEC 13346-4を第4部，ISO/IEC 13346-5を第5部
と呼ぶ。
注記3 JIS X 0611で規定するUDF 2.01，JIS X 0613で規定するUDF 2.50も同じ目的をもつJIS X
0607規格類の部分集合であるが，UDF 2.60は，論理上書きモードのBD-Rなどをサポートす
る点に違いがある。
この目的を達成するために，範囲を定義する。範囲は，JIS X 0607規格類の使用上の規則及び制約を定
義する。ここで定義する範囲を，UDFの適合範囲（UDF Compliant domain）とする。
この規格は，JIS X 0607規格類の構造Xが与えられたとき，その構造Xの各欄について，指定されたオ
ペレーティングシステム（OS）に関する次の課題を解決する。
a) その欄を読み出すOSが，その欄中のデータを利用可能である場合，そのOSの何に対して，その欄
は対応しなければならないか。
b) その欄を読み出すOSが，その欄中のデータを制限付きで利用可能である場合，そのOSにおいて，
その欄をどのように解釈しなければならないか。
c) その欄を読み出すOSが，その欄中のデータを利用可能でない場合，そのOSにおいて，その欄をど
のように解釈しなければならないか。
d) その欄を書き込むOSが，その欄中のデータを利用可能である場合，そのOSにおける何を，その欄
へ対応させなければならないか。
e) その欄を書き込むOSが，その欄中のデータを利用可能でない場合，そのOSにおいて，その欄をど
のように解釈しなければならないか。
JIS X 0607規格類の構造の幾つかに関しては，これらの課題への回答は自明なため，その構造は，ここ
には含めない。
JIS X 0607規格類を明確にするための補足として，各構造に関する付加情報を提供することがある。
この規格は，JIS X 0607規格類を実装する作業をより容易にする。
注記4 この規格では，附属書JAに示す商標又は登録商標を使用しているが，商標を示す記号TM又
2
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
は登録商標を示す記号®は表記していない。
1.1
構成
この規格は，JIS X 0607規格類が規定する構造の扱いについての情報を与える。
この規格は，次に示す四つの基本的な箇条から成る。
箇条2 基本制約及び基本要件：OSに依存しない制約及び要件を定義。
箇条3 システム依存要件：OSに依存する制約及び要件を定義。
箇条4 利用者インタフェース要件：利用者インタフェースに関連する制約及び要件を定義。
箇条6 関連する規定：追加の有用な情報。
注記 箇条2〜箇条4内の細分箇条の題名（例“2.1 第1部 一般”）に含まれる“第n部”（n = 1〜
5）の表記は，それぞれJIS X 0607規格類の第n部の規定内容への対応を示す。
この規格は，JIS X 0607規格類で定義する構造の扱いに関する情報を提供し，次に示す分野を網羅して
いる。
a) 媒体から読み出す場合の構造及び欄の解釈：これを“意味”として示す。
b) 媒体に書き込む場合の構造及び欄の内容：これを“設定値”として示す。特記しない限り，書込みは，
媒体中に新しい構造を作成することだけを意味する。媒体中に存在する構造の更新に適用する場合は，
その旨を特記する。
各構造の欄がまず示され，次いで前述の分類に関して各欄の記述がある。各欄の記述情報で補足する。
欄に関する意味が明白な場合には，構造の1個以上の欄を，記述しない場合がある。
用語遣い：この規格では，“（し）なければならない（shall）”は必須の行為又は要件を示し，“してもよい
（may）”は任意選択の行為又は要件を示し，“であることが望ましい（should）”は推奨するが任意選択で
ある行為又は要件を示す。
欄及び／又は構造に関連する特別な注釈には，“特記事項”を前置きし，一般的な注釈には，“注記”を
前置きして示す。
1.2
適合性
この規格に適合するためには，JIS X 0607規格類の第1部，第2部，第3部及び第4部への適合性が必
要である。この規格は，JIS X 0607規格類の第5部への適合性については規定しない。
ある処理システムがこの規格への適合性を主張するためには，その処理システムは，この規格で規定す
る全ての必須の要件を満たさなければならない。
適合性に関して幾つかの要点を，次に確認する。
a) 複数ボリュームの利用の任意選択性：処理システムは，単一ボリュームだけを利用可能にして，適合
性を主張できる。
b) 複数区画の利用の任意選択性：処理システムは，この規格で定義する単一ボリューム中の特別な複数
区画を利用可能にすることなく，適合性を主張できる。
c) 利用可能な媒体：処理システムは，一つの種別の媒体についての適合性を主張できるし，二つ以上の
種別の媒体の組合せに対しても適合性を主張できる。
d) 複セションを利用可能にする：CD-Rの読出しができる処理システムでは，6.10.3に規定するとおり，
複セションで記録したCD-Rの読出しができなければならない。
e) ファイル名の翻訳：処理システムは，OSの制約に適合するために，ファイル名を翻訳する必要があ
る場合，必ずこの規格で定義するアルゴリズムを使用しなければならない。
f)
拡張属性：全ての適合処理システムでは，媒体中に存在する既存の拡張属性を保存しなければならな
3
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
い。処理システムは，利用可能なOSに関する拡張属性の作成及び保守をしなければならない。参考
として，例えば，Macintoshの処理システムは，媒体中に存在するOS/2の拡張属性を保存しなければ
ならない。Macintoshの処理システムは，この規格が規定する全てのMacintosh拡張属性の作成及び保
守をもしなければならない。
g) 読出しの下位互換性：この規格（UDF 2.60規定）に適合する処理システムは，UDF 2.60規定より若い
UDF版数の規定に従って書き込まれた全ての媒体の読出しができなければならない。
h) 書込みの下位互換性：UDF 2.01，UDF 2.50及びUDF 2.60の構造は，UDF 1.50及びUDF 1.02の構造を
含む媒体に書き込んではならない。UDF 1.50及びUDF 1.02の構造は，UDF 2.01，UDF 2.50及びUDF
2.60の構造を含む媒体に書き込んではならない。これら二つの要件は，媒体が，異なる版のUDF構造
を含むことを防止する。
1.3
参照
1.3.1
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの
引用規格は，記載の年の版を適用し，その後の改正版（追補を含む。）は適用しない。
JIS X 0221:2007 国際符号化文字集合（UCS）
注記 JIS X 0221:2007は，ISO/IEC 10646:2003，Information technology−Universal Multiple-Octet
Coded Character Set (UCS) に一致している。
JIS X 0606:1998 情報交換用CD-ROMのボリューム構造及びファイル構造
注記 JIS X 0606:1998は，ISO 9660:1988，Information processing−Volume and file structure of
CD-ROM for information interchange及びそのAmendment 1:2013に一致している。
JIS X 6281:2012 120 mm再生専用形光ディスク（CD-ROM）
注記1
JIS X 6281:2012は，ISO/IEC 10149:1995，Information technology−Data interchange on
read-only 120 mm optical data disks (CD-ROM) に一致している。
注記2
Yellow Book:Compact Disc Read Only Memory System Descriptionが，JIS X 6281:2006に対応
している。
JIS X 6282:2012 情報交換用120 mm追記形光ディスク（CD-R）
注記 Orange Book, Recordable Compact Disc System, part-IIが，JIS X 6282:2009に一致している。
JIS X 6283:2012 情報交換用120 mmリライタブル光ディスク（CD-RW）
注記 Orange Book, Recordable Compact Disc System, part-IIIが，JIS X 6283:2009に一致している。
IEC 908:1987，Compact disc digital audio system
注記 IEC 908:1987は，既に改正されて，IEC 60908:1999として発行されている。
ISO/IEC 13346-1，-5:1995及びISO/IEC 13346-2〜-4:1999，Information technology−Volume and file
structure of write-once and rewritable media using non-sequential recording for information interchange−
Part 1-5
注記1
ECMA 167 3rd Edition, Volume and file structure of write-once and rewritable media using
non-sequential recording for information interchangeは，ISO/IEC 13346-1〜-5に一致している。
注記2
対応日本工業規格：JIS X 0607:2001 非逐次記録を用いる追記形及び書換形の情報交換用
媒体のボリューム及びファイルの構造（全体評価：MOD）。
注記3
この規格において，[ ]でくくられた参照は，JIS X 0607規格類を[x/a.b.c]の様式で参照し，
ここで，xは部番号，a.b.cは細分箇条番号又は図番号とする。
4
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
1.3.2
用語及び定義
この規格で用いる主な用語及び定義は，次による。
1.3.2.1
オーディオセション（Audio session）
一つ以上のオーディオトラックを含み，データトラックを含まないセション。
1.3.2.2
オーディオトラック（Audio track）
IEC 908が規定するオーディオセクタを含むように設計されたトラック。
1.3.2.3
CD-R（CD-Recordable）
追記形CD。JIS X 6282が規定する追記形コンパクトディスク。
1.3.2.4
CD-RW（CD-Rewritable）
書換形CD。JIS X 6283が規定するリライタブルコンパクトディスク。
1.3.2.5
クリーンファイルシステム（Clean File System）
この規格に適合する媒体のファイルシステム。
1.3.2.6
データトラック（Data track）
JIS X 6281が規定するデータセクタを含む設計がなされたトラック。
1.3.2.7
ダーティファイルシステム（Dirty File System）
クリーンファイルシステムではないファイルシステム。
1.3.2.8
ECCブロック長［ECC Block Size (bytes)］
関連する装置及び／又は媒体の規定が定義する値を参照するブロック長。適切な文書，例えば，CD/DVD
クラス媒体のための“MMC (Multi-Media Commands)”又は“Mt. Fuji”の規定を参考にすることが望まし
い。（例えば，ハードディスクのような）外部的にはそのような概念を見せない媒体では，ECCブロック
長は媒体のセクタ長として解釈しなければならない。さらに，完全に同じではないが，CD-RWのような
固定パケットである媒体には，固定パケットをECCブロックと同じであると考え，この規格のECCブロ
ックの規定を適用しなければならない。
1.3.2.9
固定パケット（Fixed Packet）
与えられたトラックに含まれるパケット全てが，トラック記述子ブロックに指定された長さをもつ，イ
ンクリメンタル記録方式。CDドライブに提示される番地は，JIS X 6282及びJIS X 6283が規定する，番
地付け方式の方式2に従って翻訳される。UDFファイルシステムである固定パケットの媒体上では，パケ
ットは媒体の全てのトラックで同じ長さでなければならない。各パケットの最初のセクタの論理セクタ番
地は固定パケットごとの論理セクタ数の整数倍でなければならない。固定パケット媒体はECCブロックの
規定にも従わなければならない（1.3.2.8のECCブロック長の定義を参照）。
5
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
1.3.2.10
ICB（Information Control Block）
JIS X 0607規格類における制御ノード。
1.3.2.11
論理ブロック番地（Logical Block Address）
論理ブロック番号[3/8.8.1]。
特記事項1 これを，[4/7.1]で規定する論理ブロック番地と混同してはならない。[4/7.1]で規定する論
理ブロック番地は，論理ブロック番号[3/8.8.1]と，区画参照番号[3/8.8]とを含むlb̲addr
構造で示され，区画参照番号は，指し示された論理ブロック[3/8.8.1]を含む区画[3/8.7]を
識別する。
特記事項2 [3/8.8.1]で定義する論理ブロック番号は，指し示す論理ブロック[3/8.8.1]を含む区画
[3/8.7]の，区画マップ[3/10.7]が示す方法に従って，論理セクタ番号[3/8.1.2]に変換される。
1.3.2.12
媒体ブロック番地（Media Block Address）
記録のための関連規格[1/5.10]で示される，一意のセクタ番地によって定まるセクタ番号[3/8.1.1]。この
規格では，セクタ番号[3/8.1.1]は，論理セクタ番号[3/8.1.2]に等しい。
1.3.2.13
パケット（Packet）
連続する整数個のセクタ[1/5.9]からなる記録可能単位。利用者データセクタから構成される。パケット
ライト動作のオーバヘッドとして記録される追加セクタ[1/5.9]を含むことがあり，記録のための関連規格
[1/5.10]に従って指し示すことができる。
1.3.2.14
物理番地（Physical Address）
記録のための関連規格[1/5.10]で示される，特有のセクタ番地によって定まるセクタ番号[3/8.1.1]。この
規格では，セクタ番号[3/8.1.1]は，論理セクタ番号[3/8.1.2]に等しい。
1.3.2.15
物理ブロック番地（Physical Block Address）
物理番地。
1.3.2.16
物理セクタ（Physical Sector）
記録のための関連規格[1/5.10]で示されるセクタ[1/5.9]。この規格では，セクタ[1/5.9]は，論理セクタ
[3/8.1.2]に等しい。
1.3.2.17
疑似上書き（Pseudo OverWrite）
追記媒体上に，ドライブが逐次記録を用いて論理的に実行する上書き。
1.3.2.18
ランダムアクセスファイルシステム（Random Access File System）
任意の位置に書込みができる媒体のためのファイルシステム。追記形又は書換形のいずれか。
1.3.2.19
予約トラック（reserved track）
6
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
有効な記録可能次アドレス（NWA）をもつトラック。疑似上書きに関しては，予約トラックは，NWA
における逐次記録及びNWAまでの疑似上書きがこのトラックに関して可能であることを意味する。使用
済みトラック1.3.2.24も参照。
1.3.2.20
逐次ファイルシステム（Sequential File System）
逐次に書き込まれる媒体（例えば，CD-R）のためのファイルシステム。
1.3.2.21
セション（Session）
トラックの列（トラックは1個でもよい。）であって，各トラック番号が連続した昇順を形成しているも
の。ボリューム中のトラックは，JIS X 6282の規定どおりに，一つ以上のセションに編成しなければなら
ない。
1.3.2.22
トラック（Track）
セクタの列であって，各セクタ番号が連続した昇順を形成しているもの。ボリューム中のセクタは，一
つ以上のトラックに編成されなければならない。一つのセクタが複数のトラックに属してはならない。
特記事項 トラック間に間隙がある場合もある。すなわち，トラックの最後のセクタが，次のトラッ
クの最初のセクタと隣接している必要はない。
1.3.2.23
UDF（Universal Disk Format）
ユニバーサルディスクフォーマット。
1.3.2.24
使用済みトラック（used track）
有効な記録可能次アドレス（NWA）をもたないトラック。疑似上書きに関しては，使用済みトラックは，
このトラックへの逐次記録が不可能であることを意味する。それでも，疑似上書きは可能である。予約ト
ラック1.3.2.19も参照。
1.3.2.25
利用者データブロック（user data blocks）
パケットのセクタ[1/5.9]（この規格では，論理セクタ[3/8.1.2]と同じ。）に記録された論理ブロック[3/8.8.1]。
ドライブの利用者が意図的に記録したデータが含まれる。記録のための関連規格[1/5.10]に従って番地付
け可能なセクタが存在したときでも，そのセクタがパケット記録のオーバヘッドに使用された論理ブロッ
ク[3/8.8.1]は，特にこれには含まれない。利用者データブロックは，論理ブロック[3/8.8.1]と同様に，論理
ブロック番号[3/8.8.1]で識別される。
1.3.2.26
利用者データセクタ（user data sectors）
ドライブの利用者が意図的に記録したデータを含む，パケットのセクタ[1/5.9]。パケットを記録するオ
ーバヘッドに使用されるセクタ[1/5.9]は，記録のための関連規格[1/5.10]に従って番地付けできても，利用
者データセクタには含まれない。いずれのセクタ[1/5.9]とも同じく，利用者データセクタはセクタ番号
[3/8.1.1]で識別される。この規格では，セクタ番号[3/8.1.1]は，論理セクタ番号[3/8.1.2]に等しい。
1.3.2.27
可変パケット（Variable Packet）
7
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
与えられたトラックにおける各パケットが，ホストが決定した長さをもつインクリメンタル記録方式。
CDドライブに提示される番地は，JIS X 6282及びJIS X 6283における，方式1の番地付けで規定すると
おりとする。
1.3.2.28
仮想番地（Virtual Address）
仮想区画における論理ブロック[3/8.8.1]の論理ブロック番号[3/8.8.1]。このような論理ブロック[3/8.8.1]
は，対応する非仮想区画の論理ブロック[3/8.8.1]の空間を使って記録される。VATのN番目のUint32は，
対応する仮想区画の論理ブロック番号Nを記録するために使われる，非仮想区画の論理ブロック番号
[3/8.8.1]を表す。最初の仮想番地は，0である。
1.3.2.29
仮想区画（virtual partition）
この規格の2.2.8に従って記録される種別2の区画マップ[3/10.7.3]によって，論理ボリューム記述子
[3/10.6]で識別される論理ボリューム[3/8.8]の区画。仮想区画マップには，区画番号が含まれるが，これは，
同一の論理ボリューム記述子[3/10.6]における種別1の区画マップ[3/10.7.2]の区画番号[3/10.7.2.4]と同じで
ある。仮想区画の各論理ブロック[3/8.8.1]は，その対応する非仮想区画の論理ブロック[3/8.8.1]の空間を使
って記録される。VATには，その対応する仮想区画の論理ブロック[3/8.8.1]を記録するために使われてい
る，非仮想区画の論理ブロック[3/8.8.1]が列挙される。
1.3.2.30
仮想セクタ（virtual sector）
仮想区画の論理ブロック[3/8.8.1]。このような論理ブロック[3/8.8.1]は，対応する非仮想区画の論理ブロ
ック[3/8.8.1]の空間を使って記録される。仮想セクタを，セクタ[1/5.9]又は論理セクタ[3/8.1.2]と混同しな
いほうがよい。
1.3.2.31
仮想割付け表，VAT（Virtual Allocation Table, VAT）
非仮想区画の空間に記録されるファイル[4/8.8]。対応する仮想区画をもち，そのデータ空間[4/8.8.2]は
2.2.11に従って構成される。このファイルでは複数のUint32の配列リストを備えているが，N番目のUint32
は，対応する仮想区画の論理ブロック番号Nを記録するのに使う，非仮想区画の論理ブロック番号[3/8.8.1]
を表す。このファイル[4/8.8]は，論理ボリューム[3/8.8]のファイル集合[4/8.5]におけるディレクトリ[4/8.6]
のファイル識別記述子[4/14.4]で，必ずしも参照されるわけではない。
1.3.2.32
VAT ICB（Virtual Allocation Table ICB）
VATを含むファイルを記述する，ファイルエントリICB。
1.3.3
用語遣い
1.3.3.1
してもよい（May）
任意選択の行為又は機能を示す。
1.3.3.2
任意選択の（Optional）
実装しても，しなくてもよい機能を示す。実装する場合，その機能は規定どおりに実装しなければなら
ない。
8
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
1.3.3.3
（し）なければならない（Shall）
必須であって，この規格に適合していることを主張するために実装しなければならない行為又は機能を
示す。
1.3.3.4
望ましい（Should）
任意選択ではあるが，その実装が強く推奨される行為又は機能を示す。
1.3.3.5
予約（Reserved）
将来の使用のために確保されている。予約欄は，将来の使用のために確保された欄であり，0に設定し
なければならない。予約値は，将来の使用のために確保された値であり，使用してはならない。
注記1 JIS X 0607，JIS X 0609，JIS X 0610，JIS X 0611では予備と訳している。
注記2 Reserve Volume Descriptor Sequenceの訳語は，予備ボリューム記述子列とする（JIS X 0607の
8.4.2.2を参照。）。
1.3.4
略語
この規格で用いる主な略語は，次による。
略語
意味
AD
割付け記述子（Allocation Descriptor）
AVDP
開始ボリューム記述子ポインタ（Anchor Volume Descriptor Pointer）
EA
拡張属性（Extended Attribute）
EFE
拡張ファイルエントリ（Extended File Entry）
FE
ファイルエントリ（File Entry）
FID
ファイル識別記述子（File Identifier Descriptor）
FSD
ファイル集合記述子（File Set Descriptor）
ICB
JIS X 0607規格類における制御ノード（Information Control Block）
IUVD
処理システム用ボリューム記述子（Implementation Use Volume Descriptor）
LV
論理ボリューム（Logical Volume）
LVD
論理ボリューム記述子（Logical Volume Descriptor）
LVID
論理ボリューム保全記述子（Logical Volume Integrity Descriptor）
NWA
（トラック中の）記録可能次アドレス（Next Writable Address in a track）
PD
区画記述子（Partition Descriptor）
POW
（6.15に示す）疑似上書き（Pseudo OverWrite as described in appendix 6.15）
PVD
基本ボリューム記述子（Primary Volume Descriptor）
SBD
空間ビットマップ記述子（Space Bitmap Descriptor）
USD
未割付け空間記述子（Unallocated Space Descriptor）
VAT
仮想割付け表（Virtual Allocation Table）
VDS
ボリューム記述子列（Volume Descriptor Sequence）
VRS
ボリューム認識列（Volume Recognition Sequence）
2
基本制約及び基本要件
表1は，この規格が定義する基本制約及び基本要件の幾つかを要約している。これらの制約及び要件は，
追加の制約及び要件とともに，この規格の2.1以降で詳細に規定する。
9
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表1−基本制約及び基本要件
項目
制約及び要件
論理セクタ長
特定のボリュームに関する論理セクタ長は，この特定のボリュームの物理セクタ長と同じ
としなければならない。
論理ブロック長
論理ボリュームに関する論理ブロック長は，この特定の論理ボリュームが存在するボリュ
ーム又はボリューム集合の論理セクタ長に設定しなければならない。
ボリューム集合
同一ボリューム集合中の全ての媒体は，同じ物理セクタ長をもたなければならない。書換
形又は上書き可能形の媒体，及び追記形の媒体は，同一ボリューム集合に混在してはなら
ない。
ボリューム空間の最初
の32 Kバイト
ボリューム空間の最初の32 768バイトは，JIS X 0607規格類の構造の記録に使用してはな
らない。この領域は，未割付け空間記述子又は他のいかなるJIS X 0607規格類の記述子も
参照してはならない。この領域は，元のオペレーティングシステム（OS）での自由使用に
任されている。
ボリューム認識列
JIS X 0607規格類の第2部の規定に従ってボリューム認識列を記録しなければならない。
日時表示
全ての日時表示は，現地時で記録しなければならない。時間帯は，時間帯の概念をサポー
トするOSに従って記録しなければならない。
実体識別子
実体識別子は，この規格に従って記録しなければならない。この規格で特記しない限り，
実体識別子は，処理システムを一意に識別する値を含まなければならない。
記述子CRC
CRCは，全ての記述子に関して，利用可能で，計算されなければならない。空間ビットマ
ップ記述子及び割付けエクステント記述子の記述子CRC長については，例外規則がある。
ファイル名の長さ
最大255バイトとする。
エクステント長
最大エクステント長は，230−1を，論理ブロック長の最も近い整数倍の値に端数を切り下
げた値（バイト）でなければならない。仮想区画における最大エクステント長は，論理ブ
ロック長でなければならない。
基本ボリューム記述子 ボリュームごとにただ一つの最新の基本ボリューム記述子を記録しなければならない。こ
の記述子のボリューム順序番号欄が1である媒体は，最新の論理ボリューム記述子で定義
された論理ボリュームの一部でなければならない。
開始ボリューム記述子
ポインタ
ボリュームの最大セクタ番号をNとするとき，256，N−256，及びNの三つの位置のうち，
最低2か所に記録しなければならない（2.2.3参照）。
区画記述子
再生専用形，書換形，上書き可能形，追記形及び疑似上書き可能形の区画アクセス種別を
利用可能としなければならない。次に示す一つの例外を除き，ボリュームごとにただ一つ
の最新の区画記述子を記録しなければならない。単一ボリュームで構成するボリューム集
合において，一つの区画が再生専用のアクセス種別をもち，他区画が書換形，上書き可能
形又は追記形のアクセス種別をもつ場合だけ，ボリュームは二つの最新の区画記述子とと
もに，重なり合わない二つの区画を含んでもよい。このボリュームの論理ボリュームは，
両方の区画の内容で構成する。
論理ボリューム記述子 ボリューム集合ごとにただ一つの最新のボリューム記述子を記録する。
論理ボリューム識別子欄は，空にしてはならず，論理ボリュームの識別のための識別子を
含むことが望ましい。特に，この規格に適合するボリュームを作成するソフトウェアは，
この欄に固定の値又は無意味な値を設定してはならない。同一であることを意図する複製
ディスクは，この欄が同一の値でもよい。この欄は，ジュークボックス中に複数の媒体が
存在するときの，論理ボリュームの識別のために，特に重要となる。この名前は，一般的
には，利用者に表示されているものである。
基本ボリューム記述子のボリューム順序番号欄が1であるボリュームに記録された論理ボ
リューム記述子は，論理ボリュームの全体を示す区画マップの個数欄の値と区画マップ欄
の内容とをもたなければならない。例えば，ボリューム集合が区画を追加することによっ
て拡張された場合は，更新された論理ボリューム記述子が集合の最後のボリュームに書き
込まれ，集合の最初のボリュームにも書き込まれ（又は再度書き込まれ）なければならな
い。
10
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表1−基本制約及び基本要件（続き）
項目
制約及び要件
論理ボリューム保全記
述子
記録しなければならない。LVIDの論理ボリューム保全列のエクステントは，エクステン
ト長で終了してもよい。
区画保全エントリ
記録してはならない。2.3.9を参照。
未割付け空間記述子
ボリュームごとに一つだけの最新の未割付け空間記述子を記録する。
空間ビットマップ記述
子
CRCは必要ではない。
ファイル集合記述子
論理ボリュームごとに，一つだけのファイル集合記述子を記録する。非逐次の追記形媒体
（WORM）だけは，例外とする。2.3.2を参照。FSDエクステントは，エクステント長で
終了してもよい。
ICBタグ
ICB方策種別4又は方策種別4 096だけを記録しなければならない。
ファイル識別記述子
一つのファイル識別記述子の全長は，一つの論理ブロック長を超えてはならない。
ファイルエントリ
一つのファイルエントリの全長は，一つの論理ブロック長を超えてはならない。
割付け記述子
短割付け記述子及び長割付け記述子だけを記録できる。
割付けエクステント記
述子
割付け記述子からなる一つのエクステント長は，一つの論理ブロック長を超えてはならな
い。
未割付け空間エントリ 一つの未割付け空間エントリの全長は，一つの論理ブロック長を超えてはならない。
ボリューム記述子列エ
クステント
主ボリューム記述子列エクステント及び予備ボリューム記述子列エクステントの両方と
も，最小長16個の論理セクタで構成しなければならない。VDSエクステントはエクステ
ント長で終了してもよい。
レコード構造
JIS X 0607規格類の第5部で定義するレコード構造ファイルは，作成してはならない。
UDF読出し最小版数
UDF 2.60のファイルシステムを含む全ての媒体のUDF読出し最小版数の値は，最大でも
#0250でなければならない。これは，UDF 2.50の処理システムが全てのUDF 2.60媒体を
読めることを示す。メタデータ区画のない媒体は，値が#0250より小さくてもよい。
2.1
第1部 一般
2.1.1
文字集合
この規格で定義する構造に関して，UDFで使用する文字集合は，CS0文字集合である。OSTA CS0文字
集合は，ここで定義する。
OSTA CS0は，JIS X 0221に規定されるUCS-2から#FEFF及び#FFFEを除いたd文字から成り，表2に
定義するOSTA圧縮Unicodeフォーマットで記録される。
注記 表2などに記載されているRBPとは，Relative Byte Position（相対バイト位置）の略である。
表2−OSTA圧縮Unicodeフォーマット（OSTA Compressed Unicode format）
RBP
長さ
名前
内容
0
1
圧縮識別子（Compression ID）
Uint8
1
??
圧縮ビット列（Compressed Bit Stream）
バイト
注記 ??は可変長欄を示す。
圧縮識別子（CompressionID）は，圧縮ビット列（CompressedBitStream）欄の圧縮に使用する圧縮アルゴ
リズムを識別する。表3に示すアルゴリズムが，現在利用できる。
11
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表3−圧縮アルゴリズム（Compressed Algorithm）
値
意味
0〜7
予約
8
圧縮ビット列（CompressedBitStream）中の1文字が，8ビットであることを示す。
9〜15
予約
16
圧縮ビット列中の1文字が，16ビットであることを示す。
17〜253
予約
254
CS0伸張は，空である一意な状態であることを示す。圧縮アルゴリズム値8が圧縮に使われる。
255
CS0伸張が，空である一意な状態であることを示す。圧縮アルゴリズム値16が圧縮に使われる。
圧縮識別子の値が8又は16のとき，その値は，圧縮ビット列欄で定義するd文字のビット数を規定する。
圧縮識別子が指定するビット数で圧縮ビット列を区切ったときの各ビット列は，OSTA圧縮Unicodeのd
文字を表す。符号化される文字のビットは，最上位ビットから最下位ビットまで，圧縮ビット列に加えな
ければならない。符号化される文字のビットは，符号化先の着目しているバイトの最上位ビットの位置か
ら圧縮ビット列に加えていかなければならない。
特記事項 この符号化によって，圧縮識別子16のアルゴリズムで書き込まれた文字は，ビッグエン
ディアンフォーマットで書き込まれる。
Uint16として解釈されるOSTA圧縮Unicodeのd文字の値は，Unicode 2.0の規定に対応するd文字の値
を定義する。OSTA圧縮Unicodeについては，6.4に掲げるOSTA圧縮UnicodeとUnicode 2.0との間の変換
Cのソースコードの例を参照。
Unicodeのバイト順マーク#FEFF及び#FFFEは，使用してはならない。254又は255の圧縮識別子は，削
除ビットが1に設定されたファイル識別子だけに使わなければならない。254又は255の圧縮識別子をも
つファイル識別子を非圧縮にすると，結果の識別子は空である一意な状態であるとして取り扱わなければ
ならない。
2.1.2
OSTA CS0 Charspec
struct charspec{
/* JIS X 0607 1/7.2.1 */
Uint8
CharacterSetType;
byte
CharacterSetInfo[63];
}
文字集合の種別（CharacterSetType）欄は，CS0符号化文字集合を示す値0を指定する。
文字集合情報（CharacterSetInfo）欄は，次に示すバイト値を設定し，欄の残りバイトは0に設定する。
#4F, #53, #54, #41, #20, #43, #6F, #6D, #70, #72, #65, #73, #73, #65,
#64, #20, #55, #6E, #69, #63, #6F, #64, #65
このバイト値は，次に示すASCII列を表す。
“OSTA Compressed Unicode”
2.1.3
dstring
この規格と同様に，JIS X 0607規格類は，通常は相対バイト位置を0から定義している。これに反し，
[1/7.2.12]では，相対位置が1からのものとして，dstringを定義している。これは混乱を招くことがあるの
で，[1/7.2.12]の規定を相対位置が0からのものとして変更したものを次に示す。
“7.2.12 固定長文字欄
長さnのdstringは，d文字[1/7.2]を記録するnバイトの欄である。文字の記録に使用するバイト
12
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
の数は，バイトn−1にUint8[1/7.1.1]で記録する。ここで，nは，この欄の長さとする。文字は欄の
先頭バイトから記録し，記録した文字以後からバイトn−2までのバイト位置に，すべて#00を設定
する（[1/7.2.12]参照）。”
符号化するd文字の数が0の場合，dstringの長さは0としなければならない。
特記事項 長さ0の列の場合を除いて，dstringの長さは圧縮識別子（2.1.1）を含む。長さ0の列は，
dstring欄に全て0を設定することによって記録されることが望ましい。
2.1.4
日時表示（Timestamp）
struct timestamp{
/* JIS X 0607 1/7.3 */
Uint16
TypeAndTimezone;
Int16
Year;
Uint8
Month;
Uint8
Day;
Uint8
Hour;
Uint8
Minute;
Uint8
Second;
Uint8
Centiseconds;
Uint8
HundredsofMicroseconds;
Uint8
Microseconds;
}
2.1.4.1
種別及び時間帯（Uint16 TypeAndTimezone）
次の記載において，種別（Type）は，この欄の最上位4ビットを示し，時間帯（TimeZone）欄は，この
欄の最下位12ビットを示し，その値は2の補数形式の符号付き12ビット数と解釈する。
a) 種別（Type）
1) 意味：この構造の時刻は，現地時として解釈しなければならない。OSTA UDF適合媒体では，種別
は1でなければならない。
2) 設定値：種別は，現地時を示す1を設定しなければならない。
b) 時間帯（TimeZone）
1) 意味：時間帯欄はこの欄を最後に更新したときの現地の時間帯を指定していると解釈しなければな
らない。この欄が値（−2 047）の場合には，時間帯を指定していない。
2) 設定値：時間帯の概念が利用可能なOSは，協定世界時からの時間帯の差（1分ごと）を時間帯欄に
指定しなければならない。それ以外は，時間帯欄には，値（−2 047）を設定しなければならない。
特記事項1 協定世界時より西の時間帯は，負の時間差をもつ。例えば，米国東部標準時は−300分
であり，米国東部夏時間は−240分である。
特記事項2 時間帯を利用可能としているシステム上の実装は，時間帯が指定されていない場合は協
定世界時と解釈することが望ましい。また，必須ではないが，この解釈では時間帯を利
用可能としていないシステムで作成されたファイルが，読出しシステムの現地時間帯と
関係なく，常に同じ日時表示で表示されるという利点をもつ。
2.1.5
実体識別子（Entity Identifier）
struct EntityID {
/* JIS X 0607 1/7.4 */
Uint8
Flags;
13
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
char
Identifier[23];
char
IdentifierSuffix[8];
}
特記事項 UDFはEntityIDをJIS X 0607でregidと呼ばれている構造体に使用している。
UDFは，実体識別子を次に示す四つの種別に分類する。各種別は識別子添字欄用の添字種別をもつ。四
つの種別を次に示す。
a) 範囲識別子添字をもつ範囲実体識別子（Domain Entity Identifiers with a Domain Identifier Suffix）
b) UDF識別子添字をもつUDF実体識別子（UDF Entity Identifiers with a UDF Identifier Suffix）
c) 処理システム識別子添字をもつ処理システム実体識別子（Implementation Entity Identifiers with an
Implementation Identifier Suffix）
d) アプリケーション識別子添字をもつアプリケーション実体識別子（Application Entity Identifiers with an
Application Identifier Suffix）
これらの異なる種別に基づいて実体識別子のフォーマット及び使用方法を以下に示す。全てのUDF記述
子欄は一つのEntityIDを含み，Identifier欄の値及びIdentifierSuffix欄の添字種別は2.1.5.2の表4 実体識別
子によって定義される。IdentifierSuffix欄の各添字種別の解釈は2.1.5.3で定義される。
2.1.5.1
フラグ（Uint8 Flags）
a) 意味：自明。
b) 設定値：0を設定しなければならない。
2.1.5.2
識別子（char Identifier[23]）
この規格では，特記しない限り，この欄には，処理システムを一意に識別する識別子を設定しなければ
ならない。この方法は，異なる処理システム間で交換する媒体中に記録した構造が，どの処理システムに
よるものかの識別を可能にする。
処理システムが，他の処理システムで書き込んだ媒体中に存在する構造を更新する場合，現状の処理シ
ステムは，現状の処理システムを一意に識別する値を識別子欄に設定しなければならない。
表4は，JIS X 0607規格類及びこの規格で定義する実体識別子欄を要約したものであり，設定しなけれ
ばならない値を示す。
14
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表4−実体識別子（Entity Identifiers）
記述子（Descriptor）
欄（Field）
識別子値（ID Value）
添字種別（Suffix Type）
基本ボリューム記述子
処理システム識別子
“*Developer ID”
処理システム識別子添字
基本ボリューム記述子
アプリケーション識別子 “*Application ID”
アプリケーション識別子添字
処理システム用ボリューム
記述子
処理システム識別子
“*UDF LV Info”
UDF識別子添字
処理システム用ボリューム
記述子
処理システム識別子
（処理システム用欄内）
“*Developer ID”
処理システム識別子添字
区画記述子
処理システム識別子
“*Developer ID”
処理システム識別子添字
区画記述子
区画内容
“+NSR03”
アプリケーション識別子添字
論理ボリューム記述子
処理システム識別子
“*Developer ID”
処理システム識別子添字
論理ボリューム記述子
範囲識別子
“*OSTA UDF Compliant” 範囲識別子添字
ファイル集合記述子
範囲識別子
“*OSTA UDF Compliant” 範囲識別子添字
ファイル識別記述子
処理システム用（任意選
択）
“*Developer ID”
処理システム識別子添字
ファイルエントリ
処理システム識別子
“*Developer ID”
処理システム識別子添字
装置仕様拡張属性
処理システム用
“*Developer ID”
処理システム識別子添字
UDF処理システム用拡張属
性
処理システム識別子
3.3.4.5参照
UDF識別子添字
非UDF処理システム用拡
張属性
処理システム識別子
“*Developer ID”
処理システム識別子添字
UDFアプリケーション用拡
張属性
アプリケーション識別子 3.3.4.6参照
UDF識別子添字
非UDFアプリケーション
用拡張属性
アプリケーション識別子 “*Application ID”
アプリケーション識別子添字
UDF一意IDマッピングデ
ータ
処理システム識別子
“*Developer ID”
処理システム識別子添字
パワーこう（較）正表スト
リーム
処理システム識別子
“*Developer ID”
処理システム識別子添字
論理ボリューム保全記述子
処理システム識別子
（処理システム用欄内）
“*Developer ID”
処理システム識別子添字
区画保全エントリ
処理システム識別子
N/A，2.3.9参照
N/A
仮想区画マップ
区画種別識別子
“*UDF Virtual Partition”
UDF識別子添字
仮想割付け表
処理システム用（任意選
択）
“*Developer ID”
処理システム識別子添字
予備区画マップ
区画種別識別子
“*UDF Sparable Partition” UDF識別子添字
予備表
予備識別子
“*UDF Sparing Table”
UDF識別子添字
メタデータ区画マップ
区画種別識別子
“*UDF Metadata Partition” UDF識別子添字
注記1 N/Aは，“規定しない”ことを示す。
注記2 表4の添字種別欄は，相当する実体識別子で使用する添字のフォーマットを定義する。これらの異なる添
字種別は，2.1.5.3で定義する。
特記事項1 表4の識別子値欄の値は，バイトの列として解釈し，CS0で規定するdstringとしては解
釈しない。UDFで容易に使用するために，この欄で使用する値は，ASCII文字列で指定
する。UDFで定義する実体識別子で使用するバイト列は，6.2で規定する。
表4の識別子値欄の“*Developer ID”は，現状の処理システムを一意に識別する実体識別子を示す。指
定した値は，新しい記述子を作成するときに使用することが望ましい。規定した値は，指定した実体識別
子欄の有効範囲内で何かを更新する場合には，存在する記述子にも使用することが望ましい。
15
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
特記事項2 “*Developer ID”のために選択された値は，処理システムに関する社名及び製品名を識
別できるだけの情報を含むことが望ましい。例えば，DataOneというUDF製品をもつ
XYZという会社は，Developer IDとして“*XYZ DataOne”を選択してもよい。Developer
IDの添字においても，DataOne製品の現在の版数を記録することを選択してもよい。こ
の情報は，異なる会社の複数の製品が媒体に記録していた場合，どの処理システムが媒
体の一部に不適切な構造を書き込んだのかを決定するとき，非常に助けになる。
表4の識別子値欄の“*Application ID”は，書込みを行ったアプリケーションを一意に識別する識別子を
示す。
特記事項3 この規格で定義する全ての識別子（6.1）は，UDF識別子としてOSTAによって登録され
ていなければならない。
2.1.5.3
識別子添字（char IdentifierSuffix[8]）
識別子添字（IdentifierSuffix）欄のフォーマットは，識別子の種別に依存する。
この規格で規定するOSTA範囲実体識別子（2.1.5.2及び6.1）に関しては，識別子添字欄は，表5に示
す構成でなければならない。
表5−範囲識別子添字フォーマット（Domain Identifier Suffix format）
RBP
長さ
名前
内容
0
2
UDF版数（UDF Revision）
Uint16（= #0260）
2
1
範囲フラグ（Domain Flags）
Uint8
3
5
予約（Reserved）
バイト（= #00）
UDF版数（UDFRevision）欄は，この規格の対応団体規格の規定の版数2.60を示す値#0260を設定する。
この欄は，この規格の対応団体規格の規定の改正版に加えられた変更を，処理システムが検出することを
可能にする。OSTA範囲識別子は，論理ボリューム記述子及びファイル集合記述子だけに使用する。範囲
フラグ（Domain Flags）欄は，表6に示すビットフラグを定義する。
表6−範囲フラグ（Domain Flags）
Bit
意味
0
ハード書込み保護（Hard Write-Protect）
1
ソフト書込み保護（Soft Write-Protect）
2〜7
予約（Reserved）
ソフト書込み保護（SoftWriteProtect）フラグは，利用者が設定可能なフラグであり，このフラグが存在
する記述子の有効範囲で，ボリューム構造又はファイル構造が書込み保護されていることを示す。ソフト
書込み保護フラグの値が1の場合，利用者の書込み保護を示さなければならない。このフラグは，利用者
が設定及び解除してもよい。ハード書込み保護（HardWriteProtect）フラグは，処理システムが設定可能な
フラグであり，このフラグが存在する記述子の有効範囲で永久的な書込み保護を示さなければならない。
ハード書込み保護フラグの値が1の場合，永久的な書込み保護を示さなければならない。このフラグは，
一度設定した場合解除してはならない。ハード書込み保護フラグは，ソフト書込み保護フラグに優先する。
書込み保護フラグは，論理ボリューム記述子及びファイル集合記述子の中に現れる。それらは次のとお
りに解釈しなければならない。
is̲fileset̲write̲protected = LVD.HardWriteProtect || LVD.SoftWriteProtect ||
16
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
FSD.HardWriteProtect || FSD.SoftWriteProtect
is̲fileset̲hard̲protected = LVD.HardWriteProtect || FSD.HardWriteProtect
is̲fileset̲soft̲protected = (LVD.SoftWriteProtect || FSD.SoftWriteProtect) &&
! is̲fileset̲hard̲protected
is̲vol̲write̲protected = LVD.HardWriteProtect || LVD.SoftWriteProtect
is̲vol̲hard̲protected = LVD.HardWriteProtect
is̲vol̲soft̲protected = LVD.SoftWriteProtect && !LVD.HardWriteProtect
UDFで定義するUDF実体識別子（2.1.5.2及び6.1参照）に対しては，識別子添字欄は，表7に示す構成
でなければならない。
表7−UDF識別子添字フォーマット（UDF Identifier Suffix format）
RBP
長さ
名前
内容
0
2
UDF版数（UDF Revision）
Uint16（= #0260）
2
1
オペレーティングシステムクラス（OS Class）
Uint8
3
1
オペレーティングシステム識別子（OS Identifier） Uint8
4
4
予約（Reserved）
バイト（= #00）
オペレーティングシステムクラス（OS Class）及びオペレーティングシステム識別子（OS Identifier）欄
の内容は，6.3に規定する。
UDFで定義しない処理システム実体識別子（2.1.5.2参照）に対しては，識別子添字欄は，表8に示す構
成でなければならない。
表8−処理システム識別子添字フォーマット（Implementation Identifier Suffix format）
RBP
長さ
名前
内容
0
1
オペレーティングシステムクラス（OS Class）
Uint8
1
1
オペレーティングシステム識別子（OS Identifier） Uint8
2
6
処理システム用領域（Implementation Use Area）
バイト
注記 OSクラス欄及びOS識別子欄の，意図した使用及び重要性を理解することが重要になる。これ
らの欄の主な目的は，UDFボリューム中で問題を検出したときに，誤りを取り除く支援をする
ことである。この欄は，利用者に提供可能な有効な情報も提供する。これらの二つの欄を正し
く設定した場合，処理システムに次の情報を提供する。
− 最後に特定の構造を更新したOSを識別する。
− 最後に特定のファイル又はディレクトリを更新したOSを識別する。
− 開発者が処理システムとともに複数OSを提供する場合，問題が発生したOSを決定する支
援をする。
UDFで定義しないアプリケーション実体識別子（2.1.5.2参照）に対しては，識別子添字（IdentifierSuffix）
欄は，特記しない限り，表9に示す構成としなければならない。
表9−アプリケーション識別子添字フォーマット（Application Identifier Suffix format）
RBP
長さ
名前
内容
0
8
アプリケーション用領域（Application Use Area）
バイト
17
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.1.6
初期化時の記述子タグ通し番号（Descriptor Tag Serial Number at Formatting Time）
障害回復に対応するため，全てのUDF記述子のタグ通し番号（TagSerialNumber）は初期化時に記録さ
れ，ボリュームの再初期化時には，以前に記録した値と異なる値を設定しなければならない。
障害回復が対応されない場合は，全てのUDF記述子のタグ通し番号欄には，初期化時に値0（#0000）
を記録しなければならない（2.2.1.1，2.3.1.1，[3/7.2.5]及び[4/7.2.5]参照）。
障害回復が対応される場合は，使用すべき値はボリュームが初期化される前の状態に依存する。将来に
おいて障害回復可能なボリュームの取り得る状態は，次の二つしかない。
a) 完全に消去されたボリューム：これが行われた後，障害回復が対応される場合にだけ，タグ通し番号
の値に1（#0001）が使われなければならない。
b) タグ通し番号によって障害回復に対応しているクリーンなUDFボリュームであって，少なくとも二つ
の開始ボリューム記述子ポインタのタグ通し番号の値がいずれもXと等しく，Xが0と等しくない場
合。障害回復が対応される場合は，値X＋1がタグ通し番号の値として用いられなければならない。X
＋1が0に戻ってしまう場合は，それを0のままにして障害回復が対応されていないことを示す。
特記事項1 この理由は，もし，X＋1が0に戻ってしまうのであれば，値が0でないいずれかのタグ
通し番号の一意性がそのボリューム上では保証できなくなってしまうからである。
特記事項2 この2.1.6では，消去という用語を，例えばセクタを0で埋めることによって，UDFと
しては無効なセクタにするという意味で使用している。
2.1.7
ボリューム認識列（Volume Recognition Sequence）
次の規則は，ボリューム認識列を書き込むときに守られなければならない。
a) 設定値：JIS X 0607規格類の第2部及び第3部で定義されているボリューム認識列を記録しなければ
ならない。ボリューム認識列内には，一つだけのNSR記述子がなければならない。NSR及びBOOT2
記述子は拡張領域になければならない。一つのBEA01及び一つのTEA01をもつ一つだけの拡張領域
がなければならない。その他のボリューム構造記述子は，拡張領域よりも前だけに置いてもよい。ボ
リューム認識列の直後のセクタは未記録であるか全て#00バイトで埋まっていなければならない。
b) 意味：処理系作成者は，UDF 1.02及びUDF 1.50の版数で記録された媒体がボリューム認識列の直後
のセクタについての要件に従っていないことを予期することが望ましく，それらの場合をそれに応じ
て扱うことが望ましい。
特記事項 現在のところ，BOOT2記述子はUDF用には定義されていない（5.3参照）。さらに，JIS X
0607規格類の第2部，[3/3.1]，[3/3.2]，[3/9.1]も参照する。
2.2
第3部 ボリューム構造
2.2.1
記述子タグ（Descriptor Tag）
struct tag{
/* JIS X 0607 3/7.2 */
Uint16
TagIdentifier;
Uint16
DescriptorVersion;
Uint8
TagChecksum;
byte
Reserved;
Uint16
TagSerialNumber;
Uint16
DescriptorCRC;
Uint16
DescriptorCRCLength;
Uint32
TagLocation;
18
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
}
特記事項 JIS X 0607では値が0のタグ識別子は定義されていないが，UDFでは予備表の識別子とし
て使用する。
2.2.1.1
タグ通し番号（Uint16 TagSerialNumber）
a) 意味：無視する。障害回復を意図する。
b) 設定値：このボリュームの開始ボリューム記述子ポインタのタグ通し番号（TagSerialNumber）の値に
設定しなければならない。
障害回復に対応するため，タグ通し番号はボリュームの再初期化時には，以前に記録した値と異なる値
を設定しなければならない。この値はボリュームの初期化時に決定され，初期化される前の状態に依存す
る。詳細については，2.1.6を参照。
2.2.1.2
記述子CRC長（Uint16 DescriptorCRCLength）
記述子CRCは，各記述子で利用可能であり，計算されなければならない。特記しない限り，記述子CRC
長の欄の値は，［（記述子の大きさ）−（記述子タグの長さ）］，65 535の二つの値の最小値を設定しなけれ
ばならない。記述子を読み出すときは，記述子CRCを検証することが望ましい。
特記事項 記述子CRC長（DescriptorCRCLength）欄は記述子の実際の長さ又は読み込まれるバイト
長を決定するのに使用しないことを推奨する。これらの長さは，全ての場合では一致せず，
記述子CRC長は65 535に丸められる可能性があり，またこの規格中には，これ以外の記
述子CRC長が記述子の長さと一致しない例外が存在する。
2.2.2
基本ボリューム記述子（Primary Volume Descriptor）
struct PrimaryVolumeDescriptor{ /* JIS X 0607 3/10.1 */
struct tag
DescriptorTag;
Uint32
VolumeDescriptorSequenceNumber;
Uint32
PrimaryVolumeDescriptorNumber;
dstring
VolumeIdentfier[32];
Uint16
VolumeSequenceNumber;
Uint16
MaximumVolumeSequenceNumber;
Uint16
InterchangeLevel;
Uint16
MaximumInterchangeLevel;
Uint32
CharacterSetList;
Uint32
MaximumCharacterSetList;
dstring
VolumeSetIdentifier[128];
struct charspec
DescriptorCharacterSet;
struct charspec
ExplanatoryCharacterSet;
struct extent̲ad
VolumeAbstract;
struct extent̲ad
VolumeCopyrightNotice;
struct EntityID
ApplicationIdentifier;
struct timestamp
RecordingDateandTime;
struct EntityID
ImplementationIdentifier;
byte
ImplementationUse[64];
Uint32
PredecessorVolumeDescriptorSequenceLocation;
19
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
Uint16
Flags;
byte
Reserved[22];
}
2.2.2.1
交換水準（Uint16 InterchangeLevel）
a) 意味：関連するボリュームの内容の現状の交換水準（[3/11]で規定）及び規定水準が意味する制約につ
いての指定と解釈する。
b) 設定値：このボリュームが，複数ボリュームから成るボリューム集合に属する場合，この水準は値3
を設定し，それ以外の場合は，値2を設定しなければならない。
JIS X 0607規格類は，規定する現状の交換水準に関連する制約の実施を処理システムに要求する。処理
システムは，最大交換水準（Maximum Interchange Level）欄の値を超えない限り，この欄の値を変更しても
よい。
2.2.2.2
最大交換水準（Uint16 MaximumInterchangeLevel）
a) 意味：関連するボリュームの内容についての最大交換水準（[3/11]で規定）の指定と解釈する。
b) 設定値：利用者が特別に異なる値を与えない限り，この欄は水準3（制限なし）を設定しなければな
らない。
特記事項 この欄は，ボリューム作成者の意図の指定に使用する。この欄が値2の場合，作成者は，
このボリュームが複数ボリュームから成るボリューム集合（交換水準3）に属さないこと
を意図する。受領者は，この欄を無視して値3を設定してもよいが，その場合には，処理
システムは，ボリューム作成者の意図を示す警告を受領者に与えることが望ましい。
2.2.2.3
文字集合リスト（Uint32 CharacterSetList）
a) 意味：[3/10.1.9]で定義する構造で使用する文字集合の指定と解釈する。
b) 設定値：2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。
2.2.2.4
文字最大集合リスト（Uint32 MaximumCharacterSetList）
a) 意味：文字集合リスト（CharacterSetList）欄で指定してもよい利用可能な文字集合（JIS X 0607規格
類で規定）の最大値の指定と解釈する。
b) 設定値：2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。
2.2.2.5
ボリューム集合識別子（dstring VolumeSetIdentifier[128]）
a) 意味：ボリューム集合の識別子の指定と解釈する。
b) 設定値：この欄の最初の16文字は，一意の値に設定することが望ましい。この欄の残りは，使用可能
な任意の値を設定してもよい。特に，この規格に従ってボリューム構造を生成するソフトウェアは，
この欄に，固定値又は無意味な値を設定してはならない。同一であることを意図された複製ディスク
は，この欄に同じ値を入れてもよい。
特記事項 ここで意図する目的は，一意の識別子をもつボリューム集合の保証にある。この欄の最初
の16文字において，最初の8文字は，32ビットの日時の値のCS0による16進表示とする
ことが望ましく，残りの8文字は，処理システム用に任されている。
2.2.2.6
記述子文字集合（struct charspec DescriptorCharacterSet）
a) 意味：ボリューム識別子（Volume Identifier）欄及びボリューム集合識別子（Volume Set Identifier）欄で
使用可能な文字集合の指定と解釈する。
b) 設定値：2.1.2で定義するCS0を利用可能とする設定をしなければならない。
2.2.2.7
説明用文字集合（struct charspec ExplantoryCharacterSet）
20
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
a) 意味：ボリューム抄録（VolumeAbstract）及びボリューム著作権通知（VolumeCopyrightNotice）エクス
テントの内容の解釈に使用する文字集合の指定と解釈する。
b) 設定値：2.1.2で定義するCS0を利用可能とする設定をしなければならない。
2.2.2.8
処理システム識別子（struct EntityID ImplementationIdentifier）
この欄の適切な扱いに関する詳細情報は，2.1.5を参照。
2.2.2.9
アプリケーション識別子（struct EntityID ApplicationIdentifier）
a) 意味：この欄の有効な実体識別子（2.1.5）は，この欄を最後に書いたアプリケーションを識別し，又
はこの欄が全て#00バイトで埋められている場合は，アプリケーションが識別されないと解釈する。
b) 設定値：この欄は全て#00バイトとするか，有効な実体識別子（2.1.5）を設定しなければならない。
2.2.3
開始ボリューム記述子ポインタ（Anchor Volume Descriptor Pointer）
struct AnchorVolumeDescriptorPointer{ /* JIS X 0607 3/10.2 */
struct tag
DescriptorTag;
struct extent̲ad
MainVolumeDescriptorSequenceExtent;
struct extent̲ad
ReserveVolumeDescriptorSequenceExtent;
byte
Reserved[480];
}
特記事項1 開始ボリューム記述子ポインタ構造は，媒体中の次に示す三つの位置のうち，最低2か
所に記録する。
− 論理セクタ 256
− 論理セクタ（N−256）
− 論理セクタ N
特記事項2 閉じられた媒体は，これらの規則に従うことを推奨する。6.11.2で規定されているよう
に，閉じていない逐次記録媒体では，セクタ256又は512のいずれかに一つだけの開始
ボリューム記述子ポインタが記録されてもよい。閉じていない媒体でセクタ256に一つ
だけの開始ボリューム記述子ポインタがある場合は，セクタ512に記録された開始ボリ
ューム記述子ポインタは，無視されることを推奨する。
2.2.3.1
主ボリューム記述子列エクステント（struct MainVolumeDescriptorSequenceExtent）
主ボリューム記述子列エクステントは，最小長16論理セクタでなければならない。
2.2.3.2
予備ボリューム記述子列エクステント（struct ReserveVolumeDescriptorSequenceExtent）
予備ボリューム記述子列エクステントは，最小長16論理セクタでなければならない。
特記事項 主ボリューム記述子列エクステント及び予備ボリューム記述子列エクステントは，異なる
ECCブロックに記録しなければならない。ボリューム上のこれらのエクステントの位置は，
できる限り物理的に離れていることが望ましい。通常は，エクステントの開始LSNの差を
最大にすることで達成される。複層媒体など，特殊なLSNのアドレス体系の場合には，注
意を払うことが望ましい。
2.2.4
論理ボリューム記述子（Logical Volume Descriptor）
struct LogicalVolumeDescriptor{ /* JIS X 0607 3/10.6 */
struct tag
DescriptorTag;
Uint32
VolumeDescriptorSequenceNumber;
struct charspec
DescriptorCharacterSet;
21
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
dstring
LogicalVolumeIdentifier[128];
Uint32
LogicalBlockSize;
struct EntityID
DomainIdentifier;
byte
LogicalVolumeContentsUse[16];
Uint32
MapTableLength;
Uint32
NumberofPartitionMaps;
struct EntityID
ImplementationIdentifier;
byte
ImplementationUse[128];
extent̲ad
IntegritySequenceExtent;
byte
PartitionMaps[];
}
2.2.4.1
記述子用文字集合（struct charspec DescriptorCharacterSet）
a) 意味：論理ボリューム識別子（LogicalVolumeIdentifier）欄で使用可能な文字集合の指定と解釈する。
b) 設定値：2.1.2で定義するCS0を利用可能とする設定をしなければならない。
2.2.4.2
論理ブロック長（Uint32 LogicalBlockSize）
a) 意味：この論理ボリューム記述子（LogicalVolumeDescriptor）で識別する論理ボリュームの論理ブロッ
ク長の指定と解釈する。
b) 設定値：この欄は，論理ボリューム記述子で識別する論理ボリュームを構成する媒体中の全ての区画
のうち，最大の論理セクタ長を設定しなければならない。UDFでは，ボリューム集合中の全てのボリ
ュームが同一論理セクタ長であることを要求するため，論理ブロック長（LogicalBlockSize）は，ボリ
ュームの論理セクタ長に等しい。
2.2.4.3
範囲識別子（struct EntityID DomainIdentifier）
a) 意味：記述子中の欄の使用規則及び制限を規定する範囲の指定と解釈する。この欄の全てが0の場合，
無視する。それ以外の場合は，実体識別子規則に従う。
特記事項 この欄の内容が“*OSTA UDF Compliant”でない場合，処理システムは論理ボリュームに
対する利用者からのアクセスを拒否してもよい。
b) 設定値：この欄は，この規格で定義する範囲に適合する論理ボリュームの内容であることを示すもの
でなければならない。したがって，この範囲識別子（DomainIdentifier）の識別子の値は，
“*OSTA UDF Compliant”
に指定しなければならない。
2.1.5で記載したとおり，実体識別子の識別子添字（IdentifierSuffix）欄には，論理ボリュームの内容が互
換性をもつこの規格の対応団体規格の規定の版数を含む。この欄の適切な扱いに関する詳細情報は，2.1.5
を参照。
特記事項 実体識別子の識別子添字欄は，ソフト書込み保護（SoftWriteProtect）フラグ及びハード書
込み保護（HardWriteProtect）フラグを含む（2.1.5.3参照）。
2.2.4.4
論理ボリューム内容用[16]（byte LogicalVolumeContentsUse[16]）
この欄には，ファイル集合記述子のエクステント位置が含まれる。これは，[4/3.1]に次のとおりに規定
される。
“3.1 入力
ボリュームが第3部に従って記録される場合，論理ボリュームの最初のファイル集合記述子列が
22
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
記録されるエクステントは，long̲ad[4/14.14.2]で識別される。このlong̲adは，ファイル集合記述
子を記録する論理ボリュームを記載する論理ボリューム記述子の論理ボリューム内容用欄
[3/10.6.7]に記録されている（[4/3.1]参照）。”
この欄は，ファイル集合記述子を見つけるのに使用でき，ファイル集合記述子からルートディレクトリ
を見つけることができる。
2.2.4.5
処理システム識別子（struct EntityID ImplementationIdentifier）
この欄の適切な扱いに関する詳細情報は，2.1.5を参照。
2.2.4.6
保全列エクステント（struct extent̲ad IntegritySequenceExtent）
この欄の値は，論理ボリューム保全記述子のために必要となる。書換形媒体又は上書き可能形媒体に関
しては，最小値8 Kバイトを設定しなければならない。
警告 追記形媒体に対しては，この欄は，十分な長さのエクステントを設定することが望ましい。論
理ボリューム保全記述子は，最新論理ボリューム記述子と同一のボリュームに存在しなければ
ならないため，論理ボリューム保全記述子が存在する追記形媒体が一杯になった場合は，ボリ
ューム集合に新しいボリュームを追加しなければならない。
2.2.4.7
区画マップ（byte PartitionMaps[]）
交換の目的として，区画マップは，2.2.8，2.2.9及び2.2.10に記載されているとおり，種別2を除き，区
画マップ種別1に限定しなければならない。
2.2.5
未割付け空間記述子（Unallocated Space Descriptor）
struct UnallocatedSpaceDesc{ /* JIS X 0607 3/10.8 */
struct tag
DescriptorTag;
Uint32
VolumeDescriptorSequenceNumber;
Uint32
NumberofAllocationDescriptors;
exted̲ad
AllocationDescriptors[];
}
使用可能なボリューム空間がない場合でも，この記述子を記録しなければならない。ボリューム空間の
始めの32 768バイトは，JIS X 0607規格類の構造を記録するのに使用してはならない。この領域は未割付
け空間記述子又は他のどのJIS X 0607規格類の記述子によっても参照されてはならない。
2.2.6
論理ボリューム保全記述子（Logical Volume Integrity Descriptor）
struct LogicalVolumeIntegrityDesc{ /* JIS X 0607 3/10.10 */
struct tag
DescriptorTag;
Timestamp
RecordingDateAndTime;
Uint32
IntegrityType;
struct extend̲ad
NextIntegrityExtent;
byte
LogicalVolumeContentsUse[32];
Uint32
NumberOfPartitions;
Uint32
LengthOfImplementationUse;
Uint32
FreeSpaceTable[];
Uint32
SizeTable[];
byte
ImplementationUse[];
}
23
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
論理ボリューム保全記述子は，関連する論理ボリュームの内容を更新したときに書き込まれなければな
らない構造である。論理ボリューム保全記述子の内容によって，処理システムは，次に示す有用な問いに
対し容易に回答できる。
a) 論理ボリュームの内容は，一貫性のある状態か否か
b) 論理ボリュームを更新した最終日時
c) 論理ボリューム中の使用可能空間の論理ブロック総数
d) 論理ボリューム中の論理ブロック総数
e) 論理ボリューム中で次に使用可能な一意ID
f)
論理ボリュームを作成した作成処理システムが最後にアクセスした日時以降に論理ボリューム中の内
容を更新した他の処理システムの有無
2.2.6.1
論理ボリューム内容用（byte LogicalVolumeContensUse[32]）
この欄の内容の情報に関しては，3.2.1を参照。
2.2.6.2
使用可能空間表（Uint32 FreeSpaceTable[]）
ほとんどのOSは，媒体のマウント時に，処理システムが論理ボリューム中の使用可能空間の大きさを
提供することを要求するため，使用可能空間表の値を全ての区画のために保守することは重要となる。次
の2例は例外とする。
a) 仮想区画でありアクセス種別が疑似上書き可能の区画のためには，使用可能空間表の値は#FFFFFFFF
に設定されなければならない。
b) アクセス種別が再生専用の区画のためには，使用可能空間表の値は0に設定されなければならない。
それ以外の場合，有効な使用可能空間の量が不明なことを示す#FFFFFFFFの任意選択値は，使用しては
ならない。
注記 論理ボリューム保全記述子をクローズ状態にしたときだけ，正しい使用可能空間表を保証する。
2.2.6.3
サイズ表（Uint32 SizeTable[]）
ほとんどのOSは，媒体のマウント時に，処理システムが論理ボリュームの大きさを提供することを要
求するため，これらの値を全ての非仮想区画に保守することは重要となる。区画長が不明なことを示す
#FFFFFFFFの任意選択値は仮想区画に使用してはならない。仮想区画については，サイズ表の値を
#FFFFFFFFに設定しなければならない。
2.2.6.4
処理システム用（byte ImplementationUse[]）
論理ボリューム保全記述子（Logical Volume Integrity Descriptor）の処理システム用（ImplementationUse）
領域は，表10に示す構成でなければならない。
表10−処理システム用フォーマット（ImplementationUse format）
RBP
長さ
名前
内容
0
32
処理システム識別子（ImplementationID）
EntityID
32
4
ファイル数（Number of Files）
Uint32
36
4
ディレクトリ数（Number of Directories）
Uint32
40
2
UDF読出し最小版数（Minimum UDF Read Revision）
Uint16
42
2
UDF書込み最小版数（Minimum UDF Write Revision）
Uint16
44
2
UDF書込み最大版数（Maximum UDF Write Revision）
Uint16
46
L̲IU−46 処理システム用（Implementation Use）
バイト
特記事項 VATを使用する逐次ファイルシステムでは，ImplementationID及びImplementation Use欄以
24
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
外の表10の全ての欄の値が対応するVATの欄の値によって上書きされる。2.2.11参照。
a) 処理システム識別子（ImplementationID）：処理システム識別子は，実体識別子の有効範囲内のどれか
を最後に更新した処理システムの実体識別子。実体識別子の有効範囲は，論理ボリューム識別子及び
関連する論理ボリュームの内容である。この欄は，論理ボリュームの内容を最後に更新した処理シス
テムを識別することを可能とする。
b) ファイル数（Number of Files）：論理ボリューム中の現状のハードリンクを含むファイルの個数。個数
には，ディレクトリビット，親ビット及び消去済みビットの全てがZEROであるディレクトリ階層中
のFIDが全て含まれる。名前付きストリームを識別するFIDは，個数には含まれない。全ての処理シ
ステムは，この情報を保守しなければならない。
c) ディレクトリ数（Number of Directories）：論理ボリューム中のルートディレクトリを含むディレクト
リの現状の個数。個数にはルートディレクトリ，及びディレクトリ階層中のディレクトリビットが
ONEであり，親ビット，消去済みビットの双方がZEROである全てのFIDが含まれる。ストリーム
を識別するFIDは，個数には含まれない。全ての処理システムは，この情報を保守しなければならな
い。
d) UDF読出し最小版数（Minimum UDF Read Revision）：この媒体中の全ての構造を読み出すために，処
理システムが利用可能とする必要があるUDF版数の最小値でなければならない。この番号は，2進化
10進表示で記録しなければならない。例えば，#0250はUDF 2.50を示す。それ以上の要件は，箇条2
の基本制約及び基本要件を参照。
e) UDF書込み最小版数（Minimum UDF Write Revision）：この媒体中の全ての構造を更新するために，処
理システムが利用可能とする必要があるUDF版数の最小値でなければならない。この番号は，2進化
10進表示で記録しなければならない。例えば，#0250はUDF 2.50を示す。
f)
UDF書込み最大版数（Maximum UDF Write Revision）：媒体中を更新した処理システムが利用可能とす
るUDF版数の最大値でなければならない。処理システムは，媒体の更新によって，媒体がこの欄の現
状の値より大きいUDF版数を必要とするようになった場合だけ，この欄を更新しなければならない。
この番号は，2進化10進表示で記録しなければならない。例えば，#0260は，UDF 2.60を示す。
g) 処理システム用（Implementation Use）：処理システム識別子で識別する処理システムだけの固有情報
を含む。
2.2.7
処理システム用ボリューム記述子（Implementation Use Volume Descriptor）
struct ImpUseVolumeDescriptor{ /* JIS X 0607 3/10.4 */
struct tag
DescriptorTag;
Uint32
VolumeDescriptorSequenceNumber;
struct EntityID
ImplementationIdentifier;
byte
ImplementationUse[460];
}
この2.2.7は，UDF処理システム用ボリューム記述子を定義する。この記述子はボリューム集合の全て
のボリュームに記録しなければならない。ボリュームは，処理システム固有の追加の処理システム用ボリ
ューム記述子を含んでもよい。この記述子の意図する目的は，特定の論理ボリュームに属するボリューム
集合中のボリュームの識別を支援することである。
特記事項 処理システムは，媒体中にそれ自体のフォーマットにおける追加の処理システム用ボリュ
ーム記述子を記録してもよい。UDF処理システム用ボリューム記述子は，追加の記述子を
25
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
除外しない。
2.2.7.1
処理システム識別子（EntityID ImplementationIdentifier）
この欄は“*UDF LV Info”を指定しなければならない。実体識別子については2.1.5を参照。
2.2.7.2
処理システム用（byte ImplementationUse[460]）
処理システム用領域は，次に示す構造でなければならない。
struct LVInformation{
struct charspec
LVICharset;
dstring
LogicalVolumeIdentifier[128];
dstring
LVInfo1[36];
dstring
LVInfo2[36];
dstring
LVInfo3[36];
struct EntityID
ImplementationID;
byte
ImplementationUse[128];
}
2.2.7.2.1
論理ボリューム情報用文字集合（charspec LVICharset）
a) 意味：論理ボリューム識別子（LogicalVolumeIdentifier）欄及び論理ボリューム情報（LVInfo）欄で使用
可能な文字集合の指定と解釈する。
b) 設定値：2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。
2.2.7.2.2
論理ボリューム識別子（dstring LogicalVolumeIdentifier[128]）
この記述子で参照する論理ボリュームの識別子。
2.2.7.2.3
論理ボリューム情報（dstring LVInfo1[36], LVInfo2[36], LVInfo3[36]）
論理ボリューム情報欄（LVInfo1，LVInfo2及びLVInfo3）は，媒体の識別を支援する追加情報を含むこ
とが望ましい。例えば，論理ボリューム情報欄は，所有者名，組織名及び連絡先の情報を含むことができ
る。
2.2.7.2.4
処理システム識別子（struct EntityID ImplementionID）
実体識別子に関する2.1.5を参照。
2.2.7.2.5
処理システム用（byte ImplementationUse[128]）
この領域は，追加の処理システム固有の情報を記録するために処理システムで使用してもよい。
2.2.8
仮想区画マップ
これは，JIS X 0607規格類の範囲を拡大し，連続書込み媒体（例えば，CD-R）を含んだものである。こ
れを拡大したのは，区画マップエントリが仮想空間を記載するためである。
論理ボリューム記述子には，与えられたボリュームを構成する区画の一覧が含まれる。仮想区画は，物
理区画と同じ方法で記載することはできないので，次に指定する種別2区画マップを使わなければならな
い。
仮想区画マップが記録されると，論理ボリューム記述子は，最低二つの区画マップを含まなければなら
ない。一つの区画マップは種別1の区画マップとして記録しなければならない。もう一つの区画マップは
種別2区画マップとして記録しなければならない。この種別2の区画マップのフォーマットは，表11に指
定されたとおりでなければならない。
26
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表11−仮想区画に関する種別2区画マップの配置
（Layout of Type 2 Partition Map for virtual partition）
RBP
長さ
名前
内容
0
1
区画マップ種別（Partition Map Type）
Uint8=2
1
1
区画マップ長（Partition Map Length）
Uint8=64
2
2
予約（Reserved）
#00バイト
4
32
区画種別識別子（Partition Type Identifier）
EntityID
36
2
ボリューム列番号（Volume Sequence Number）
Uint16
38
2
区画番号（Partition Number）
Uint16
40
24
予約（Reserved）
#00バイト
注記1 区画種別識別子：
− フラグ = 0
− 識別子 = *UDF Virtual Partition
− 識別子添字は，2.1.5に定義されるとおりに記録する。
注記2 ボリューム列番号 = VAT及び区画を記録するボリューム
注記3 区画番号 = 同じ論理ボリューム記述子に含まれる種別1区画マップ内の区画番号
2.2.9
予備区画マップ
ディスクドライブシステムの中には，欠陥管理を行わないものもある（例えば，CD-RW）。これらのシ
ステムに明らかに欠陥のない空間を与えるために，種別2の区画が使われる。区画マップは，区画番号，
パケットサイズ（1.3.2参照），並びに予備表の大きさ及び位置を定義する。この種別2の区画マップは，
通常の媒体にある種別1の区画マップと置き換えることを意図している。予備区画マップが記録された場
合は種別1の区画マップを記録してはならない。予備区画マップは，区画番号とボリューム列番号とを識
別するだけでなく，パケット長及び予備表を識別する。予備区画マップは，欠陥管理を行うディスクドラ
イブシステムに記録してはならない（表12参照）。
27
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表12−予備区画に関する種別2区画マップの配置
（Layout of Type 2 Partition Map for sparable partition）
RBP
長さ
名前
内容
0
1
区画マップ種別（Partition Map Type）
Uint8=2
1
1
区画マップ長（Partition Map Length）
Uint8=64
2
2
予約（Reserved）
#00バイト
4
32
区画種別識別子（Partition Type Identifier）
EntityID
36
2
ボリューム列番号（Volume Sequence Number）
Uint16
38
2
区画番号（Partition Number）
Uint16
40
2
パケット長（Packet Length）
Uint16
42
1
予備表数（=N̲ST）［Number of Sparing Tables(=N̲ST)］
Uint8
43
1
予約（Reserved）
#00バイト
44
4
各予備表の大きさ（Size of each sparing tables）
Uint32
48
4×N̲ST
予備表の位置（Locations of each sparing tables）
Uint32
48＋4×N̲ST
16−4×N̲ST
パッド（Pad）
#00バイト
注記1 区画種別識別子：
− フラグ = 0
− 識別子 = *UDF Sparable Partition
− 識別子添字は，2.1.5に定義されるとおりに記録される。
注記2 区画番号 = この区画の番号。この区画に関連する区画記述子を識別することが望ましい。
注記3 パケット長 = 固定パケットごとの利用者データブロック数。この値は箇条6の媒体固有の規定において示
す。
注記4 予備表数 = 記録された冗長な表の数。これは1〜4の範囲の値が望ましい。
注記5 各予備表数 = 各予備表に割り付けられるバイト数。
注記6 予備表の位置 = 媒体ブロック番地として指定される各予備表のスタート位置。処理システムでは，各予備
表のスタートをパケットの始めに合わせることが望ましい。処理システムでは，最小二つの予備表を物理
的に離れている位置に記録することが望ましい。
2.2.10 メタデータ区画マップ
単一の区画でアクセス種別が種別0（疑似上書き可能），種別1（再生専用）又は種別4（上書き可能）
を含み，LVDに仮想区画マップが記録されていないボリュームは，メタデータ区画マップが記録されなけ
ればならない。一つのボリューム上に二つの重なり合わない区画があり，片方のアクセス種別が再生専用
でもう一方が上書き可能な特別な場合，メタデータ区画マップが上書き可能区画に関連しなければならな
い。それ以外の全ての場合には，メタデータ区画マップは記録してはならない（表12a参照）。
メタデータ区画についての更に詳しい説明については，2.2.13を参照。
表12a−メタデータ区画に関する種別2区画マップの配置
（Layout of Type 2 Partition Map for metadata partition）
オフセット
長さ
名前
内容
0
1
区画マップ種別（Partition Map Type）
Uint8 = 2
1
1
区画マップ長（Partition Map Length）
Uint8 = 64
2
2
予約（Reserved）
#00バイト
4
32
区画種別識別子（Partition Type Identifier）
EntityID
36
2
ボリューム列番号（Volume Sequence Number）
Uint16
38
2
区画番号（Partition Number）
Uint16
40
4
メタデータファイル位置（Metadata File Location）
Uint32
44
4
メタデータ控えファイル位置（Metadata Mirror File Location）
Uint32
28
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表12a−メタデータ区画に関する種別2区画マップの配置
（Layout of Type 2 Partition Map for metadata partition）（続き）
オフセット
長さ
名前
内容
48
4
メタデータビットマップファイル位置（Metadata Bitmap File Location）
Uint32
52
4
割付け単位サイズ（ブロック数）［Allocation Unit Size(blocks)］
Uint32
56
2
整列単位サイズ（ブロック数）［Alignment Unit Size(blocks)］
Uint16
58
1
フラグ（Flags）
Uint8
59
5
予約（Reserved）
#00バイト
注記1 区画種別識別子：
− フラグ = 0
− 識別子 = *UDF Metadata Partition
− 識別子添字は，2.1.5のとおりに記録される。
注記2 区画番号 = この区画の番号。この区画に関連する区画記述子を識別しなければならない。これは媒体の種
別に適切に記録されなければならない唯一の，種別1マップ又は種別2予備マップの区画番号と一致しな
ければならない。
注記3 メタデータファイル位置 = メタデータファイルのファイルエントリを含むブロックのアドレス。このアド
レスは，区画マップに関連する物理区画内又は予備区画内の論理ブロックアドレスとして解釈されなけれ
ばならない（注記2の区画番号欄を参照）。
注記4 メタデータ控えファイル位置 = メタデータファイルのファイルエントリを含むブロックのアドレス。この
アドレスは，区画マップに関連する物理区画内又は予備区画内の論理ブロックアドレスとして解釈されな
ければならない（注記2の区画番号欄を参照）。
注記5 メタデータビットマップファイル位置 = メタデータビットマップファイルのファイルエントリを含むブ
ロックのアドレス。このアドレスは，区画マップに関連する物理区画内又は予備区画内の論理ブロックア
ドレスとして解釈されなければならない（注記2の区画番号欄を参照）。メタデータビットマップファイル
位置の欄の値が#FFFFFFFFである場合，メタデータビットマップファイルのファイルエントリは定義され
ない。
注記6 割付け単位サイズ = この区画マップに関連するメタデータファイル（又は控えファイル）の割付け単位ご
との論理ブロックの数。この値は，次の三つの値より大きい数の整数倍でなければならない。
− 媒体のECCブロック長を論理ブロック長で除した商
− パケット長（種別2予備区画マップが記録されている場合）
− 32
注記7 整列単位サイズ = メタデータファイル（又は控えファイル）に割り付けられた全てのエクステントの開始
論理ブロック番号は，この値の整数倍でなければならない。この値は，次の値より大きい数の整数倍でな
ければならない。
− 媒体のECCブロック長を論理ブロック長で除した商
− パケット長（種別2予備区画マップが記録されている場合）
注記8 フラグ
− Bit 0 = 複製メタデータフラグ。これがセット（ONE）された場合，メタデータ控えファイルは独自の
割付けをもつことを示す（すなわち，メタデータファイルのデータを複製したものである。）。これが
クリア（ZERO）された場合，メタデータ控えファイルの割付け記述子は，メタデータファイルの割付
け記述子と同じ割付けを記述していることを示す（すなわち，データは複製されてなく，主ファイル
及び控えファイルが同じデータブロックを共有しているが，各ファイルエントリ及びその関連する割
付け記述子は一意で異なる。）。
− Bit 1-7 = 予約。書込み時にはZEROにセットされなければならず，読出し時には無視されなければな
らない。
特記事項1 メタデータ区画は，LVIDにサイズ表及び使用可能空間表のエントリをもたなければなら
ない（2.2.6参照）。
特記事項2 メタデータファイル位置，メタデータ控えファイル位置及びメタデータビットマップフ
ァイル位置のUint32の欄は，ファイルエントリ位置を識別する。各ファイルエントリに
29
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
割り付けられるブロック数は，1論理ブロックでなければならない。
2.2.11 仮想割付け表
仮想割付け表（VAT）（表13参照）は，連続書込み媒体（例えば，CD-R）に使われ，ランダムに書込み
可能な媒体のようにシステムに見せかけるために用いられる。VATは連続書込み媒体（例えば，CD-R）に
だけ記録しなければならない。
VATは仮想番地を論理番地に変換するマップである。これは，ファイルエントリICB（VAT ICB）で識
別されるファイルとして記録しなければならないが，表を構築する場合，大幅な柔軟性を認める。VAT ICB
はいかなる処理でも，最後に記録されるセクタである。VAT自体は，どの位置に記録してもよい。
VATは，ファイル種別248のファイルエントリICBによって識別しなければならない。このICBは，記
録された最後の有効データセクタでなければならない。エラー修復計画は，ファイル種別248をもつICB
を見つけることで，最後の有効なVATを見つけることができる。
このファイルは，小さいときは，記載するICBに埋め込むことができる。大きくなると，ICBに先行す
るセクタに記録できる。セクタは，隣接する必要はないが，必要に応じて表の新しい部分にだけ書込みが
できる。これによって，多くのディレクトリをもつディスクでも，僅かな増加分の更新が可能になる。
VATが小さいとき（ディスク上の少数ディレクトリ），VATは，埋込みVATで新しいファイルICBを書
き込むことによって更新される。VATが大きくなりすぎてICBに合わなくなると，VATで一つのセクタを
書き込み，ICBで他のセクタを書き込むことが必要になる。この点を超えると，VATのために複数のセク
タが必要になる。しかし，複数のエクステントが利用可能になるため，VATの更新は，全てのVATを示す
ポインタでICBを更新し書き込む必要のあるセクタだけを，書き込むだけでよい。
VATは，ある種の情報を求める要求を，適切な論理位置に転送するために使う。この表を用いた間接的
アクセス方法で，直接的な上書き能力があるかのように見せかけることができる。例えば，ルートディレ
クトリを記載するICBは仮想セクタ1として参照できる。仮想セクタは，仮想区画マップエントリによっ
て識別する区画に含まれる。ディスクを更新する過程でルートディレクトリが変わるかもしれない。変わ
る場合，ルートディレクトリを記載する新しいセクタが書き込まれ，論理ブロック番地は，仮想セクタ1
に対応する論理ブロック番地として記録される。仮想セクタ1を参照するものは，たとえ，新しい論理ブ
ロック番地に存在していても，現存するうちで最新の仮想セクタ1を示すため，変わる必要はない。
仮想番地付けの使用によって，要求された構造の実効上の上書きが可能になる。この構造は，参照する
全てのポインタが，仮想番地だけでできるとき，書換え可能になる。書換え構造が書き込まれると，仮想
の参照は変わる必要がなくなる。VATへの適切なエントリは，対応する仮想番地の新しい論理ブロック番
地を反映するように変えられ，その後あらゆる仮想の参照は間接的に新しい構造を示す。ディレクトリICB
のとおりに，更新が必要な全ての構造は，仮想番地で参照しなければならない。各構造が更新されると，
VAT ICB内の対応するエントリが更新されなければならない。
VATは，Uint32エントリの連続としてファイルに記録されなければならない。各エントリは，VATが位
置する物理区画へのセクタ数でのオフセットでなければならない。最初のエントリは，仮想区画セクタ0
でなければならず，2番目のエントリは仮想区画セクタ1でなければならず，以降同様でなければならな
い。Uint32エントリはVATヘッダに続かなければならない。事前のVAT ICBの入力によって，前の状態
のようなファイルシステムを一覧できる。この欄が#FFFFFFFFである場合，そうしたICBは，指定されな
い。
30
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表13−仮想割付け表構造（Virtual Allocation Table structure）
オフセット
長さ
名前
内容
0
2
ヘッダの長さ（=L̲HD）[Length of Header (=L̲HD)]
Uint16
2
2
処理システム用の長さ（=L̲IU）[Length of Implementation Use (=L̲IU)]
Uint16
4
128
論理ボリューム識別子（Logical Volume Identifier）
dstring
132
4
VAT ICB前位置（Previous VAT ICB location）
Uint32
136
4
ファイル数（Number of Files）
Uint32
140
4
ディレクトリ数（Number of Directories）
Uint32
144
2
UDF読出し最小版数（Minimum UDF Read Revision）
Uint16
146
2
UDF書込み最小版数（Minimum UDF Write Revision）
Uint16
148
2
UDF書込み最大版数（Maximum UDF Write Revision）
Uint16
150
2
予約（Reserved）
#00バイト
152
L̲IU 処理システム用（Implementation Use）
バイト
152＋L̲IU
4
VATエントリ0（VAT entry 0）
Uint32
156＋L̲IU
4
VATエントリ1（VAT entry 1）
Uint32
…
…
…
…
情報の長さ−4
（Information Length
−4）
4
VATエントリn（VAT entry n）
Uint32
a) ヘッダの長さ（Length of Header）：VATエントリに先行するデータの量を識別する。この値は，152＋
L̲IUでなければならない。
b) 処理システム用の長さ（Length of Implementation Use）：処理システム用欄のバイト数を指定しなけれ
ばならない。この欄が0でない場合，この値は，最低32で4の整数倍でなければならない。
c) 論理ボリューム識別子（Logical Volume Identifier）：論理ボリュームを識別しなければならない。この
欄は，論理ボリューム識別子で対応する欄の代わりに，処理システムで使用しなければならない。こ
の欄の値は，利用者が変更するまで，LVDの欄と同じであることが望ましい。
d) VAT ICB前位置（Previous VAT ICB location）：区画マップエントリで識別される区画において，前の
VAT ICBの論理ブロック番号を指定しなければならない。この欄が#FFFFFFFFのとき，ICBは指定さ
れない。
e) ファイル数（Number of Files）：2.2.6.4の定義による。この欄の内容は，対応するLVID欄に代わって，
使用されなければならない。
f)
ディレクトリ数（Number of Directories）：2.2.6.4の定義による。この欄の内容は，対応するLVID欄に
代わって，使用されなければならない。
g) UDF読出し最小版数（Minimum UDF Read Revision）：2.2.6において定義されている。この欄の内容は，
対応するLVID欄に代わって，使用されなければならない。
h) UDF書込み最小版数（Minimum UDF Write Revision）：2.2.6において定義されている。この欄の内容は，
対応するLVID欄に代わって，使用されなければならない。
i)
UDF書込み最大版数（Maximum UDF Write Revision）：2.2.6において定義されている。この欄の内容は，
対応するLVID欄に代わって，使用されなければならない。
j)
処理システム用（Implementation Use）：長さが0でない場合，処理システム用領域の残りの使用を識
別する実体識別子から始める。
k) VATエントリ（VAT entry）：VATエントリnは，仮想ブロックnの論理ブロック番号を識別しなけれ
31
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ばならない。#FFFFFFFFのエントリは，仮想セクタが現在使用されていないことを示している。LBN
指定は，区画マップエントリで識別される区画に位置する。表のエントリの数は，ICBのVATファイ
ルサイズから決定できる。
エントリ数 =（情報の長さ−L̲HD）/ 4
2.2.12 予備表
ディスクドライブシステムの中には，欠陥管理を行わないものもある（例えば，CD-RW）。予備表は，
これらのシステムに見かけ上欠陥のない空間を作るために用いられる。特定の媒体では，セクタのまとま
り（パケット）にだけ書込みができ，再配置を更に複雑にする。これは，セクタだけが書き込まれるので
はなく，パケット全体を再配置しなければならないことによる。この問題に取り組むため，区画マップが
予備区画を識別し，予備表の位置を更に識別する。予備表は，媒体上で再配置された領域を識別する。予
備表は，予備区画マップで識別される。予備表は，欠陥管理を行うディスクシステム･ドライブシステムに
記録してはならない。
予備表は，予備用に割り付けられた空間を示し，取替え部分に対する欠陥セクタの配置リストを含む。
予備表の分離コピーは，分離パケットに記録しなければならない。予備表は，最新のものを維持しなけれ
ばならない。
区画マップの論理空間を物理空間へ配置する。通常，これは，オフセットと長さとが指定される直線配
置である。予備区画では，この配置に基づくが，物理空間内の区画のオフセットと長さとは，区画記述子
（2.2.14参照）で指定される。予備区画は一つのパケットの境界で始まり，かつ，一つのパケットの境界
で終わらなければならない。予備表は，更に論理配置から物理配置への例外リストを指定する。あらゆる
配置の長さは，パケット一つ分である。パケットサイズは，予備区画マップで指定される。
予備領域及び予備表のインスタンスは，媒体のどの部分でも，つまり区画の内外いずれでもよい。区画
に重なっている場合，重なっている部分は割り付けられたとして表示されなければならず，割付け禁止空
間ストリームに含まれなければならない。マップされた位置は，フォーマット時に埋めることが望ましい。
元の位置は，エラーが起こると，動的に割り当てられる。各予備表は，表14の構造でなければならない。
表14−予備表配置（Sparing Table layout）
BP
長さ
名前
内容
0
16
記述子タグ（Descriptor Tag）
タグ=0
16
32
予備識別子（Sparing Identifier）
EntityID
48
2
再割付け表長（= RT̲L）［Reallocation Table Length (= RT̲L)］
Uint16
50
2
予約（Reserved）
#00バイト
52
4
列番号（Sequence Number）
Uint32
56
8×RT̲L
マップエントリ（Map Entry）
マップエントリ
この構造は，必要ならば一つのセクタより大きくてもよい。
a) 記述子タグ
タグ識別子0を含むが，これは，記述子タグのフォーマットが，JIS X 0607規格類で指定されていな
いことを示す。記述子タグの他の欄は，全てタグ識別子は，JIS X 0607規格類で定義された値である
かのように，有効でなければならない。
b) 予備識別子：
1) フラグ = 0
2) 識別子 = *UDF Sparing Table
32
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3) 識別子添字は，2.1.5に規定されるとおりに記録される。
c) 再割付け表長
マップエントリ表のエントリの数を示す。
d) 列番号
予備表更新の都度，増加する数を含む。
e) マップエントリ
マップエントリは，表15に記述される。マップは元の位置の欄によって昇順に分類しなければならな
い。
表15−マップエントリ記述（Map Entry description）
RBP
長さ
名前
内容
0
4
元の位置（Original Location）
Uint32
4
4
マップ位置（Mapped Location）
Uint32
f)
元の位置
パケットの論理ブロック番地を予備とする。パケットの番地は，パケットの最初の利用者データブロ
ックの番地とする。この欄が#FFFFFFFFのとき，このエントリは，予備のために可能となる。この欄
が#FFFFFFF0のとき，対応するマップ位置は欠陥と表示され，マッピングには使わないことが望まし
い。#FFFFFFFF〜#FFFFFFF1の元の位置は，予約しておく。
g) マップ位置
動作中のデータの物理ブロック番地。元のパケット位置への要求は，ここで識別されるパケット位置
に転送される。マップ位置のエントリは全て有効で，元の位置が#FFFFFFF0，#FFFFFFFF，又は予約
であるエントリを含む。マップ位置が区画と重なる場合，その区画は，割付け済みと表示された空間
をもち，その空間は，割付け禁止空間ストリームの一部に入れなければならない。
2.2.13 メタデータ区画（Metadata Partition）
2.2.13で定義するファイル及び方針は，ボリューム中の全てのメタデータの迅速な位置決定を容易にし，
ICB／ディレクトリ情報のクラスタリングを促進し，更にオプションでメタデータの複製を容易にする。
これはほとんどの場合に，単にICBの位置を決定するために行う，完全な媒体スキャン又はディレクトリ
の横断解析を実行する必要性を取り除くことによって，ファイルシステムの高速な修復作業に大きく貢献
する。メタデータのクラスタリングは，更にメタデータを内包する実装の演算の性能を著しく改善する。
メタデータの複製のオプションが選択された場合，ある程度の性能の低下はあるが，ファイルシステムの
媒体損傷に対する堅ろう（牢）性は向上する。
種別2のメタデータ区画マップが記録される場合，メタデータファイル，メタデータ控えファイル，及
びメタデータビットマップファイルも記録され保守されなければならない。例外としてメタデータビット
マップファイルは，再生専用区画及び疑似上書き可能区画に記録されてはならない。
メタデータ控えファイルのファイルエントリの割付け記述子は，次のいずれかでなければならない。
a) メタデータファイルの割付け記述子で参照されたのと同じ物理区画又は予備区画のエクステントを参
照する。この場合，メタデータ区画マップのフラグ欄の複製メタデータフラグを設定してはならない。
b) 違うエクステントを参照する。すなわち，全てのメタデータを複製する。この場合，メタデータ区画
マップのフラグ欄の複製メタデータフラグを設定しなければならない。
33
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
メタデータファイル，メタデータ控えファイル，及びメタデータビットマップファイルのファイルエン
トリは，メタデータ区画マップ以外のいかなる構造からも参照されてはならず，ファイルリンク数は0で
なければならない。これらのファイルがある場合は，メタデータ区画マップによって参照される物理区画
又は予備区画に記録されなければならない。
メタデータ区画マップ（2.2.10参照）は区画空間を定義する。そこには全てのメタデータ（FSD，ICB，
割付け記述子，及びディレクトリのデータ）が記録されなければならないが，前述のとおりメタデータフ
ァイル，メタデータ控えファイル，及びメタデータビットマップファイルを構成するICB及びデータだけ
は例外である。
ディレクトリ又はストリームディレクトリを記述するファイルエントリは，ディレクトリのデータ空間
を記述するために，“直接”参照（すなわち，データがファイルエントリに埋め込まれている。[4/14.6.8]
のフラグビット0-2欄参照），又はshort ad割付け記述子を用いなければならない。これはこのデータが，
ファイルエントリそのものとともにメタデータ区画に存在することによる。
他の種類の（名前付きストリームを含む）ファイルデータを記述するファイルエントリは，ファイルの
データ空間を記述するために，“直接”参照，又はメタデータ区画マップによって参照される物理区画又は
予備区画を参照するlong ad割付け記述子を用いなければならない。2.2.10で示した再生専用区画及び上書
き可能区画が一つのボリューム上にある，特別な二つの区画の場合，ファイル又は名前付きストリームの
データ空間もまた再生専用区画に割り付けられてもよい。
メタデータ区画に記録された全ての割付け記述子のエクステント位置（Extent Location）欄は，メタデー
タファイルのブロックでのオフセットとして解釈されなければならない。例えば，メタデータ区画の論理
ブロック40は，メタデータファイルのバイトでのオフセット（40 * 論理ブロック長）に相当し，それは
（メタデータファイルの割付け記述子を介して）関連する物理区画又は予備区画のいずれかの論理ブロッ
クに相当する。
実装は，メタデータ控えファイルについて複製及び共有の両方の割付けモードをサポートしなければな
らない（上記及び2.2.10メタデータ区画マップのフラグ欄参照）。メタデータ控えファイルのファイルエ
ントリは，メタデータファイルのファイルエントリと一致して有効に保守されなければならないが，メタ
データファイルのファイルエントリの後に更新されることが望ましい。
メタデータ区画マップのフラグ欄の複製メタデータフラグがセットされた場合は，メタデータ控えファ
イルは，メタデータファイルと常に同一な内容を含むように動的に保守されなければならない。メタデー
タファイル及びメタデータ控えファイルの使われていない論理ブロックは，同一でなくてもよい。この場
合メタデータ区画のブロックは，メタデータ控えファイル又はメタデータファイルの同じオフセットのど
ちらから読んでもよい。データは，まずメタデータファイルに書き込まれ，次にメタデータ控えファイル
に書き込まれることが望ましい。
メタデータ区画マップのフラグ欄の複製メタデータフラグがセットされている場合，実装及び修復ユー
ティリティはメタデータファイルの内容がメタデータ控えファイルの内容に優先すると考える方が望まし
い。例えば，修復ユーティリティは，メタデータファイルから読み出した（読出し不能な部分は控えから
読み出せる）メタデータに基づいてボリュームを修復することができ，その後メタデータ控えファイルの
内容を（既に一貫性のある）メタデータファイルのそれで置き換えることができる。
メタデータ又はメタデータ控えファイルに割り付けられた論理ブロックは，未割付け空間ビットマップ
において割付け済みとしてマークされなければならない。そのためメタデータ区画内の利用可能なブロッ
ク数を決定する仕組みが必要となる。これは，メタデータビットマップファイルによって達成される。メ
34
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
タデータビットマップファイルは，再生専用区画及び疑似上書き可能区画に記録されてはならない。
図0−メタデータ区画
特記事項 図0の中のLBNの値は，説明用であって固定されていない。区画参照番号は，LVDの区
画マップによって決定される。
これらのファイルのより詳しい説明及びどのように使われるかについては，2.2.13.1に示す。
2.2.13.1 メタデータファイル（及びメタデータ控えファイル）
これらのファイルは，そのファイルエントリのICBタグのファイル種別（File Type）欄の値が250（メ
タデータファイル）か251（メタデータ控えファイル）でなければならない。これらのファイルエントリ
の一意ID（UniqueID）欄の値は0でなければならない。
これらのファイルの割付け記述子（2.3.10参照）は，常に次のとおりでなければならない。
a) short̲adを使用する（そのICBが存在するのと同じ物理区画又は予備区画の空間を参照）。
b) 種別が“割付け済みであるが未記録”であるエクステントを指定しない。
35
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
c) 種別が“割付け済みかつ記録済み”又は“未割付け”であるエクステントは，［割付け単位サイズ
（Allocation Unit Size）と論理ブロック長との積］の整数倍のエクステント長をもたなければならない。
割付け単位サイズは，メタデータ区画マップで指定される。
d) 種別が“割付け済みかつ記録済み”であるエクステントは，メタデータ区画マップで指定された整列
単位サイズ（Alignment Unit Size）の整数倍である開始論理ブロック番号をもたなければならない。
これらのファイルのファイルエントリの情報長欄は，ADで記述されたブロック数と論理ブロック長と
の積に等しくなければならない。
これらのファイルの割付け記述子は，次のデータ種別の一つを含む論理ブロックだけを記述しなければ
ならない。ユーザデータ又はその他のメタデータは参照してはならない。
a) FSD
b) 終端記述子
c) ICB
d) 割付け記述子のエクステント（2.3.11参照）
e) ディレクトリ又はストリームディレクトリのデータ（例えば，FID）
f)
使用可能な未使用ブロック
特記事項 ファイルエントリ及び可能なメタデータファイルの割付けエクステント記述子は，複製メ
タデータファイルのそれらと（物理的に）可能な限り離れていることが望ましい。メタデ
ータ区画マップの複製メタデータフラグ（Duplicate Metadata Flag）がセットされている場
合，これらの二つのファイルの割り付けられたエクステントの数は同じになる。通常，離
れて記録することは，ファイル及びその控えのエクステントの開始LBNの差を最大にす
ることで達成される。幾つかのドライブ又は媒体は，“バックグラウンド物理フォーマッ
ティング”（6.13及び6.14参照）又は“インクリメンタルフォーマッティング”の組合せ
をサポートしており，このような機能を使用する処理システムは，メタデータファイル及
びデータを割り当てるときに考慮することが望ましい。このような場合，迅速な取出し又
は媒体の読出し容易性に影響を及ぼさずにファイルの場所を離すことは実際不可能であ
るかもしれない。
メタデータファイル及び控えファイルのファイルエントリの読み書き時間（Access Time）欄及び変更時
間（Modification Time）欄は，フォーマッティング時に正しい値に設定されなければならないが，ファイ
ルシステムによって更新される必要はない。
メタデータファイル及びメタデータ控えファイルのファイルエントリは，NULLストリームディレクト
リICB欄及び拡張属性ICB欄がなければならない。
2.2.13.2 メタデータビットマップファイル
このファイルは，そのファイルエントリのICBタグのファイル種別（File Type）欄の値が252でなけれ
ばならない。これらのファイルエントリの一意ID（UniqueID）欄の値は，0でなければならない。
このファイルは，メタデータファイルに割り当てられたブロックの使用状況を記述するスペースビット
マップ記述子を含む。すなわち，メタデータ区画に割り当てられた空間を記述するビットマップである。
ビットマップの位置0のビットは，前述のファイルの最初のブロックに該当し，位置1のビットは2番目，
以下同様となる。これは，メタデータ控えファイルにも適用される。メタデータファイルとメタデータ控
えファイルとは，メタデータ区画マップのフラグ欄の複製メタデータフラグにかかわらず，ファイル内容
36
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
が一致しているからである。
このビットマップのビットがセットされている（ONE）場合，メタデータファイル又は複製メタデータ
ファイル内の該当するブロックは，新規のメタデータ用に使用可能であることを示す。
特記事項 メタデータ区画マップのフラグ欄の複製メタデータフラグがセットされていない場合は，
これらのブロックは，複製メタデータファイルの割付け記述子がメタデータファイルの対
応するブロックと同一のブロックを指すため，同一の一つのブロックである。
このビットマップのビットがクリアされている（ZERO）場合は，該当するブロックは新規のメタデー
タ用に使用不可能，すなわち，それらのブロックが使用中であるか，又はメタデータファイルの割り付け
られていない領域に位置するか，のどちらかである。
その他のメタデータファイルの要件を次に示す。
a) このSBDの記述子タグの記述子CRC長欄は，0又は8に設定されなければならない。値8が推奨さ
れる。
b) メタデータビットマップファイルの割付け記述子は，“未割付け”である種別の割付け記述子を含んで
はならない。
c) このファイルのファイルエントリの情報長欄は，SBDの大きさと同じでなければならない（特記事項:
SBDの大きさにはビットマップ部が含まれる。）。
d) メタデータ区画の各ブロックに対して，ビットマップに1ビットが存在しなければならない。
e) メタデータビットマップファイルのファイルエントリのアクセス日時欄及び変更日時欄は，初期化時
に有効な値が設定されていなければならないが，ファイルシステムによって更新される必要はない。
f)
メタデータビットマップファイルのファイルエントリのストリームディレクトリICB欄及び（拡張FE
の場合）拡張属性ICB欄は，NULLでなければならない。
g) このSBDのタグ位置（TagLocation）欄の記述子は，メタデータビットマップファイルに割り付けられ
た最初のブロックの論理ブロック番号に設定されなければならない。
2.2.13.3 新規のメタデータに対するブロック割付けの手順
メタデータビットマップファイルからセット（ONE）されたビットを探し，それをクリアする。その後，
メタデータ区画［メタデータファイル及び（複製モードの場合は）複製メタデータファイル］内の該当す
るブロックを新たなデータのために使用してよい。メタデータファイル（及び複製時には複製メタデータ
ファイル）にセット（ONE）されたビットがなかった場合，ファイルは2.2.13.5に示すとおりに拡張され
なければならない。
2.2.13.4 メタデータブロックの割付け解除の手順
メタデータビットマップファイルの，メタデータ区画内の割付け解除しようとするブロック番号に該当
するビットをセット（ONE）する。
2.2.13.5 メタデータ区画の推奨される拡張の手順
2.2.13.5で示す変更は，新たに割り付けられたブロックがメタデータのために使用される前にドライブ
（最終的には媒体）に書き込まれなければならない。これらの変更が処理システムの書込みキャッシュに
長くとどまってしまい，変更によって記述されたブロックに割り当てられた新たなメタデータが先に媒体
に書き込まれてしまうことは望ましくない。
a) メタデータファイル及びメタデータ控えファイル割付け記述子に新たな割付け記述子をつなぐのに十
分な場所があることを確認する。ない場合は，新たな割付け記述子エクステントを割り付ける。
b) メタデータビットマップファイルの割付けが，メタデータファイルに追加された追加ブロックの記述
37
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
のためのビットマップの拡張に，十分広いことを確認する。足りない場合は，メタデータビットマッ
プファイルにブロックを割り付ける。
c) （メタデータファイル）のための新たなエクステントのブロックをサイズ及び2.2.13.1に規定されて
いるアライメントの要件に従って割り付ける。
d) メタデータ区画マップのフラグ（Flags）欄の複製メタデータフラグがセットされている場合，（メタ
データ控えファイルに）第2のエクステントのブロックをサイズ及び2.2.13.1に規定されているアラ
イメントの要件に従って割り付ける。最初の割付けからできるだけ離れていることが望ましい。
e) メタデータファイルに新規の割付け記述子を追加するか，又は既存の記述子を変更することによって，
新規に割り付けられたエクステントの最初を参照できるようにする。メタデータ区画マップのフラグ
（Flags）欄の複製メタデータフラグ（Duplicate Metadata Flag）がセットされていない場合，メタデー
タ控えファイルのADを変更し，同じエクステントを参照する。
f)
上記において第2のエクステントが割り付けられた場合，メタデータ控えファイルに新規の割付け記
述子を追加するか，既存のADを変更し，第2のエクステントを参照する。
g) 新規のエクステントがメタデータファイルの最後に追加された場合，メタデータファイル及び複製の
FEの情報長欄を新規のブロックを含むように増やす。
h) メタデータビットマップファイルが拡張された場合，そのFEの情報長欄をメタデータファイルの新
規のブロックを記述するビットを含むように増やす。
i)
新たなメタデータのために使用可能なことを示すために，メタデータビットマップファイルのメタデ
ータファイルに今回追加されたエクステントに該当するビットをセット（ONEに）する。
2.2.13.6 メタデータ区画からの空間の推奨される回収の手順
メタデータファイル及びその複製に割り付けられたブロックは，次の二つのいずれかによって返却され
なければならない。
a) メタデータファイル及びその複製を切り詰める。
b) メタデータファイル及びその複製の領域のADを作成し，散在（未割付け）するのに合わせてメタデ
ータビットマップファイルの該当するビットをZEROにし，これらのブロックが使用できないことを
示す。
除去されるいかなる領域も次のとおりでなければならない。
a) 現在参照されているメタデータを含んでいてはならない［例えば，メタデータビットマップファイル
の該当する全てのビットが既にセット（ONEに）されていなければならない。］。
b) 2.2.13.1に示すサイズ及び整列の制約に適合しなければならない。
切り詰める場合（メタデータ区画が切り詰められようとしている。）は，次による。
a) ビットマップのサイズを減らすために，メタデータビットマップファイルのSBDを更新する。
b) メタデータビットマップファイルのファイルエントリの情報長欄（Information Length）を減少したビ
ットマップのサイズを反映するように更新する。
c) メタデータファイル及びその複製のファイルエントリの情報長欄（Information Length）を領域を除去
するように更新する。
d) 割付け解除されたブロックを区画の未割付け空間ビットマップで利用可能にマークする。
散在にマークされた場合（メタデータ区画の中間の領域が除去されようとしている。）は，次による。
a) メタデータビットマップファイルの該当するビットをZEROにクリアする。
b) 割付け解除されようとしている領域のために，散在（未割付け）割付け記述子をメタデータファイル
38
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
（及びその複製）に生成する。
c) 割付け解除されたブロックを区画の未割付け空間ビットマップで利用可能にマークする。
2.2.14 区画記述子（Partition Descriptor）
struct PartitionDescriptor { /* JIS X 0607 3/10.5 */
struct tag
DescriptorTag;
Uint32
VolumeDescriptorSequenceNumber;
Uint16
PartitionFlags;
Uint16
PartitionNumber;
struct EntityID
PartitionContents;
byte
PartitionContentsUse[128];
Uint32
AccessType;
Uint32
PartitionStartingLocation;
Uint32
PartitionLength;
struct EntityID
ImplementationIdentifier;
byte
ImplementationUse[128];
byte
Reserved[156];
}
2.2.14.1 区画内容（Struct EntityID PartitionContents）
この欄の適切な扱いに関する詳細情報は，実体識別子に関する2.1.5を参照。
2.2.14.2 アクセス種別（Uint32 AccessType）
JIS X 0607 [3/10.5.7]で定義されているアクセス種別の値のほかに，UDFでは値0を疑似上書き可能とい
う名称のアクセス種別として用いなければならないと定義する。このアクセス種別の値は，6.15で記述す
るとおりの疑似上書き方式が利用可能な区画に使用されなければならない。
アクセス種別3（書換形）の区画は空き空間ビットマップ又は空き空間表を定義しなければならない
（2.3.3参照）。それ以外の区画は空き空間ビットマップ又は空き空間表を定義してはならない。
幾つかの書換形又は上書き可能形媒体では，区画アクセス種別の3（書換形）と4（上書き可能形）との
間で混乱があるかもしれない。
書換形区画は，書込み前に何らかの形の前処理が必要な媒体（例えば，従来のMO，DVD-RW）上で使
われる。このような区画は，アクセス種別3を使わなければならない。
上書き可能形区画は，書込み前に何らかの形の前処理が不要な媒体（例えば，CD-RW，DVD+RW，
DVD-RAM，BD-RE，HD DVD-Rewritable）上で使われる。このような区画は，アクセス種別4を使わなけ
ればならない。アクセス種別の値が定義済みのアクセス種別の値のいずれとも等しくない場合，又は媒体
とドライブとの組合せがアクセス種別の値で指示された書込み動作を行うことができない場合は，その区
画は再生専用区画として取り扱わなければならない（例：追記形媒体上又は再生専用ドライブ内の上書き
可能形区画）。
特記事項 上記の規則は，UDF版数が大きく（例：UDF 2.60），疑似上書き可能区画を使用し，読出
し最小版数の値が2.50である媒体に，UDF 2.50処理システムが再生専用形アクセスを可
能にするために，重要である。
39
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.2.14.3 区画開始位置（Uint32 PartitionStartingLocation）
予備区画においてはこの欄の値は，パケット長の整数倍でなければならない。パケット長は，予備区画
マップで定義される。
物理区画の場合，この欄の値は，その媒体の（“ECCブロック長”をセクタ長で除したもの）の整数倍
でなければならない（ECCブロック長の定義は1.3.2参照）。
2.2.14.4 区画長（Uint32 PartitionLength）
予備区画においてはこの欄の値は，パケット長の整数倍でなければならない。パケット長は，予備区画
マップで定義される。
2.2.14.5 処理システム識別子（Struct EntityID ImplementationIdentifier）
この欄の適切な扱いに関する詳細情報は，実体識別子に関する2.1.5を参照。
2.2.14.6 区画内容用（byte PartitionContentsUse[128]）
区画内容用欄は2.3.3で定義されるとおりの区画ヘッダ記述子を含む。
2.3
第4部 ファイル構造
2.3.1
記述子タグ（Descriptor Tag）
struct tag{
/* JIS X 0607 4/7.2 */
Uint16
TagIdentifier;
Uint16
DescriptorVersion;
Uint8
TagChecksum;
byte
Reserved;
Uint16
TagSerialNumber;
Uint16
DescriptorCRC;
Uint16
DescriptorCRCLength;
Uint32
TagLocation;
}
特記事項 JIS X 0607では値が0のタグ識別子は定義されていないが，UDFでは予備表として使用す
る。
2.3.1.1
タグ通し番号（Uint16 TagSerialNumber）
a) 意味：無視する。障害回復のためにある。
b) 設定値：このボリュームの開始ボリューム記述子ポインタのタグ通し番号（TagSerialNumber）と同じ
値を設定しなければならない。
ボリューム構造のタグ通し番号と同じ制約が適用される（2.2.1.1及び2.1.6参照）。
2.3.1.2
記述子CRC長（Uint16 DescriptorCRCLength）
ボリューム構造の記述子CRC長と同じことが適用される。2.2.1.2参照。
2.3.1.3
タグ位置（Uint32 TagLocation）
仮想番地（例えば，VATを通した参照）を通して参照される構造のために，この値は物理番地又は論理
番地ではなく，仮想番地でなければならない。
2.3.2
ファイル集合記述子（File Set Descriptor）
struct FileSetDescriptor{
/* JIS X 0607 4/14.1 */
struct tag
DescriptorTag;
struct timestamp
RecordingDateandTime;
40
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
Uint16
InterchangeLevel;
Uint16
MaximumInterchangeLevel;
Uint32
CharacterSetList;
Uint32
MaximumCharacterSetList;
Uint32
FileSetNumber;
Uint32
FileSetDescriptorNumber;
struct charspec
LogicalVolumeIdentifierCharacterSet;
dstring
LogicalVolumeIdentifier[128];
struct charspec
FileSetCharacterSet;
dstring
FileSetIdentifier[32];
dstring
CopyrightFileIdentifier[32];
dstring
AbstractFileIdentifier[32];
struct long̲ad
RootDirectoryICB;
struct EntityID
DomainIdentifier;
struct long̲ad
NextExtent;
struct long̲ad
SystemStreamDirectoryICB
byte
Reserved[32];
}
書換形及び上書き可能形媒体中には，一つだけのファイル集合記述子を記録しなければならない。追記
形媒体中には，複数のファイル集合記述子を記録してもよい。
複数のファイル集合に関するUDF規定を，次に示す。
a) 複数のファイル集合は，追記形媒体中だけに許可する。
b) デフォルトのファイル集合は，最大のファイル集合番号をもつものと定義する。
c) デフォルトのファイル集合だけを，書込み可能としてもよい。その列における他の全てのファイル集
合は，ハード書込み保護（2.1.5.3参照）を設定しなければならない。
d) 書込み不可のファイル集合は，その他のファイル集合で参照（直接又は間接的に）するメタデータ構
造を参照しなければならない。書込み可能のファイル集合は，実ファイルデータエクステントを参照
してもよい。
追記形媒体のファイル集合中では，全てのファイル及びディレクトリをICB方策種別4で記録する場合，
そのファイル集合記述子の範囲識別子には，ハード書込み保護を設定しなければならない。
追記形媒体中の複数のファイル集合の意図する目的は，媒体中に複数のアーカイブをもつ機能を利用可
能にすることである。例えば，一つのファイル集合は，特定の時点で作成した情報集合のバックアップを
表現する。
後続のファイル集合は，その後作成した同一情報集合の他のバックアップとして表現する。
2.3.2.1
交換水準（Uint16 InterchangeLevel）
a) 意味：関連するファイル集合の内容の現状の交換水準（[4/15]で規定）及び規定水準が意味する制約の
指定と解釈する。
b) 設定値：水準3を設定しなければならない。
処理システムは，指定された現状の交換水準に関連する制約を実施しなければならない。
41
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.3.2.2
最大交換水準（Uint16 MaximumInterchangeLevel）
a) 意味：関連するファイル集合の内容についての最大交換水準の指定と解釈する。この値は，現状の交
換水準欄で設定してもよい値を制限する。
b) 設定値：水準3を設定しなければならない。
2.3.2.3
文字集合リスト（Uint32 CharacterSetList）
a) 意味：JIS X 0607規格類の第4部において定義され，この欄を含む記述子によって記述するファイル
集合に記録される全ての記述子において，内容をcharspecと規定する全ての欄で指定される文字集合
の指定と解釈する。
b) 設定値：2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。
2.3.2.4
文字最大集合リスト（Uint32 MaximumCharacterSetList）
a) 意味：関連するファイル集合で利用可能な文字集合の最大値及び規定水準が意味する制限の指定と解
釈する。
b) 設定値：2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。
2.3.2.5
論理ボリューム識別子用文字集合（struct charspec LogicalVolumeIdentifierCharacterSet）
a) 意味：論理ボリューム識別子欄で使用可能なd文字の指定と解釈する。
b) 設定値：2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。
2.3.2.6
ファイル集合用文字集合（struct charspec FileSetCharacterSet）
a) 意味：JIS X 0607規格類の第4部で定義された，ファイル集合記述子の有効範囲内の内容がdstringで
ある欄で使用可能なd文字の指定と解釈する。
b) 設定値：2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。
2.3.2.7
範囲識別子（struct EntityID DomainIdentifier）
a) 意味：記述子中の欄の使用規則及び制約を規定する範囲の指定と解釈する。この欄がNULLの場合，
無視する。それ以外の場合は，実体識別子の規則に従う。
b) 設定値：この欄は，この規格で定義する範囲に適合するファイル集合記述子の有効範囲を示すもので
なければならない。したがって，範囲識別子の値は，
“*OSTA UDF Compliant”
に設定しなければならない。
2.1.5で記載したとおり，実体識別子の識別子添字（IdentifierSuffix）欄には，論理ボリュームの内容が互
換性をもつこの規格の対応団体規格の規定の版数を含む。この欄の適切な扱いに関する詳細情報は，2.1.5.3
を参照。
特記事項 実体識別子の識別子添字欄は，ソフト書込み保護フラグ及びハード書込み保護フラグを含
む。
2.3.3
区画ヘッダ記述子（Partition Header Descriptor）
struct PartitionHeaderDescriptor{ /* JIS X 0607 4/14.3 */
struct short̲ad
UnallocatedSpaceTable;
struct short̲ad
UnallocatedSpaceBitmap;
struct short̲ad
PartitionIntegrityTable;
struct short̲ad
FreedSpaceTable;
struct short̲ad
FreedSpaceBitmap;
byte
Reserved[88];
42
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
}
区画ヘッダ記述子は，区画記述子の区画内容用欄に記録される。
すなわち，未割付け空間とした論理ブロックは，前処理なしに書込み可能なブロックである。書換形媒
体の場合，消去処理なしに書き込める。空き空間とした論理ブロックは，書込み準備が必要なブロックで
あり，何らかの前処理をする必要がある。書換形媒体の場合，消去処理後に書き込む。媒体の種別の分類
についての詳細は，2.2.14.2参照。
特記事項1 空間表又は空間ビットマップの使用は，論理ボリューム中で一貫していなければならな
い。空間表及び空間ビットマップの両方を一つの論理ボリューム中で同時に使用しては
ならない。
特記事項2 空間表又は空間ビットマップは，再生専用区画，疑似上書き可能区画，VATを使用して
いるファイルシステムには記録してはならない。
2.3.3.1
区画保全表（struct short̲ad PartitionIntegrityTable）
区画保全エントリは使用しないため，全て0を指定しなければならない。
2.3.4
ファイル識別記述子（File Identifier Descriptor）
struct FileIdentifierDescriptor{ /* JIS X 0607 4/14.4 */
struct tag
DescriptorTag;
Uint16
FileVersionNumber;
Uint8
FileCharacteristics;
Uint8
LengthofFileIdentifier;
struct long̲ad
ICB;
Uint16
LengthofImplementationUse;
byte
ImplementationUse[];
char
FileIdentifier[];
byte
Padding[];
}
ファイル識別記述子は，一つの論理ブロック長に制限しなければならない。
特記事項1 UDFの全てのディレクトリは，親ディレクトリの位置を示すファイル識別記述子を一つ
もたなければならない。親ディレクトリを記述するファイル識別記述子は，ディレクト
リの最初のファイル識別記述子にしなければならない。ルートディレクトリの親ディレ
クトリは，[4/8.6]に示されているのと同様に，ルートディレクトリにしなければならな
い。
特記事項2 メタデータ区画マップの記録された論理ボリュームでは，全てのディレクトリ及びスト
リームディレクトリがメタデータ区画（2.2.10参照）に記録されなければならない。し
かし，名前付きストリームのデータ空間は，物理空間に記録されなければならない。
2.3.4.1
ファイル版数（Uint16 FileVersionNumber）
a) 意味：ファイルの版数はただ一つだけとし，次項ではこの値を1にしている。
b) 設定値：値1を設定しなければならない。
2.3.4.2
ファイル特性（Uint8 FileCharacteristics）
2.3.4.2.1
削除ビット（Deleted bit）
削除ビットは，ディレクトリからFIDを除去せずに，ファイル又はディレクトリが削除されていること
43
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
を表示するために使用してもよい。この場合，その地点から最後まで，ディレクトリを書き換えることが
必要になる。ファイル又はディレクトリの空間の割付けが解除されているとき，処理システムでは，ICB
欄を0に設定しなければならない。これは，削除ビットが設定されても，FIDの欄が全て有効でなければ
ならないことによる（JIS X 0607 [4/14.4.3]の注記21，及び[4/14.4.5]を参照。）。
[4/8.6]は，あるディレクトリの全てのFIDのファイル識別子（及び常に1でなければならないファイル
版数）が一意であることを要求する。JIS X 0607規格類の第4部は削除ビットを設定されたFIDにもこの
要求が及ぶか否か記載がないが，意図は否である。削除ビットを設定されたFIDは，一意であることの要
求を受けないと解釈される。
この解釈をしないで，JIS X 0607規格類の第4部を誤解して作られた可能性があるUDF処理システムを
補助するために，処理システムはFIDの削除ビットが設定されるとき，これらの規則に従わなければなら
ない。
もし，ファイル識別子の圧縮識別子が8ならば，圧縮識別子は254に書き換える。もし，ファイル識別
子の圧縮識別子が16ならば，圧縮識別子は255に書き換える。ファイル識別子の残りのバイトは変えない
ままにする。
このように，ファイル又はディレクトリを削除しないことを望むユーティリティは，圧縮IDの書換え
を逆にすることによって元の名前を回復できる。
特記事項 処理システムでは，ディレクトリが大きくなるのを避けるため，削除ビットが1に設定さ
れ，ICB欄が0に設定されたFIDを再使用することが望ましい。
2.3.4.2.2
親ビット及びディレクトリビット（Parent bit and Directory bit）
JIS X 0607 [4/14.4.3]の図13の下の次の言明には不備がある。
“親ビットがONEにセットされている場合，ディレクトリビットはONEにセットされなければならな
い。”
この言明にもかかわらず，親FID内の親ビットは，FIDがディレクトリ又はシステムストリームディレ
クトリを識別する場合だけONEにセットされなければならない。親FIDがファイルを識別する場合は，
ディレクトリビットはZEROにセットされなければならない。後者は，ファイルに結びつけられたストリ
ームディレクトリ内の親FIDの場合である。
2.3.4.3
ICB（struct long̲ad ICB）
あらゆるファイル識別記述子のlong̲adの処理システム用バイトは，ファイル及びディレクトリ名前空
間のUDF一意IDを記録するために使用しなければならない（表16参照）。
long̲adの処理システム用バイトは，2.3.10.1で規定されている割付け記述子の処理システム用の構造を
保持する。この構造の四つの処理用バイトは，UDF一意IDを保持するUint32として解釈される。
表16−UDF一意ID（ADImpUse structure holding UDF Unique ID）
RBP
長さ
名前
内容
0
2
フラグ（2.3.10.1参照）[Flags (see 2.3.10.1)]
Uint16
2
4
UDF一意ID（UDF Unique ID）
Uint32
3.2.1の論理ボリュームヘッダ記述子は，ファイル識別記述子のlong̲adの処理システム用バイトにおけ
るUDF一意ID（UDF Unique ID）欄，並びにファイルエントリ及び拡張ファイルエントリの一意ID（Unique
ID）欄の設定方法を記述している。
2.3.4.4
処理システム用の長さ（Uint16 LengthofImplementationUse）
44
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
a) 意味：処理システム用（ImplementationUse）欄の長さを指定しなければならない。
b) 設定値：この欄には，処理システム用欄の長さを指定しなければならないが，処理システム用欄が未
使用であることを示す0を設定してもよい。
ファイル識別記述子を追記形媒体に書き込むとき，次のFIDの記述子タグ欄がブロック境界に及ばない
ことを保証するため，FIDの後の現在のブロックに16未満のバイトが残っていれば，FIDの長さは，これ
を避けるのに十分なだけ増加する（この場合，処理システム用欄を使用する。）。後者の場合，処理システ
ム用欄は少なくとも32バイトでなければならない。
2.3.4.5
処理システム用（byte ImplementationUse[]）
a) 意味：処理システム用の長さ（LengthofImplementationUse）欄が0でない場合，この欄の最初の32バ
イトは，ファイル識別記述子を最後に更新した処理システムの処理システム実体識別子の指定と解釈
する。
b) 設定値：処理システム用の長さ欄が0でない場合，この欄の最初の32バイトに，現状の処理システム
の処理システム実体識別子を指定しなければならない。
特記事項 この欄の適切な扱いに関する詳細情報は，実体識別子に関する2.1.5を参照。
この欄は，特定のファイル識別記述子を最後に作成又は更新した処理システムを識別することを可能と
する。
2.3.4.6
ファイル識別子（char FileIdentifier[]）
OSTA圧縮Unicode形式のファイル識別子が書かれている（2.1.1参照）。この欄のバイト長は，親FID
のとき0になる唯一の例外を除いて，1より大きくなければならない。このファイル識別子記述子のファ
イル特性欄の削除ビットが設定されている場合は，2.3.4.2の追加規定を参照。削除ビットが設定されてい
ない場合は，ファイル識別子のUnicode表現はこのディレクトリ内で一意でなければならない。この一意
性はJIS X 0607 [4/8.6]のバイトごとの一意性だけでなく，OSTA圧縮Unicode形式を伸張して得られる
Unicode記述子についても要求されている。
2.3.5
ICBタグ（ICB Tag）
struct icbtag{
/* JIS X 0607 4/14.6 */
Uint32
PriorRecordedNumberofDirectEntries;
Uint16
StrategyType;
byte
StrategyParameter[2];
Uint16
MaximumNumberofEntries;
byte
Reserved;
Uint8
FileType;
Lb̲addr
ParentICBLocation;
Uint16
Flags;
}
2.3.5.1
方策種別（Uint16 StrategyType）
a) 意味：この欄の内容には，使用するICB方策種別を指定する。読出しアクセスの目的の処理システム
は，ICB方策種別4及び4 096を利用可能としなければならない。
b) 設定値：値4又は4 096を設定しなければならない。特記事項参照。
特記事項 6.6で定義されているICB方策種別4 096は，追記形媒体で使用することを意図している。
ICB方策種別4 096は，非逐次記録の追記形媒体に記録されたアクセス種別が追記形であ
45
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
る区画内のICBだけに許されている。
2.3.5.2
ファイル種別（Uint8 FileType）
標準のバイトで番地付け可能なファイルのために値5を使用しなければならず，0を使用してはならな
い。VAT（2.2.11参照）のために値248を使用しなければならない。Real-Timeファイル（6.11参照）を示
すために値249を使用しなければならない。ファイル種別250，251及び252は，各々メタデータファイル，
メタデータ控えファイル，メタデータビットマップファイルに使用しなければならない。詳細は，2.2.13
を参照。ファイル種別253〜255は使用してはならない。
2.3.5.2.1
ファイル種別249（File Type 249）
ファイル種別249のファイルは，このファイルのデータ領域にアクセスするための特別なコマンドを要
求する。起こり得るダメージを避けるために，これらのコマンドが利用可能でない処理システムの場合，
このファイルのデータ領域にアクセスするか又は変更するコマンドを全く出さない。これは，読出し，書
込み及び削除を含むが限定されるものではない。
2.3.5.3
親ICB位置（ParentICBLocation）
ICB方策種別4の場合，この欄は使用してはならず，全て0バイトを書く。ICB方策種別4 096の場合，
この欄の使用は，任意選択とする。
特記事項 [4/14.6.7]では，この欄が0の場合，そのようなICBを指定していないことを意味すると規
定している。これは，処理システムがICBを論理ブロック番地0に記録できることから，
規定の誤りである。したがって，この欄を使用する場合，ICBを論理ブロック0に記録し
てはならない。
2.3.5.4
フラグ（Uint16 Flags）
a) ビット0〜2
これらのビットは，使用する割付け記述子の種別を指定する。使用する割付け記述子種別の選択のガ
イドラインについては，2.3.10を参照。
b) ビット3［分類（Sorted）］
1) 意味：OSTA UDF適合媒体に関して，このビットは，ディレクトリが未分類でもよい（0）ことを示
さなければならない。
2) 設定値：0を設定しなければならない。
c) ビット4［再配置不可（Non-relocatable）］
1) 意味：OSTA UDF適合媒体に関して，このビットは，もし，ファイルが再配置不可であるならば，
（1）を示さなければならない。もし，[4/14.6.8]でのこのビットの定義に反するならば，処理システ
ムはこのビットを0に設定しなければならない。
2) 設定値：0を設定することが望ましい。
特記事項1 このフラグはファイルをロックするものではない。それは，処理システムが特定の
応用プログラムの要求を満たすためにファイルの割付けをアレンジしたことを示す
のに使用される。これらの場合では，記録済みのブロック（UDF予備区画に関する
2.2.9を参照）の再割当て，又はファイルの断片解消処理（defragmentation）は望ま
れないかもしれない。1に設定されたフラグをもつファイルが複写される場合，フ
ァイルの新しいコピーは，このビットを0に設定することが望ましい。
d) ビット9［連続性（Contiguous）］
1) 意味：OSTA UDF適合媒体に関して，このビットは，ファイルが連続である（1）ことを示してもよ
46
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
い。ファイルが連続であることを処理システムが保証できない場合に，ファイルが不連続でもよい
ことを示すために，処理システムはこのビットを0に設定してもよい。
2) 設定値：0を設定することが望ましい。
e) ビット11［変換（Transformed）］
1) 意味：OSTA UDF適合媒体に関して，このビットは，変換がない（0）ことを示さなければならない。
2) 設定値：0を設定しなければならない。
データ圧縮法及びその他のデータ変換形式は，将来のOSTAの規定で示す。
f)
ビット12［複数版数（Multi-versions）］
1) 意味：OSTA UDF適合媒体に関して，このビットは，複数版数ファイルが存在しない（0）ことを示
さなければならない。
2) 設定値：0を設定しなければならない。
g) ビット13［ストリーム（Stream）］
1) 意味：ファイルエントリ又は名前付きストリームを定義する拡張ファイルエントリ又はファイル若
しくはディレクトリの主データストリームのいずれかである（1）ことを示さなければならない。
[4/8.8.3]及びこの規格の3.3.5参照。
2) 設定値：FE又は名前付きストリームのEFEのために1を設定しなければならない。それ以外の場
合は0を設定しなければならない。
特記事項2 ファイル又はディレクトリの主データストリームのFE又はEFE，及びシステムス
トリームディレクトリのFE又はEFEについて，ストリームビットは0に設定され
なければならない。これらのFE又はEFEはストリームディレクトリの親FIDによ
って参照されるであろうという事実にもかかわらず，[4/14.6.8]の注記24によって親
FIDの場合は除かれる。
2.3.6
拡張ファイルエントリ及びファイルエントリ（Extended File Entry and File Entry）
struct FileEntry{
/* JIS X 0607 4/14.17及び4/14.9 */
struct tag
DescriptorTag;
struct icbtag
ICBTag;
Uint32
Uid;
Uint32
Gid;
Uint32
Permissions;
Uint16
FileLinkCount;
Uint8
RecordFormat;
Uint8
RecordDisplayAttributes;
Uint32
RecordLength;
Uint64
InformationLength;
Uint64
ObjectSize;
/* EFEだけ*/
Uint64
LogicalBlocksRecorded;
struct timestamp
AccessDateAndTime;
struct timestamp
ModificationDateAndTime;
struct timestamp
CreationDateAndTime;
/* EFEだけ*/
struct timestamp
AttributeDateAndTime;
47
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
Uint32
Checkpoint;
Byte
Reserved[4];
/* EFEだけ*/
struct long̲ad
ExtendedAttributeICB;
struct long̲ad
StreamDirectoryICB;
/* EFEだけ*/
struct EntityID
ImplementationIdentifier;
Uint64
UniqueID;
Uint32
LengthofExtendedAttributors;
Uint32
LengthofAllocationDescriptes;
byte
ExtendedAttributes[];
byte
AllocationDescriptors[];
}
一つの拡張ファイルエントリ（Extended File Entry）又はファイルエントリ（File Entry）の全長は，一つ
の論理ブロック長を超えてはならない。全ての場合でFEの代わりにEFEを使用することが推奨される。
EFEはFEの上位集合である。これは，EFEがFEの全ての欄と，上記の構造で“EFEだけ”と表示さ
れている差し込まれている特別の欄とをもつことを意味する。EFEとFEとでは同じ欄のオフセットが異
なることがあることに注意する。一般的に，この規格の全文にわたって“拡張ファイルエントリ”は“フ
ァイルエントリ”で置き換えることが可能である。
ボリュームにメタデータ区画マップが記録されている場合，全ての（拡張）ファイルエントリ，割付け
記述子エクステント及びディレクトリのデータは，メタデータ区画に記録されなければならない。例えば，
メタデータ及び／又はメタデータ控えファイルに割り付けられた論理ブロック。例外を含む詳細について
は2.2.13参照。
2.3.6.1
レコードフォーマット（Uint8 RecordFormat）
a) 意味：OSTA UDF適合媒体に関して，ファイルに記録する情報の構造は，この欄で規定しない（0）こ
とを示さなければならない。
b) 設定値：0を設定しなければならない。
2.3.6.2
レコード表示属性（Uint8 RecordDisplayAttributes）
a) 意味：OSTA UDF適合媒体に関して，ファイルに記録する情報の構造は，この欄で規定しない（0）こ
とを示さなければならない。
b) 設定値：0を設定しなければならない。
2.3.6.3
レコード長（Uint32 RecordLength）
a) 意味：OSTA UDF適合媒体に関して，ファイルに記録する情報の構造は，この欄で規定しない（0）こ
とを示さなければならない。
b) 設定値：0を設定しなければならない。
2.3.6.4
情報長（Uint64 InformationLength）
最後の割付け記述子だけがブロック長の倍数でないエクステント長をもつ場合は，[4/12.1]及び
[4/14.14.1.1]を参照。
2.3.6.5
記録済み論理ブロック（Uint64 LogicalBlocksRecorded）
データを埋め込んだファイル又はディレクトリについて，この欄の値は0を設定しなければならない。
2.3.6.6
処理システム識別子（struct EntityID ImplementationIdentifier）
実体識別子に関する2.1.5を参照。
48
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.3.6.7
一意ID（Uint64 UniqueID）
ファイル集合のルートディレクトリに関して，この値は0を設定しなければならない。
3.2.1の論理ボリュームヘッダ記述子は，ファイル識別記述子におけるlong̲adの処理システム用バイト
のUDF一意ID欄，並びにファイルエントリ及び拡張ファイルエントリの一意ID欄の設定方法を記述し
ている。
2.3.6.8
ファイルリンク数（FileLinkCount）
ディレクトリに対するハードリンク（hard link）は許されない。ディレクトリのファイルエントリは，
次によって識別されなければならない。
a) ルートディレクトリでないディレクトリについては，ディレクトリ名を定義する厳密に一つのFID。
b) 適切な場合は0以上の親FID。もしあれば，各々の直下の子ディレクトリ内に一つの親FID。
名前付きストリーム及びストリームディレクトリのハードリンクの制約については，3.3.5.1参照。
2.3.6.9
アクセス，更新，作成及び属性日時表示 （Access, Modification, Creation and Attribute Timestamps）
[4/14.9.12]〜[4/14.9.14]はアクセス，更新及び属性日時は“ファイルの作成日時より前であってはならな
い”と言明している。幾つかのオペレーティングシステムは“作成時間”について異なった概念をもって
いるため，UDFでは[4/14.9.12]〜[4/14.9.14]の“前であってはならない”を“前でないほうが望ましい”に
読み替えることによって，この規定を必須から推奨へと変更する。
特記事項 [4/14.9.12]〜[4/14.9.14]はファイル日時拡張属性のファイル作成日時についてしか触れてい
ない。しかし，ファイル日時拡張属性のファイル作成日時は拡張ファイルエントリには記
録してはならない。EFEはその作成日時の欄をもっており，それが使用されなければなら
ない。3.3.4.3.1及び[4/14.17.13]〜[4/14.17.16]を参照。
2.3.7
未割付け空間エントリ（Unallocated Space Entry）
struct UnallocatedSpaceEntry{ /* JIS X 0607 4/14.11 */
struct tag
DescriptorTag;
struct icbtag
ICBTag;
Uint32
LengthofAllocationDescriptors;
byte
AllocationDescriptors[];
}
特記事項 未割付け空間エントリの最大長は，一つの論理ブロック長でなければならない。
2.3.7.1
割付け記述子（byte AllocationDescriptors[]）
短割付け記述子だけを使用する。
特記事項 割付け記述子中のエクステント長欄の上位2ビットは，エクステント種別[4/14.14.1.1]を指
定する。未割付け空間エントリで規定する割付け記述子に関して，この種別は，割付け済
みであるが未記録であるエクステントを示す値1に設定するか，又はエクステントが割付
け記述子の後続エクステントであることを示す値3に指定するかしなければならない。割
付け記述子の後続エクステントは，一つの論理ブロック長に制限しなければならない。
割付け記述子は，位置の昇順に連続的に並べなければならない。表中の割付け記述子は重複してはなら
ない。例えば，位置 = 2，長さ = 2 048（論理ブロック長 = 1 024）の割付け記述子の次が，位置 = 3の割
付け記述子であることは許されない。隣接する割付け記述子が続いてはならない。例えば，位置 = 2，長
さ = 1 024（論理ブロック長 = 1 024）の割付け記述子の次が，位置 = 3の割付け記述子であってはならず，
位置 = 2，長さ = 2 048の一つの割付け記述子でなければならない。隣接する割付け記述子が続いてもよ
49
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
い唯一の場合は，いずれか一方の隣接する割付け記述子の長さが，割付け記述子で記述可能な最大値のと
きである。
2.3.8
空間ビットマップ記述子（Space Bitmap Descriptor）
struct SpaceBitmap{
/* JIS X 0607 4/14.12 */
struct Tag
DescriptorTag;
Uint32
NumberOfBits;
Uint32
NumberOfBytes;
byte
Bitmap[];
}
2.3.8.1
記述子タグ（struct Tag DescriptorTag）
空間ビットマップ記述子の記述子CRC長については，例外規定がある。2.3.1.2で定義されるとおりの記
述子CRC長のデフォルトの値が使われない場合，記述子CRC長は0又は8のどちらかでなければならな
い。値8が推奨される。
2.3.9
区画保全エントリ（Partition Integrity Entry）
（JIS X 0607 [4/14.13]参照）論理ボリューム保全記述子（2.2.6参照）の機能によってこの記述子は必要
でないため，この記述子は記録してはならない。
2.3.10 割付け記述子（Allocation Descriptor）
ファイルのデータ領域を構成するとき，処理システムは，選択対象の幾つかの種別の割付け記述子をも
つ。次に示すガイドラインは，使用する適切な割付け記述子の選択時に従わなければならない。
a) 短割付け記述子：単一ボリューム中に存在する論理ボリューム（例えば，独立した装置で作成した論
理ボリューム）で，他のボリュームを拡張する予定のない論理ボリュームに関して，短割付け記述子
を使用することが望ましい。
特記事項1 最大交換水準については，2.2.2.2を参照。
b) 長割付け記述子：複数ボリュームに存在する論理ボリューム，又は現在は単一ボリューム内に存在す
るが，後で複数ボリュームにまたがる予定の論理ボリュームに関して，長割付け記述子を使用するこ
とが望ましい。
特記事項2 単一ボリューム中でも長割付け記述子を使用する利点はある。この利点は，書換形媒体
中の消去したエクステントの追跡を利用可能とすることである。付加情報については，
2.3.10.1を参照。
短割付け記述子及び長割付け記述子の両方に関して，エクステント長（ExtentLength）欄の下位30ビッ
トが0の場合，上位2ビットは0でなければならない。
特記事項3 仮想区画マップの記録されたボリュームの場合
a) 仮想空間を識別する割付け記述子は，ブロック長以下の長さのエクステント長をも
たなければならない。ファイルデータ，ディレクトリ，又はストリームデータを識
別する割付け記述子は物理空間を識別しなければならない。仮想空間に記録された
ICBは，物理空間を識別するために，long̲ad割付け記述子を使用しなければならな
い。short̲ad割付け記述子を使用することによって，もし，ICBが仮想空間にある
ならば，仮想空間のファイルデータを識別することになる。
b) 仮想空間に記録された記述子は，タグ位置欄に記録された仮想論理ブロック番号を
もたなければならない。
50
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
特記事項4 メタデータ区画マップの記録されたボリュームの場合
a) ディレクトリ又はストリームディレクトリのデータを識別する割付け記述子は，メ
タデータ空間を識別しなければならない。
b) ファイル又はストリームのデータを識別する割付け記述子は，物理空間を識別しな
ければならない。
c) メタデータ空間に記録された割付け記述子は，同様にメタデータ空間にあるエクス
テントを識別するときはshort̲adを使わなければならない。
d) エクステント種別3（継続）である割付け記述子は，種別3の記述子そのものが記
録されている同じ区画を識別しなければならない。
e) メタデータ空間に記録された記述子は，適切な場合，記述子そのもののメタデータ
空間論理ブロック番号をその記述子タグのタグ位置欄（TagLocation）に記録しなけ
ればならない。
2.3.10.1 長割付け記述子（Long Allocation Descriptor）
struct long̲ad{
/* JIS X 0607 4/14.14.2 */
Uint32
ExtentLength;
Lb̲addr
ExtentLocation;
byte
ImplementationUse[6];
}
UDF及び処理システムの両方に処理システム用（ImplementationUse）欄の使用を許可するために，6バ
イトの処理システム用欄の中に次の構造を記録しなければならない。
struct ADImpUse
{
Uint16 flags;
byte impUse[4];
}
/*
*ADImpUse Flags (NOTE:bits 1-15 reserved for future use by UDF)
*/
#define EXTENTErased (0x01)
前処理の利点である書換形媒体の効率のために，このエクステント消去（EXTENTErasd）フラグは，消
去したエクステントを示す1を設定しなければならない。これは，割付け済みであるが未記録であるエク
ステントだけに使用する。
2.3.11 割付けエクステント記述子（Allocation Extent Descriptor）
struct AllocationExtentDescriptor{ /* JIS X 0607 4/14.5 */
struct tag
DescriptorTag;
Uint32
PreviousAllocationExtentLocation;
Uint32
LengthOfAllocationDescriptors;
}
割付けエクステント記述子は，割付け記述子それ自体を含まない。UDFは，[4/14.5]を割付け記述子が割
付けエクステント記述子の割付け記述子長（LengthOfAllocationDescriptors）欄に続く最初のバイトから始
まる方法として解釈する。割付けエクステント記述子はその割付け記述子とともに割付け記述子のエクス
51
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
テントを構成する。割付け記述子のエクステント長は，論理ブロック長を超えてはならない。割付け記述
子の次から論理ブロックの最後まで続く不使用のバイトは，値#00をもつ。
2.3.11.1 記述子タグ（Struct tag DescriptorTag）
記述子タグの記述子CRC長は，割付け記述子エクステントに続く割付け記述子を含む。記述子CRC長
は，8又は8＋割付け記述子長でなければならない。
2.3.11.2 先行割付けエクステント位置（Units32 PreviousAllocationExtentLocation）
a) 意味：この欄は使用してはならない。
b) 設定値：0を設定しなければならない。
2.3.12 パス名（Pathname）
2.3.12.1 パス要素（Path Component）
struct PathComponent{
/* JIS X 0607 4/14.16.1 */
Uint8
ComponentType;
Uint8
LengthofComponentIdentifier;
Uint16
ComponentFileVersionNumber;
char
ComponentIdentifier[];
}
2.3.12.1.1 要素ファイル版数（Uint16 ComponentFileVersionNumber）
a) 意味：ファイルの版数はただ一つだけとし，次項ではこの値を0にしている。
b) 設定値：値0を設定しなければならない。
2.4
第5部 レコード構造
レコード構造ファイルは，作成してはならない。これらが媒体中に存在し，処理システムが利用可能で
ない場合は，内容を解釈しないバイト列として扱わなければならない。
3
システム依存要件
3.1
第1部 一般
3.1.1
日時表示（Timestamp）
struct timestamp{
/* JIS X 0607 1/7.3 */
Uint16
TypeAndTimezone;
Int16
Year;
Uint8
Month;
Uint8
Day;
Uint8
Hour;
Uint8
Minute;
Uint8
Second;
Uint8
Centiseconds;
Uint8
HundredsofMicroseconds;
Uint8
Microsecond;
}
3.1.1.1
1/100秒（Uint8 Centisecond）
a) 意味：1/100秒の概念が利用可能でないオペレーティングシステム（OS）では，処理システムはこの
52
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
欄を無視しなければならない。
b) 設定値：1/100秒の概念が利用可能でないOSでは，処理システムはこの欄に0を設定しなければなら
ない。
3.1.1.2
100マイクロ秒（Uint8 HundredsofMicrosecond）
a) 意味：100マイクロ秒の概念が利用可能でないOSでは，処理システムはこの欄を無視しなければな
らない。
b) 設定値：100マイクロ秒の概念が利用可能でないOSでは，処理システムはこの欄に0を設定しなけ
ればならない。
3.1.1.3
マイクロ秒（Uint8 Microsecond）
a) 意味：マイクロ秒の概念が利用可能でないOSでは，処理システムはこの欄を無視しなければならな
い。
b) 設定値：マイクロ秒の概念が利用可能でないOSでは，処理システムはこの欄に0を設定しなければ
ならない。
3.2
第3部 ボリューム構造
3.2.1
論理ボリュームヘッダ記述子（Logical Volume Header Descriptor）
struct LogicalVolumeHeaderDesc{ /* JIS X 0607 4/14.15 */
Uint64
UniqueID,
bytes
reserved[24]
}
この構造体は，LVIDの論理ボリューム内容用（Logical Volume Contents Use）欄内にある。
3.2.1.1
一意ID（Uint64 UniqueID）
この欄は，UDF一意IDマッピングデータストリーム（Unique ID Mapping Data Stream）の次の新規のオ
ブジェクトに使用するための，次一意IDの値を含む，3.3.7.1参照。次一意IDの値は，0がルートディレ
クトリに予約されており，システムストリームディレクトリオブジェクト及び1〜15の値はMacintoshの
実装で使用するのに予約されているため，16に初期設定する。次一意IDの値は，次に記載する，新たに
作成されたオブジェクトのための新規のUDF一意IDの値の各割付けとともに単調に増加する。次一意ID
の値の下位32ビットが#FFFFFFFFに達すると，64ビット値に期待されるとおり，次の増加は上位32ビッ
トを1ずつ増加させることによって実行されるが，下位32ビットは，16（初期設定値）に折り返す。この
ような折り返しが行われると，32ビットFIDのUDF一意IDの値の一意性は保証できなくなる。そのため，
次一意IDの値が#FFFFFFFFより大きい場合，UDF一意IDマッピングデータストリームは完全に削除さ
れなければならない。
一意IDは，新しいファイル又はディレクトリが生成されるか，他の名前を現存のファイル又はディレ
クトリにリンクするときに使用する。名前の変更又は移動の場合，オブジェクトのFID一意IDの値は変
更されてはならず，該当するUDF一意IDマッピングエントリは正しく維持されなければならない
（3.3.7.1.2参照）。オブジェクトが別のディレクトリへ移動したときには，親からのこのマッピングエント
リへの参照は更新されなければならない。FIDが削除されたときは，使われなくなったUDF一意IDに該
当するマッピングエントリは再利用してはならず，削除するか無効と印を付けられなければならない。フ
ァイル識別記述子及びファイルエントリ又は拡張ファイルエントリは，ファイル又はディレクトリに関連
する，ストリームディレクトリ又は名前付きストリームに使われるが，一意IDは使用しない。むしろ，
これらの構造の一意ID欄は，ストリームが関連するファイル及びディレクトリの，ファイルエントリ・
53
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
拡張ファイルエントリの一意IDから，そうした値をとる。同じファイルエントリ・拡張ファイルエント
リの計数（counts）が拡張属性空間の定義のために使われる。親のFIDは，その一意IDの値を親FIDに識
別されるファイルエントリ・拡張ファイルエントリの下位32ビットからとる。システムストリームディレ
クトリのFID及びファイルエントリ，並びにシステムストリームディレクトリに関連するストリームの
FID及びファイルエントリは，値が0である一意IDを使わなければならない。
ファイル又はディレクトリが生成されると，この一意IDは，ファイルエントリ・拡張ファイルエント
リの一意ID欄に割り付けられ，一意IDの下位32ビットは，ファイル識別記述子（2.3.4.3参照）のlong̲ad
の処理システム用バイトのUDF一意記述子に割り付けられ，一意IDは，前に記載された方法で増加する。
名前が現存のファイル又はディレクトリにリンクすると，次一意IDの下位32ビットが，ファイル識別
記述子（2.3.4.3参照）のlong̲adの処理システム用バイトのUDF一意IDに割り付けられ，一意IDは先に
記載された方法で増加する。
下位32ビットは，ファイルエントリ・拡張ファイルエントリ及び最初のファイル識別記述子において同
じでなければならないが，後続のFIDでは異ならなければならない。
UDF処理システムは全て，この3.2.1.1に記載されているとおりに，FIDでUDF一意IDを維持するもの
とし，ファイルエントリ及び拡張ファイルエントリでは一意IDを維持しなければならない。閉じた論理
ボリューム保全記述子の論理ボリュームヘッダ記述子は，有効な一意IDをもたなければならない。
VATを使用するファイルシステムでは，LVIDのLVHDの一意ID欄の機能は，VAT ICBファイルエント
リの一意ID欄によって引き継がれ，それに加え，新たに作られたオブジェクトの最初の一意IDの値は，
この3.2.1.1で記載されている次一意IDの増加処理に従ってVAT ICB一意IDの値を一度増加させた値が
使われる。このため，VAT ICBファイルエントリと同じ一意IDをもつオブジェクトはない。
3.3
第4部 ファイル構造
3.3.1
ファイル識別記述子（File Identifier Descriptor）
struct FileIdentifierDescriptor{ /* JIS X 0607 4/14.4 */
struct tag
DescriptorTag;
Uint16
FileVersionNumber;
Uint8
FileCharacteristics;
Uint8
LengthofFileIdentifier;
struct long̲ad
ICB;
Uint16
LengthofImplementationUse;
byte
ImplementationUse[];
char
FileIdentifier[];
byte
Padding[];
}
3.3.1.1
ファイル特性（Uint8 FileChacteristics）
いろいろなOSでのファイル特性の使用法を以降の細分箇条に記載する。
3.3.1.1.1
MS-DOS，OS/2，Windows 95，Windows NT，Macintosh OS 9以前，及びMacintosh OS X
a) 意味：
1) ビット0が1の場合，隠しファイルと解釈しなければならない。
2) ビット1が1の場合，ディレクトリファイルと解釈しなければならない。
3) ビット2が1の場合，削除ファイルと解釈しなければならない。
54
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
4) ビット3が1の場合，関連するファイル識別子記述子のICB欄は，この記述子に記録するディレク
トリの親ディレクトリを識別していると解釈しなければならない。
b) 設定値：
1) 隠しファイルを示す場合，ビット0に1を指定しなければならない。
2) ディレクトリファイルを示す場合，ビット1に1を指定しなければならない。
3) 削除ファイルを示す場合，ビット2に1を指定しなければならない。
Macintosh OS Xでは隠しファイルビットに関する追加の規定が3.3.4.5.4.2にある。
3.3.1.1.2
UNIX及びOS/400
UNIX及びOS/400で，隠しファイルを隠しファイルでない普通のファイルとして処理することを除けば，
これらのビットは3.3.1.1.1の規定と同様に処理しなければならない。
3.3.2
ICBタグ（ICB Tag）
struct icbtag{
/* JIS X 0607 4/14.6 */
Uint32
PriorRecordedNumberofDirectEntries;
Uiny16
StrategyType;
byte
StrateryParameter[2];
Uint16
MaximumNumberofEntries;
byte
Reserved;
Uint8
FileType;
Lb̲addr
ParentICBLocation;
Uint16
Flags;
}
3.3.2.1
フラグ（Uint16 Flags）
3.3.2.1.1
MS-DOS，OS/2，Windows 95及びWindows NT
a) ビット6及び7（Setuid & Setgid）
1) 意味：無視する。
2) 設定値：これらのビットを利用可能とする環境の下でのセキュリティ情報のメンテナンスのために，
次に示す状態のいずれかの一つが真の場合，ビット6及び7を0に設定しなければならない。
− 一つのファイルを作成する。
− ファイルに関連付けた属性及び許可条件を修正する。
− ファイルを書き込む（ファイルに関係するデータの内容を更新して）。
− ファイルに関連する拡張属性を修正する。
− ファイルに関連する名前付きストリームを修正する。
b) ビット8（Sticky）
1) 意味：無視する。
2) 設定値：0を設定しなければならない。
c) ビット10（System）
1) 意味：MS-DOS及びOS/2システムビットに配置する。
2) 設定値：MS-DOS及びOS/2システムビットに配置する。
3.3.2.1.2
Macintosh OS 9以前
a) ビット6及び7（Setuid & Setgid）
55
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
1) 意味：無視する。
2) 設定値：これらのビットを利用可能とする環境の下でのセキュリティ情報のメンテナンスのために，
次に示す状態のいずれかの一つが真の場合，ビット6及び7を0に設定しなければならない。
− 一つのファイルを作成する。
− ファイルに関連付けた属性及び許可条件を修正する。
− ファイルを書き込む（ファイルに関係するデータの内容を更新して）。
− ファイルに関連する拡張属性を修正する。
− ファイルに関連する名前付きストリームを修正する。
b) ビット8（Sticky）
1) 意味：無視する。
2) 設定値：0を設定しなければならない。
c) ビット10（System）
1) 意味：無視する。
2) 設定値：ファイル作成時だけ0を設定し，ほかは保守しなければならない。
3.3.2.1.3
UNIX及びMacintosh OS X
a) ビット6，7及び8（Setuid, Setgid, Sticky）
これらのビットは，対応する標準UNIXファイルシステムのビットに配置される。
b) ビット10（System）
1) 意味：無視する。
2) 設定値：ファイル作成時だけ0を設定し，ほかは保守しなければならない。
3.3.2.1.4
OS/400
a) ビット6及び7（Setuid & Setgid）
1) 意味：無視する。
2) 設定値：これらのビットを利用可能とする環境の下でのセキュリティ情報のメンテナンスのために，
次に示す状態のいずれかの一つが真の場合，ビット6及び7を0に設定しなければならない。
− 一つのファイルを作成する。
− ファイルに関連付けた属性及び許可条件を修正する。
− ファイルを書き込む（ファイルに関係するデータの内容を更新して）。
− ファイルに関連する拡張属性を修正する。
− ファイルに関連する名前付きストリームを修正する。
b) ビット8（Sticky）
1) 意味：無視する。
2) 設定値：0を設定しなければならない。
c) ビット10（System）
1) 意味：無視する。
2) 設定値：ファイル作成時だけ0を設定し，ほかは保守しなければならない。
3.3.3
拡張ファイルエントリ及びファイルエントリ（Extended File Entry and File Entry）
struct FileEntry{
/* JIS X 0607 4/14.17及び4/14.9 */
struct tag
DescriptorTag;
struct icbtag
ICBTag;
56
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
Uint32
Uid;
Uint32
Gid;
Uint32
Permissions;
Uint16
FileLinkCount;
Uint8
RecordFormat;
Uint8
RecordDisplayAttributes;
Uint32
RecordLength;
Uint64
InformationLength;
Uint64
ObjectSize;
/* EFEだけ*/
Uint64
LogicalBlocksRecorded;
struct timestamp
AccessTime;
struct timestamp
ModificationTime;
struct timestamp
CreationDateAndTime;
/* EFEだけ*/
struct timestamp
AttributeTime;
Uint32
checkpoint;
Byte
Reserved[4];
/* EFEだけ*/
struct long̲ad
ExtendedAttributeICB;
struct long̲ad
StreamDirectoryICB;
/* EFEだけ*/
struct EntityID
ImplementationIdentifier;
Uint64
UniqueID;
Uint32
LengthofExtendedAttributors;
Uint32
LengthofAllocationDescriptors;
byte
ExtendedAtrributes[];
byte
AllocationDescriptors[];
}
拡張ファイルエントリ（EFE）とファイルエントリ（FE）との間の差異及び規定については2.3.6を参照。
3.3.3.1
利用者ID（Uint32 Uid）
a) 意味：利用者識別子の概念を利用可能としないOSでは，処理システムは，この欄を無視しなければ
ならない。この欄を利用可能とするOSでは，（232−1）の値は無効な利用者IDと解釈し，ほかの場合，
この欄は有効な利用者IDを含む。
b) 設定値：利用者が指定しない限り，利用者IDの概念を利用可能としないOSでは，処理システムは，
無効な利用者IDと解釈するための値（232−1）をこの欄に設定しなければならない。
3.3.3.2
グループID（Uint32 Gid）
a) 意味：グループ識別子の概念を利用可能としないOSでは，処理システムは，この欄を無視しなけれ
ばならない。この欄を利用可能とするOSでは，（232−1）の値は無効なグループIDと解釈し，ほかの
場合，この欄は有効なグループIDを含む。
b) 設定値：利用者が指定しない限り，グループIDの概念を利用可能としないOSでは，処理システムは，
無効なグループIDと解釈するための値（232−1）をこの欄に設定しなければならない。
3.3.3.3
許可条件（Uint32 Permissions）
/* Definition: */
57
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/* Bit
for a file
for a Directory
*/
/* - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
/* Execute May excute file
May search directory
*/
/* write
May change file contents
May create and delete files
*/
/* Read
May examine fil contents
May list files in directory
*/
/* ChAttr May change file attributes May change dir attributes
*/
/* Delete
May delete file
May delete directory
*/
#define OTHER̲Execute 0x00000001
#define OTHER̲Write
0x00000002
#define OTHER̲Read
0x00000004
#define OTHER̲ChAttr
0x00000008
#define OTHER̲Delete
0x00000010
#define GROUP̲Execute 0x00000020
#define GROUP̲Write
0x00000040
#define GROUP̲Read
0x00000080
#define GROUP̲ChAttr
0x00000100
#define GROUP̲Delete
0x00000200
#define OWNER̲Execute 0x00000400
#define OWNER̲Write
0x00000800
#define OWNER̲Read
0x00001000
#define OWNER̲ChAttr 0x00002000
#define OWNER̲Delete
0x00004000
セキュリティ情報を扱う許可条件の概念は，OS間で完全には移植可能でない。この規格では，次に示
す基本的な課題に言及することによって，許可条件ビットを処理する処理システム間で一貫性を保持する。
a) OSが，利用者ID及びグループIDの概念をもたない場合，所有者，グループ及びその他の許可条件
をどのように処理システムが扱うことが望ましいのか。
b) OSが，利用可能にする許可条件ビットに直接変換されない特定の許可条件ビットがある場合，処理
システムは，どのように許可条件ビットを処理することが望ましいのか。
c) 新しいファイルを作成するときに，OSが利用可能にする許可条件ビットに直接変換されない許可条
件に関しては，どのようなデフォルト値を用いることが望ましいのか。
3.3.3.3.1
所有者，グループ，その他（Owner, Group and Other）
一般に，利用者ID及びグループIDを利用可能にしないOSでは，許可条件ビットを処理するとき，次
に示すアルゴリズムを使用する。
a) 特定の許可条件を読み出す場合，全ての三つ（所有者，グループ，その他）の許可条件の論理和で値
を検査することが望ましい。例えば，OWNER̲Write，GROUP̲Write及びOTHER̲Writeの論理和が1
に等しかった場合，ファイルは書込み可能を示す。
b) 特定の許可条件を設定する場合，処理システムは許可条件ビットの三つ（所有者，グループ及びその
他）の集合を設定することが望ましい。例えば，書込み可能なファイルを示す場合，OWNER̲Write，
GROUP̲Write及びOTHER̲Writeを全て値1に設定することが望ましい。
3.3.3.3.2
デフォルト許可値（Default Permission Values）
表17では，この規格で扱う各OSに関して，そのOSで利用可能な許可条件ビットに直接変換されない
許可条件ビットについて，新しいファイルを作成するときにどのようなデフォルト値を使用することが望
ましいかを記載している。
58
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表17−許可条件
許可
ファイル又は
ディレクトリ
記載
DOS
OS/2
Win
95
Win
NT
Mac
OS 9
以前
UNIX，
OS/400，
Mac OS X
読出し
ファイル
ファイルを読み出してもよい。
1
1
1
1
1
U
読出し
ディレクトリ ディレクトリが実行の表示がある
場合だけ，読み出してもよい。
1
1
1
1
1
U
書込み
ファイル
ファイルの内容を修正してもよい。
U
U
U
U
U
U
書込み
ディレクトリ ディレクトリが実行の表示がある
場合だけ，ファイル，又はサブディ
レクトリは，名前を変更したり，加
えたり，削除してもよい。
U
U
U
U
U
U
実行
ファイル
ファイルは実行してもよい。
0
0
0
0
0
U
実行
ディレクトリ ディレクトリの許可条件は，変更し
てもよい。
1
1
1
1
1
U
属性
ファイル
ファイルの許可条件は変更しても
よい。
1
1
1
1
1
特記
事項1
属性
ディレクトリ ディレクトリの許可条件は変更し
てもよい。
1
1
1
1
1
特記
事項1
削除
ファイル
ファイルは削除してもよい。
特記
事項2
特記
事項2
特記
事項2
特記
事項2
特記
事項2
特記
事項2
削除
ディレクトリ ディレクトリは削除してもよい。
特記
事項2
特記
事項2
特記
事項2
特記
事項2
特記
事項2
特記
事項2
U：利用者指定 1：設定 0：除去
特記事項1 UNIXでは，ファイル及びディレクトリの所有者だけが，その属性を変更してもよい。Macintosh OS Xで
は，属性許可条件はUNIXと同様に取り扱うか又はユーザの指示に従う。
特記事項2 削除許可条件ビットは，書込み許可条件ビットの状態を基に設定することが望ましい。DOS，OS/2及び
Macintoshでは，ファイル又はディレクトリに書込みの表示が出たら（書込み許可条件設定），ファイルは
削除可能と考えられ，削除許可条件ビットを設定することが望ましい。ファイルが再生専用の場合，削除
許可条件ビットを設定するのは望ましくない。これは，ファイル作成とファイルの属性変更とにも適用す
る。Macintosh OS Xでは，削除許可条件はUNIXと同様に取り扱う又はユーザの指示に従う。
3.3.3.3.3
許可条件処理（Processing Permissions）
この規格で扱うOSにおいて，許可条件ビットの処理法を記載する表18に従って，処理システムは許可
条件ビットを処理する。表18は，OSが利用可能な許可条件ビットに直接変換されない許可条件ビットに
関連する項目を示す。
59
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表18−各OSの許可条件ビット処理
許可
ファイル又は
ディレクトリ
記載
DOS OS/2 Win
95
Win
NT
Mac
OS 9
以前
UNIX OS/
400
Mac
OS X
読出し
ファイル
ファイルを読み出してもよい。
E
E
E
E
E
E
E
E
読出し
ディレクトリ ディレクトリを読み出してもよい。
E
E
E
E
I
E
E
E
書込み
ファイル
ファイルの内容を更新してもよい。
E
E
E
E
E
E
E
E
書込み
ディレクトリ ファイル又はディレクトリを作成，
削除又は名前を変更してもよい。
E
E
E
E
E
E
E
E
実行
ファイル
ファイルは実行してもよい。
I
I
I
I
I
E
I
E
実行
ディレクトリ ファイル又はサブディレクトリを
規定するために，ディレクトリを検
索してもよい。
E
E
E
E
E
E
E
E
属性
ファイル
ファイルの許可条件を変更しても
よい。
E
E
E
E
E
I
I
特記
事項
属性
ディレクトリ ディレクトリの許可条件を変更し
てもよい。
E
E
E
E
E
I
I
特記
事項
削除
ファイル
ファイルを削除してもよい。
E
E
E
E
E
I
I
特記
事項
削除
ディレクトリ ディレクトリを削除してもよい。
E
E
E
E
E
I
I
特記
事項
E：実施する I：無視する
特記事項 Macintosh OS Xでは，処理系が条件をUNIXと同様に取り扱うと決めた場合は，これらの許可条件は無視
される。処理系がユーザに許可条件を設定することを許した場合は，この許可条件は実施される。同様に，
処理系が削除条件をUNIXと同様に取り扱うと決めた場合は，この条件は無視される。処理系がユーザに
削除条件を設定することを許した場合は，この条件は実施される。
検索ビットとして時々参照するディレクトリの実行ビットは，特別な意味をもつ。このビットは，ディ
レクトリの検索を可能にするが，その内容を一覧表示できるわけではない。例えば，実行許可条件だけを
設定し，読出し許可条件ビットを設定しないPRIVATEと呼ぶディレクトリがある場合，ディレクトリ
PRIVATEの内容は，一覧表示できない。PRIVATEディレクトリ中にREADMEと呼ぶ一つのファイルがあ
ると仮定する。利用者は，PRIVATEディレクトリが検索可能であるため，READMEファイルにアクセス
できる。
ディレクトリの内容を一覧表示するためには，読出し許可条件ビット及び実行許可条件ビットの両方を
ディレクトリに設定しなければならない。ファイル又はサブディレクトリの作成，削除及び名前を変更す
るためには，書込み許可条件ビット及び実行許可条件ビットの両方をディレクトリに設定しなければなら
ない。ディレクトリに対する実行ビットをもっとよく理解するためには，ファイル及びディレクトリの許
可条件を扱うUNIXの文献を参照する。ディレクトリの実行ビットに定義する規則は，全ての処理システ
ムで実施しなければならない。この規則はMacintosh OS 9以前の処理システムには該当しない。Macintosh
OS 9以前の処理システムでは，ディレクトリのアクセス可能性を決定する場合，読出しビットの状態を無
視してもよい。
特記事項 ファイル又はサブディレクトリを削除するには，ファイル又はサブディレクトリの削除許
可条件ビットが設定されており，ファイル又はサブディレクトリを含むディレクトリには，
書込み許可条件ビット及び実行許可条件ビットの両方が設定されていなければならない。
60
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.3.3.4
一意ID（Uint64 UniqueID）
3.2.1は，この欄の値がどのように設定されるかを示す。VATを使用するファイルシステムでは，LVID
のLVHDの一意ID欄の機能は，VAT ICBのファイルエントリの一意ID欄によって引き継がれる。3.2.1.1
参照。
特記事項 UDF 2.01，UDF 2.50及びUDF 2.60の版では，UDF一意IDマッピングデータで使われる
一意IDの値は，ファイルエントリからではなくファイル識別記述子からとる。
3.3.3.5
拡張属性（byte Extended Attributes[]）
ある種の拡張属性は，実行処理のためにファイルエントリ（FileEntry）のこの欄に記録することが望ま
しい。その他の拡張属性は，拡張属性ICB（ExtendedAttributeICB）欄で指示するICBに記録することが望
ましい。3.3.4では，この欄に記録することが望ましい拡張属性について規定する。
3.3.4
拡張属性（Extended Attributes）
長さの変更が起こり得る，より長い拡張属性（EA）を扱うために，次に示す規則をEA空間に適用する。
a) 一つの論理ブロック以上の属性長をもつ全てのEAは，論理ブロック境界で開始し，論理ブロック境
界で終了するブロック列でなければならない。この規則に関する唯一の例外は，最初のECMA 167 EA
の開始とする。
b) より短いEAは，4バイト単位の属性長でなければならない。
c) 各拡張属性空間は，次に示す構成のうち，一つの連続論理空間を表さなければならない。
1) JIS X 0607規格類の拡張属性
2) ブロック境界でない処理システム用拡張属性
3) ブロック境界の処理システム用拡張属性
4) 応用プログラム用拡張属性
特記事項 ファイルごとに，二つの拡張属性空間が存在してもよい。一方は，ファイルエントリ又は
拡張ファイルエントリに埋め込まれ，他方は，ファイルエントリ又は拡張ファイルエント
リ内の拡張属性ICB番地によってアクセスされる分離された空間とする。各拡張属性空間
が存在する場合は，独自の拡張属性ヘッダ記述子をもたなければならない（3.3.4.1参照）。
3.3.4.1
拡張属性ヘッダ記述子（Extended Attribute Header Descriptor）
struct ExtendedAttributedHeaderDescriptor{ /* JIS X 0607 4/14.10.1 */
struct tag
DescriptorTag;
Uint32
ImplementationAttributesLocation;
Uint32
ApplicationAttributesLocation;
}
a) 意味：この記述子の位置（Location）欄の一つの値が，拡張属性空間の長さと同等であるか，それよ
り大きいものは，対応する属性が存在しないと解釈しなければならない。
b) 設定値：この記述子の位置（Location）欄の一つに関係している属性が存在しない場合，対応する位
置欄の値は#FFFFFFFFに設定しなければならない。
3.3.4.2
代替許可条件（Alternate Permissions）
struct AltematePermissionsExtendedAttribute{ /* JIS X 0607 4/14.10.4 */
Uint32
AttributeType;
Uint8
AttributeSubtype;
byte
Reserved[3];
61
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
Uint32
AttributeLength;
Uint16
OwnerIdentification;
Uint16
GroupIdentification;
Uint16
Permission;
}
この構造は，記録してはならない。
3.3.4.3
ファイル日時拡張属性（File Times Extended Attribute）
struct FileTimesExtendedAttribute{ /* JIS X 0607 4/14.10.5 */
Uint32
AttributeType;
Uint8
AttributeSubtype;
byte
Reserved[3];
Uint32
AttributeLength;
Uint32
DataLength;
Uint32
FileTimeExistence;
byte
FileTimes;
}
3.3.4.3.1
ファイル日時（byte FileTimes）
a) 意味：この欄にファイル作成日時が含まれている場合，関連ファイルの作成日時と解釈しなければな
らない。主ファイルエントリが拡張ファイルエントリである場合，この構造のファイル作成日時は無
視し，主ファイルエントリのファイル作成日時を使用しなければならない。
b) 設定値：主ファイルエントリが拡張ファイルエントリである場合，この構造は，ファイル作成日時を
記録してはならない。
主ファイルエントリが拡張ファイルエントリではなく，ファイル日時拡張属性が存在しない場合，又は
ファイル作成日時を含まない場合，処理システムでは，ファイル作成日時を表すために，ファイルエント
リの訂正日時欄を使用しなければならない。
3.3.4.4
装置仕様の拡張属性（Device Specification Extended Attribute）
struct DeviceSpecificationExtendedAttribute{ /* JIS X 0607 4/14.10.7 */
Uint32
AttributeType;
Uint8
AttributeSubtype;
byte
Reserved[3];
Uint32
AttributeLength;
Uint32
ImplementationUseeLength; /* (= IU̲L) */
Uint32
MajorDeviceIdentification;
Uint32
MinorDeviceIdentification;
byte
ImplementationUse[IU̲L];
}
次に示す規範は，ファイルに関連する装置仕様拡張属性を作成する処理システムに従わなければならな
い。
a) ファイルが関連する装置仕様拡張属性をもつ場合，icbtag構造中のファイル種別欄の内容は，値6（ブ
ロック特殊装置ファイルを示す。）又は値7（文字特殊装置ファイルを示す。）を指定する。
62
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
b) icbtag構造中のファイル種別欄の内容が値6又は値7でない場合，ファイルに関連する装置仕様拡張
属性は無視する。
c) icbtag構造中のファイル種別欄の内容が値6又は値7に等しく，ファイルに関連する装置仕様拡張属
性がない場合，ファイルへのアクセスは拒否しなければならない。
d) ブロック特殊装置ファイルに関連する解釈方法を提供しないOS環境において，関連する装置仕様拡
張属性をもつファイルへのopen, read, write及びclose要求は拒否しなければならない。
3.3.4.4.1
処理システム用（ImplementationUse[IU̲L]）
全ての処理システムは，処理システム用欄内の最初の構造体として，一つのEntityID構造体を記録しな
ければならない。このEntityID構造体は，Developer IDによって現在の処理システムを一意に識別する（2.1.5
参照）。
3.3.4.5
処理システム用拡張属性（Implementation Use Extended Attribute）
struct ImplementationUseExtendedAttribute{ /* JIS X 0607 4/14.10.8 */
Uint32
AttributeType;
Uint8
AttributeSubtype;
byte
Reserved[3];
Uint32
AttributeLength;
Uint32
ImplementationUseLength; /* (= IU̲L) */
struct EntityID
ImplementationIdentifier;
byte
ImplementationUse[IU̲L];
}
属性長（AttributeLength）欄は，全体の拡張属性の長さを指定する。処理システム用拡張属性の使用を定
義する可変長の拡張属性に関して，属性長欄には，処理システム用（Implementation Use）欄の最後と処理
システム用拡張属性（Implementation Use Extended Attribute）の最後との間に埋込み空間を残すのに，十分
な大きさを指定することが望ましい。
3.3.4.5.1〜3.3.4.5.6では，オペレーティングシステム（OS）固有の拡張属性を記録するために，いろい
ろなOSで処理システム用拡張属性を使用する方法を記述する。
3.3.4.5.1〜3.3.4.5.6に定義する構造は，ヘッダチェックサム（header checksum）欄を含む。この欄は，処
理システム用拡張属性ヘッダの16ビットチェックサムを表す。属性種別（AttributeType）から処理システ
ム識別子（ImplementationIdentifier）までの欄を，チェックサムで保護するデータとして表す。ヘッダチェ
ックサム欄は，拡張属性空間の障害回復の支援として使う。ヘッダチェックサムのためのCのソースコー
ドを6.8に示す。
特記事項 全ての適合する処理システムでは，媒体中の既存の拡張属性を保存することを推奨する。
処理システムは，動作中のOSに関する拡張属性を作成し，利用可能にすることが望まし
い。例えば，Macintosh処理システムでは，媒体中に存在するOS/2拡張属性を保存するこ
とを推奨する。また，この規格に規定する全てのMacintosh拡張属性を作成し，利用可能
にすることが望ましい。
3.3.4.5.1
全てのオペレーティングシステム（All Operating System）
3.3.4.5.1.1
空きEA空間（FreeEASpace）
この拡張属性は，拡張属性空間で未使用な空間を示すために使用しなければならない。この拡張属性は，
処理システム用拡張属性として記録しなければならない。その処理システム用拡張属性の処理システム識
63
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
別子（ImplementationIdentifier）は，
“*UDF FreeEASpace”
に設定する。
この拡張属性の処理システム用（ImplementationUse）領域は，表19に示す構成でなければならない。
表19−空きEA空間のフォーマット（FreeEASpace format）
RBP
長さ
名前
内容
0
2
ヘッダチェックサム（Header Checksum）
Uint16
2
IU̲L−2
空きEA空間（Free EA Space）
バイト
この拡張属性は，拡張属性空間の全てを再度書き込むことなく，処理システムが他の拡張属性の全長を
縮小又は拡大することを可能にする。空きEA空間（FreeEASpace）の拡張属性は上書きしてもよく，上書
きを必要とする処理システムがその空間を再利用してもよい。
3.3.4.5.1.2
DVD著作権管理情報（DVD Copyright Management Information）
この拡張属性は，DVD著作権管理情報を示すために使用しなければならない。この拡張属性は，処理シ
ステム用拡張属性として記録しなければならない。その処理システム用拡張属性の処理システム識別子
（ImplementationIdentifier）は，
“*UDF DVD CGMS Info”
に設定しなければならない。
この拡張属性の処理システム用（ImplementationUse）領域は，表20に示す構成でなければならない。
表20−DVD CGMS Infoのフォーマット
RBP
長さ
名前
内容
0
2
ヘッダチェックサム（Header Checksum）
Uint16
2
1
CGMS情報（CGMS Information）
バイト
3
1
データ構造種別（Data Structure Type）
Uint8
4
4
保護システム情報（Protection System Information） バイト
この拡張属性は，DVD著作権管理情報の記録を可能にする。このフォーマットの解釈は，DVD
Format/Logo Licensing Corporation（6.9.3参照）が出版するDVD規定で定義しなければならない。この拡張
属性を利用可能にすることは，任意選択とする。
3.3.4.5.2
MS-DOS，Windows95及びWindowsNT
a) 意味：無視する。
b) 設定値：この拡張属性は，利用できない。媒体中の既存ファイルの拡張属性は保存しなければならな
い。
3.3.4.5.3
OS/2
OS/2は，制限のない個数の拡張属性を利用可能にする。これらの拡張属性は，3.3.8.2に定義するとおり，
名前付きストリームとして記録しなければならない。性能を高めるために，次に示す処理システム用拡張
属性を作成する。
3.3.4.5.3.1
OS/2拡張属性長（OS2EALength）
この拡張属性は，OS/2拡張属性ストリーム（3.3.8.2）情報の長さを規定する。この値は，ディレクトリ
操作でOS/2に通知する必要があるため，効率上の理由から，ファイルエントリ（FileEntry）の拡張属性
64
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
（ExtendedAttributes）欄に記録することが望ましい。この拡張属性は，処理システム識別子
（ImplementationIdentifier）に，処理システム用拡張属性として記録しなければならない。その処理システ
ム用拡張属性の処理システム識別子（ImplementationIdentifier）は，
“*UDF OS/2 EALength”
に設定しなければならない。
この拡張属性の処理システム用（ImplementationUse）領域は，表21に示す構成とする。
表21−OS/2拡張属性長フォーマット（OS/2 EALength format）
RBP
長さ
名前
内容
0
2
ヘッダチェックサム（Header Checksum）
Uint16
2
4
OS/2拡張属性長（OS/2 Extended Attribute Length） Uint32
OS/2拡張属性長欄に記録する値は，OS/2EAストリームのファイルエントリの情報長（OS/2Extended
AttributedLength）欄に一致しなければならない。
3.3.4.5.4
Macintosh OS
Macintosh OSは，次の3.3.4.5.4.1及び3.3.4.5.4.2に示す拡張属性の利用を要求する。
3.3.4.5.4.1
Macintoshボリューム情報（MacVolumeInfo）
この拡張属性は，Macintoshボリューム情報を含み，処理システム用識別子（ImplementationIdentifier）に
処理システム用拡張属性として記録しなければならない。その処理システム用拡張属性の処理システム識
別子（ImplementationIdentifier）は，
“*UDF Mac VolumeInfo”
に設定しなければならない。
この拡張属性の処理システム用（ImplementationUse）領域は，表22に示す構成でなければならない。
表22−Macintoshボリューム情報フォーマット（MacVolumeInfo format）
RBP
長さ
名前
内容
0
2
ヘッダチェックサム（Header Checksum）
Uint16
2
12
最後の更新日時（Last Modification Date）
timestamp
14
12
最後のバックアップ日時（Last Backup Date）
timestamp
26
32
ボリュームファインダ情報（Volume Finder Information）
Uint32
Macintoshボリューム情報（MacVolumeInfo）の拡張属性は，ルートディレクトリのファイルエントリ
（FileEntry）の拡張属性として記録しなければならない。
3.3.4.5.4.2
Macintoshファインダ情報（MacFinderInfo）
この拡張属性は，関連ファイル又はディレクトリのMacintoshファインダ情報を含む。この情報は頻繁
にアクセスするため，効率上の理由からファイルエントリ（FileEntry）の拡張属性（ExtendedAttributes）
欄に記録することが望ましい。
Macintoshファインダ情報の拡張属性は，処理システム用識別子（ImplementationIdentifier）に処理システ
ム用拡張属性として記録しなければならない。その処理システム用拡張属性の処理システム識別子
（ImplementationIdentifier）は，
“*UDF Mac FinderInfo”
に設定しなければならない。
65
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
この拡張属性の処理システム用（ImplementationUse）領域は，表23及び表24に示す構成でなければな
らない。
表23−ディレクトリに対するMacintoshファインダ情報フォーマット
（MacFinderInfo format for a directory）
RBP
長さ
名前
内容
0
2
ヘッダチェックサム（Header Checksum）
Uint16
2
2
埋込み（Reserved for Padding）
Uint16 = 0
4
4
親ディレクトリID（Parent Directory ID）
Uint32
8
16
ディレクトリ情報（Directory Information）
UDFDInfo
24
16
ディレクトリ拡張情報（Directory Extended Information）
UDFDXInfo
表24−ファイルに対するMacintoshファインダ情報フォーマット
（MacFinderInfo format for a file）
RBP
長さ
名前
内容
0
2
ヘッダチェックサム（Header Checksum）
Uint16
2
2
埋込み（Reserved for Padding）
Uint16 = 0
4
4
親ディレクトリID（Parent Directory ID）
Uint32
8
16
ファイル情報（File Information）
UDFFInfo
24
16
ファイルの拡張情報（File Extended Information）
UDFFXInfo
40
4
リソースフォークデータ長（Resource Fork Data Length）
Uint32
44
4
リソースフォーク割付け長（Resource Fork Allocated Length） Uint32
Macintoshファインダ情報（MacFinderInfo）の拡張属性は，論理ボリューム中の全てのファイル及びデ
ィレクトリの拡張属性として記録しなければならない。
Macintoshファインダ情報中で使用する構造は，明確化のために表25〜表30で示す。これらの構造の完
全な情報については，“Inside Macintosh”と呼ぶMacintoshの文献を参照。各構造のボリューム及びページ
番号は，“Inside Macintosh”固有のボリューム及びページに対応する。
表25−UDFPointフォーマット（ボリュームI，139ページ）
RBP
長さ
名前
内容
0
2
V
Int16
2
2
H
Int16
表26−UDFRectフォーマット（ボリュームI，141ページ）
RBP
長さ
名前
内容
0
2
Top
Int16
2
2
Left
Int16
4
2
Bottom
Int16
6
2
Right
Int16
66
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表27−UDFDInfoフォーマット（ボリュームIV，105ページ）
RBP
長さ
名前
内容
0
8
FrRect
UDFRect
8
2
FrFlags
Int16
10
4
FrLocation
UDFPoint
14
2
FrView
Int16
表28−UDFDXInfoフォーマット（ボリュームIV，106ページ）
RBP
長さ
名前
内容
0
4
FrScroll
UDFPoint
4
4
FrOpenChain
Int32
8
1
FrScript
Uint8
9
1
FrXflags
Uint8
10
2
FrComment
Int16
12
4
FrPutAway
Int32
表29−UDFFInfoフォーマット（ボリュームII，84ページ）
RBP
長さ
名前
内容
0
4
FdType
Uint32
4
4
FdCreator
Uint32
8
2
FdFlags
Uint16
10
4
FdLocation
UDFPoint
14
2
FdFldr
Int16
表30−UDFFXInfoフォーマット（ボリュームIV，105ページ）
RBP
長さ
名前
内容
0
2
FdIconID
Int16
2
6
FdUnused
バイト
8
1
FdScript
Int8
9
1
FdXFlags
Int8
10
2
FdComment
Int16
12
4
FdPutAway
Int32
特記事項1 前述した構造は，元のMacintosh構造と実際に異なることを示すために，“UDF”が先行
する元のMacintosh名をもつ。媒体中では，ビッグエンディアン形式の元のMacintosh構
造に対して，UDF構造では，リトルエンディアンで記録する。
特記事項2 Macintosh OS Xはファインダ情報に特別な隠しビットをもっている。このファインダ情
報の隠しビットは，ファイルについてはUDFFInfoのFdFlagsの15番目のビットであり，
ディレクトリについてはFrFlagsの15番目のビットである。
a) 意味：ファイル又はディレクトリのファインダ情報を読んだ後，このファイル又は
ディレクトリのファイル識別子（FID）のFile Characterics欄の隠しビットの値はア
プリケーションに返すファインダ情報の隠しフラグにコピーされなければならない。
このファイル又はディレクトリがファインダ情報をもたず，かつ，FIDの隠しビッ
トが設定されている場合は，隠しビットだけが設定された，全て0のファインダ情
67
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
報をアプリケーションに返さなければならない。このファイルを二つ以上のFIDが
指している場合は，アプリケーションに返すファインダ情報の隠しフラグは，この
ファイルを探すのに最後に使ったFIDの隠しビットの値と同じに設定しなければな
らない。読出し時にはディスク上のデータは変更してはならない。
b) 設定値：媒体上のファインダ情報を更新する場合は，ファインダ情報の隠しフラグ
はこのファイル又はディレクトリを指すFIDの隠しビットにコピーされなければな
らない。このファイルを二つ以上のFIDが指している場合は，少なくとも一つのFID
の隠しビットがファインダ情報の隠しフラグによって更新されなければならない。
どのFIDが更新されるかは処理系に依存する。
この規定はWindowsとMacintosh OS Xとの間の隠しファイルの相互互換性を向上させ，
Windows上の隠しファイルはMacintosh OS Xでも隠され，また，その逆も成り立つ。ハ
ードリンクをもつファイルについては，隠しファイルの振る舞いは不定である。
3.3.4.5.5
UNIX
a) 意味：無視する。
b) 設定値：この拡張属性は，利用できない。媒体上の既存ファイルの拡張属性は，保存しなければなら
ない。
3.3.4.5.6
OS/400
OS/400は，次の3.3.4.5.6.1に示す拡張属性の利用を要求する。
3.3.4.5.6.1
OS400DirInfoフォーマット
この属性は，OS/400拡張ディレクトリ情報を規定する。この値は，ディレクトリ操作でOS/400に通知
する必要があるため，効率上の理由から，ファイルエントリの拡張属性欄に記録することが望ましい。こ
の拡張属性は，処理システム用拡張属性として記録しなければならない。その処理システム用拡張属性の
処理システム識別子は，
“*UDF OS/400 DirInfo”
に設定しなければならない。
この拡張属性の処理システム用（ImplementationUse）領域は，表31に示す構成でなければならない。
表31−OS400DirInfoフォーマット（OS400DirInfo format）
RBP
長さ
名前
内容
0
2
ヘッダチェックサム（Header Checksum） Int16
2
2
埋込み（Reserved for Padding）
Int16 = 0
4
44
ディレクトリ情報（DirectoryInfo）
Int16
OS400DirInfoフォーマットに記録するディレクトリ情報の構造の全ての情報は，IBMの次の規定を参照
する。
IBM OS/400 UDF Implementation
Optical Storage Solutions, Department HTT
IBM
Rochester, Minnesota
3.3.4.6
応用プログラム用拡張属性（Application Use Extended Attribute）
struct ApplicationUseExtendedAttribute{ /* JIS X 0607 4/14.10.9 */
68
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
Uint32
AttributeType; /*= 65536 */
Uint8
AttributeSubtype;
byte
Reserved[3];
Uint32
AttributeLength;
Uint32
ApplicationUseLength; /* (= AU̲L) */
struct EntityID
ApplicationIdentifier;
byte
ApplicationUse[AU̲L];
}
属性長（AttributeLength）欄は，全体の拡張属性の長さを指定する。アプリケーション用拡張属性の使用
を定義する可変長の拡張属性に対して，属性長欄には，アプリケーション用（Application Use）欄の最後及
びアプリケーション用拡張属性（Application Use Extended Attribute）の最後との間に埋込み空間を残すのに，
十分な大きさを指定することが望ましい。
次の3.3.4.6.1に定義する構造は，ヘッダチェックサム（header checksum）欄を含む。この欄は，アプリ
ケーション用拡張属性ヘッダの16ビットチェックサムを表す。属性種別（AttributeType）からアプリケー
ション識別子（ApplicationIdentifier）までの欄を，チェックサムで保護するデータとして表す。ヘッダチェ
ックサム欄は，拡張属性空間の障害回復の支援として使う。ヘッダチェックサムのためのCのソースコー
ドを6.8に例示する。
特記事項 全ての適合する処理システムでは，媒体中の既存の拡張属性を保存することを推奨する。
処理システムは，動作中のOSに対する拡張属性を作成し，利用可能にすることが望まし
い。例えば，Macintosh処理システムでは，媒体中に存在するOS/2拡張属性を保存するこ
とを推奨する。この規格に規定する全てのMacintosh拡張属性をも作成し，利用可能にす
ることが望ましい。
3.3.4.6.1
全てのオペレーティングシステム（All Operating Sytsem）
3.3.4.6.1.1
FreeAppEASpace
この拡張属性は，拡張属性空間でアプリケーション用拡張属性に確保された未使用な空間を示すために
使用しなければならない。この拡張属性は，アプリケーション識別子（ApplicationIdentifier）に
“*UDF FreeAppEASpace”
を設定するアプリケーション用拡張属性として記録しなければならない。
この拡張属性のアプリケーション用（ApplicationUse）領域は，表32に示す構成でなければならない。
表32−FreeAppEASpaceのフォーマット（FreeAppEASpace format）
RBP
長さ
名前
内容
0
2
ヘッダチェックサム（Header Checksum） Uint16
2
IU̲L−1
空きEA空間（Free EA Space）
バイト
この拡張属性は，拡張属性空間の全てを再度書き込むことなく，処理システムが他の拡張属性の全長を
縮小又は拡大することを可能にする。FreeAppEASpaceの拡張属性は，上書きしてもよく，上書きを必要と
する処理システムがその空間を再利用してもよい。
3.3.5
名前付きストリーム（Named Stream）
名前付きストリームは，ファイルの関連データを関連付ける機構を提供する。この機構は，概念的に拡
張属性に類似している。しかし，名前付きストリームは，拡張属性よりもはるかに優れている。名前付き
69
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ストリームには，長さの制限がない。各名前付きストリームは独自の空間をもつため，拡張属性の共通空
間よりもはるかに空間管理を行いやすい。特定の名前付きストリームを見つけるのに，拡張属性の場合に
必要であったデータ空間全体の検索は行わない。
名前付きストリームは，主に利用者データを対象にする。例えば，データベースアプリケーションは，
レコードをデフォルトストリーム又は主ストリームに記録してもよく，索引を名前付きストリームに記録
してもよい。そこで利用者は，多くのファイルではなくデータベース用の一つのファイルだけを見ること
になり，アプリケーションは，多様な名前付きストリームをあたかも独立したファイルとして使用できる。
名前付きストリームは，拡張ファイルエントリによって識別する。拡張ファイルエントリは，関連付け
られた名前付きストリームをもつファイルに必要となる。名前付きストリームをもたないファイルは，拡
張ファイルエントリを使用することが望ましい。ファイルは通常のファイルエントリを含んでもよい。通
常のファイルエントリは，DVDビデオディスクの書込みなどの下位互換性が必要な場合に使われる。
ファイル集合記述子によって識別されるストリームディレクトリであるシステムストリームディレクト
リがある。これらのストリームは，ファイルに関連するデータではなく，媒体全体に関連するデータを記
載するために使用する。UDFは，システムストリームディレクトリによって識別される幾つかのシステム
ストリームを定義する。
唯一の例外は，システムストリームディレクトリの親は，システムストリームディレクトリでなければ
ならないことである。
名前付きストリームは，新しい処理システムにおいて，拡張属性ではなく，メタデータ及びアプリケー
ションデータを記録するのに使うことを推奨する。
3.3.5.1
名前付きストリームの制約（Named Stream Restrictions）
JIS X 0607規格類はその追補1とともに，ストリームディレクトリを識別する欄を含む，新しい拡張フ
ァイルエントリを定義している。新しい拡張ファイルエントリは，古いファイルエントリの代わりに用い，
名前付きストリーム自体を記述するのに用いることが望ましい。ファイルエントリ及び拡張ファイルエン
トリは，自由に混合してもよい。特に，古い再生用の処理システムとの互換性で，特定のファイルが保守
され得る。しかし，ファイルエントリの代わりに拡張ファイルエントリを使用することが推奨される（3.3.5
参照）。
制約：
a) ストリームディレクトリ又は名前付きストリームを記述するICBの，ストリームディレクトリICB欄
は，0に設定しなければならない（階層的なストリームではない。）。
b) 各名前付きストリームは，厳密に一つのストリームディレクトリにおける，厳密に一つのFIDによっ
て識別されなければならない［名前付きストリーム又はファイルとのハードリンク（hard link）では
ない。］。
c) 各ストリームディレクトリICBは，厳密に一つのストリームディレクトリICB欄によって識別されな
ければならない（ストリームディレクトリへのハードリンクではない。）。
d) 名前付きストリームをもつファイルへのハードリンクは，許容される。
e) 名前付きストリーム及びストリームディレクトリは，拡張属性をもってはならない。
f)
名前付きストリーム及びストリームディレクトリを規定するファイル識別記述子及びファイルエント
リ・拡張ファイルエントリの一意ID欄がどのように設定されるかは，3.2.1.1に示す。
g) 主ファイルエントリのUID，GID及び許可条件の欄は，主ストリームに関連付けられた全ての名前付
きストリームに適用する。名前付きストリームの作成時に，主ファイルエントリのUID，GID及び許
70
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
可条件の欄の値は，名前付きストリームの対応する欄のデフォルト値として使用することが望ましい。
処理システムは，名前付きストリームのこれらの欄を保守又はチェックする必要はない。
h) 処理システムは，FIDの中で設定されたメタデータビットでマーク付けされた名前付きストリームを
利用者に示さないことが望ましい。メタデータビットでマーク付けされた名前付きストリームは，フ
ァイルシステムの実装での使用だけを目的とする。
i)
ストリームディレクトリにおける親エントリFIDは，主拡張ファイルエントリを指示し，したがって，
その参照は，拡張ファイルエントリのファイルリンク数欄で数えなければならない。唯一の例外は，
システムストリームディレクトリの親は，システムストリームディレクトリでなければならないこと
である。
特記事項 ファイル又はディレクトリを削除する場合，次の危険があり得る。FIDが削除されるとき
に，ファイルリンク数が1になると，処理システムでは，ストリームディレクトリの存在
をチェックすることが望ましい。ストリームディレクトリが存在すると，このファイルエ
ントリを示すFIDはもはやない。したがって，それと関連する構造は，全て削除されるこ
とが望ましい。
j)
主拡張ファイルエントリの訂正日時欄は，関連する名前付きストリームの訂正時には必ず更新するこ
とが望ましい。主拡張ファイルエントリのアクセス日時欄は，関連する名前付きストリームへのアク
セス時には必ず更新することが望ましい。主拡張ファイルエントリにおけるICBタグフラグ欄の
SETUIDビット及びSETGIDビットは，関連する名前付きストリームの訂正時には，必ずクリアする
ことが望ましい。
k) 名前付きストリームディレクトリのICBは，ファイル種別13をもたなければならない。全ての名前
付きストリームは，ファイル種別5をもたなければならない。
l)
全てのシステムは，名前付きストリームを実装していない実装システムにおいても，主データストリ
ームを利用可能にしなければならない。
3.3.5.2
UDF定義システム名前付きストリーム（メタデータ）［System Named Stream（Metadata）］
名前付きストリームの集合は，ファイルシステム用にUDFによって規定する。UDF名前付きストリー
ムの中には，ファイル集合記述子［システムストリームディレクトリ（System Stream Directory）］によっ
て識別され，ファイル集合全体に適用されるものもある。これらはUDF定義のシステムストリームと呼ば
れ，3.3.7で定義される。他のUDF名前付きストリームは，個々のファイル又はディレクトリに属し，そ
のファイル又はディレクトリのストリームディレクトリによって識別される。これらはUDF定義の非シス
テムストリームと呼ばれ，3.3.8で定義される。
全てのUDF定義名前付きストリームは，この規格で特記しない限り，ストリームディレクトリのファイ
ル識別記述子においてセットされたメタデータビットをもたなければならない。ファイルシステムの実装
によって生成されない名前付きストリームは，全てこのビットを0に設定しなければならない。
4文字の*UDFは，この規格におけるUDF定義の全ての名前付きストリームの最初の4文字とする。処
理システムは，この規格で規定していない名前付きストリームに，*UDFで始まる識別子を使用してはな
らない。*UDFで始まる名前付きストリームのための全ての識別子は，OSTAによる将来の定義のために
確保される。
3.3.6
名前付きストリームとしての拡張属性（Extended Attributes as named stream）
特記事項 幾つかの種類の拡張属性から名前付きストリームへの変更が不可能だと判明したため，そ
して，拡張属性から名前付きストリームへの自動変換を許すことははじめから意図されて
71
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
いなかったため，この3.3.6は，UDF 2.01の後の版（UDF 2.50及びUDF 2.60）では修正さ
れた。いかなる拡張属性も名前付きストリームに変換することは許されていない。
3.3.7
UDF定義のシステムストリーム（UDF Defined System Streams）
この細分箇条は，UDF定義のシステムストリームの規定を含む（表33参照）。
表33−UDF定義のシステムストリーム
ストリーム名
ストリーム位置
メタデータフラグ
“*UDF Unique ID Mapping Data”
システムストリームディレクトリ（ファイル集合記述子）
1
“*UDF Non-Allocatable Space”
システムストリームディレクトリ（ファイル集合記述子）
1
“*UDF Power Cal Table”
システムストリームディレクトリ（ファイル集合記述子）
1
“*UDF Backup”
システムストリームディレクトリ（ファイル集合記述子）
1
表33に列挙されたシステムストリームは，メタデータフラグ集合を備えているので，処理システムは，
プラットフォームの“プラグインファイルシステムインタフェース（plug-in file system interface）”を介し
てシステムストリームの名前を渡してはならない。
3.3.7.1
一意IDマッピングデータストリーム（Unique ID Mapping Data Stream）
一意IDマッピングデータは，処理システムが，UDF一意IDに関連付けられたファイル及びディレクト
リに対するICB階層に直接進むことを可能にするか，又はUDF一意IDに関連付けられたファイル及びデ
ィレクトリを含むディレクトリに対するICB階層に進むことを可能にする。このために使われるUDF一
意IDの値は，UDF 2.01，UDF 2.50及びUDF 2.60の版ではファイルエントリからではなくファイル識別記
述子からとられる。
一意IDマッピングデータは，（ファイル集合記述子に関連付けられた）システムストリームディレクト
リの名前付きストリームとして記録される。このシステムストリームの名前は
“*UDF Unique ID Mapping Data”
に設定しなければならない。
このストリームのファイル識別記述子のファイル特性欄の中のメタデータビットは，プラットフォーム
のファイルシステムインタフェースのクライアントに，このストリームの存在を知らせないことが望まし
いことを示すため，1に設定しなければならない。一意IDマッピングデータストリームの存在及び一貫性
のための規則は，
a) 再生専用媒体のために作成されなければならない。
b) 追記形及び書換可能形媒体にボリュームをバッチ書込みする処理システム（例えば，プリマスタリン
グツール）によって作成されなければならない。
c) 追記形又は書換可能形媒体（例えば，オンラインファイルシステム）にボリュームのインクリメンタ
ルな更新をする処理システムには，次の規則を適用する。
1) 存在しない場合は，作成し，保守してもよい。
2) 存在しており，ボリュームがクリーンな場合，保守しなければならない。
3) 存在しているが，ボリュームがダーティな場合，修復し保守することが望ましいが，消去してもよ
い。
これらの規則に関して，有効な閉じた論理ボリューム保全記述子，又は有効な仮想番地表のいずれかが
記録されれば，ボリュームはクリーンである。
72
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.3.7.1.1
UDF一意IDマッピングデータ（UDF Unique ID Mapping Data）
一意IDマッピングのストリームの内容は，“UDF一意IDマッピングデータ”及び“UDF一意IDマッ
ピングエントリ”表によって示される。マッピングデータはマッピングエントリの配列の前にヘッダ欄を
含む。この構造の欄は，表34の対応表によって示される。
表34−UDF一意IDマッピングデータ
RBP
長さ
名前
内容
0
32
処理システム識別子
実体ID
32
4
フラグ
Uint32
36
4
マッピングエントリカウント（= MEC） Uint32
40
8
予約（Reserved）
バイト（= #00）
48
16×MEC マッピングエントリ
IDマッピングエントリ
処理システム識別子は，2.1.5に記載されている。
フラグは，次のとおりに規定される。
a) ビット0はインデックスビットであり，1に設定するとき，インデックスモードと呼ぶ。インデック
スモードでは，UDF一意IDは一度16（次一意IDが初期設定される値）減らされると，配列マッピ
ングエントリの項目として使用できる。
b) 予約のビット1〜31は，0に設定しなければならない。
c) マッピングエントリカウントは，配列マッピングエントリの，エントリにおける大きさである。
d) マッピングエントリは，UDF一意IDマッピングエントリ（表35参照）構造の配列である。非ストリ
ームの親でないファイル識別記述子ごとに，一つのマッピングエントリがある。
ボリュームが一致していれば，常に配列は，UDF一意IDの昇順にソートされる。
3.3.7.1.2
UDF一意IDマッピングエントリ（UDF Unique ID Mapping Entry）
表35−UDF一意IDマッピングエントリ
RBP
長さ
名前
内容
0
4
UDF一意ID
Uint32
4
4
親論理ブロック番号
Uint32
8
4
オブジェクト論理ブロック番号
Uint32
12
2
親区画参照数
Uint16
14
2
オブジェクト区画参照数
Uint16
a) UDF一意IDは，オブジェクトを識別するFIDの値とする。
b) 親論理ブロック番号は，オブジェクトを識別するFIDを含むディレクトリを識別するICBの論理ブロ
ック番号とする。
c) オブジェクト論理ブロック番号は，オブジェクトを識別するFIDのICB欄のlong̲adからの論理ブロ
ック番号とする。
d) 親区画参照番号は，オブジェクトを識別するFIDを含むディレクトリを識別するICBの区画参照番号
とする。
e) オブジェクト区画参照番号は，オブジェクトを識別するFIDのICB欄のlong̲adからの区画参照番号
とする。
インデックスモードでは，最初のエントリは16であるUDF一意IDをもち，引き続くエントリはそれ
73
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
以前のエントリより1以上大きなUDF一意IDの値をもつことを求められる。
インデックスモードでない場合は，配列を縮めるために無効なエントリは削除されてもよい。無効なエ
ントリは，UDF一意ID欄以外の全ての欄で0の値をもつことで示される。無効なエントリは，媒体から
オブジェクトが削除された結果であるか，マッピングエントリ配列の最後のまだ使用中でないエントリで
ある。
ストリームでなく，親FIDでないものは，有効なエントリでなければならない。
特記事項 オブジェクトのマッピングエントリのUDF一意IDの値はそのオブジェクトのファイルエ
ントリの一意IDの値と同じである必要はない。
次の手順を実行することによって，マッピングエントリの正しさを検証できる。
a) オブジェクトの親ディレクトリのファイルエントリをマッピングエントリの親論理ブロック番号及び
親区画参照番号を用いて読み出す。
b) 親ディレクトリ内でマッピングエントリのUDF一意IDと同じ値のUDF一意IDをもつFIDを探す。
c) このFIDのICB欄のlong̲adは，マッピングエントリのオブジェクト論理ブロック番号及びオブジェ
クト区画参照番号の値にそれぞれ等しい論理ブロック番号及び区画参照番号の値を含んでいなければ
ならない。
3.3.7.2
割付け禁止空間ストリーム（Non-Allocatable Space Stream）
JIS X 0607規格類は，媒体の欠陥領域を記載したり，ファイルシステム以外の割付けのために使用でき
ない領域を記載する機構を規定しない。割付け禁止空間ストリームは，ファイルシステムが使用できない
空間を記載するための方法を提供する。割付け禁止空間ストリームは，予備区画マップが記録されたボリ
ュームだけに記録されなければならない。
割付け禁止空間ストリームは，初期化時に生成されなければならない。割付け禁止空間ストリームが示
す空間も，全て未割付け空間ビットマップ又は未割付け空間表で割付け済みとしてマーク付けされなけれ
ばならない。割付け禁止空間ストリームは，ファイル集合記述子のシステムストリームディレクトリでシ
ステムストリームとして記録されなければならない。システムストリーム名は，次のとおりでなければな
らない。
“*UDF Non-Allocatable Space”
ストリームは，メタデータ（ファイル特性集合のビット4をONEに設定する。）及びシステム（ICBタ
グフラグ欄のビット10をONEに設定する。）の属性でマーク付けされなければならない。このストリー
ムの割付け記述子は，割付け禁止パケットを識別しなければならない。この割付け記述子は，割付け種別
1（割り付け済みであるが未記録）でなければならない。このストリームのファイルエントリの情報長は0
でなければならず，そのため全ての割付け記述子はファイルの最後にある。このストリームには，初期化
時の欠陥パケットと初期化時に予備のため割り付けられる空間との両方が含まれなければならない。
3.3.7.3
パワーこう（較）正ストリーム（Power Calibration Stream）
CD-Rドライブのパケットライト機能を効果的に利用するときにあり得る制限の一つに，現CD-R媒体
で利用可能な，パワーこう（較）正領域の限られた数（100）がある。これらのパワーこう（較）正領域は，
ドライブに現在入っているCD-Rディスクに，データを確実にうまく書き込める適切なパワーこう（較）
正設定を確立するのに使われる。特定のドライブのための適切な設定値は，同一の製造及び型をもつ二つ
の異なるドライブ間で異なり，同一のディスク，ドライブ及びシステム構成を使っても，環境条件が異な
れば，ディスク間で大きく異なる。
このため，ほとんどの現在のCD-Rドライブは，媒体変更が起きた後の最初の書込みが行われようとす
74
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
るときに，こう（較）正し直す。ディスクアトワンス又はトラックアトワンスのモードを使って記録する
場合には，これが制約を課することはない。それは，これらの各モードでは，100回に満たない各書込み
でディスクが（利用可能なデータ容量を全て使い，又は記録可能なトラック数を全て使って）一杯になる
ことによる。しかしパケットライトを使うと，ディスクはディスクが一杯になるまで，長期間にわたって，
何千回も書き込むことができる。
例えば，仮に，各作業日の最後に新規ファイル・訂正ファイルを増加的にバックアップしたいとする（ド
ライブは同じ日に他の仕事で断続的に使われるかもしれないが）。これらのバックアップには，1日に1 MB
（又はそれ以下）程度の書込みが必要かもしれない。毎日ディスクに書込みする前に，パワーこう（較）
正領域の一つがドライブのこう（較）正に使われれば，5か月以内にパワーこう（較）正領域は全て使用
されることになるが，消費されるのは，ディスクの全容量の一部分だけとなる。その結果は，それらの製
品の利用者が予期しないことであり，受け入れられそうもない。
業界では，CD-Rディスクのパワーこう（較）正領域を使わなければならない頻度を減らす方法を提供
しようと試みている。少なくとも，現在のCD-Rドライブのあるモデルは，最近使用した少数のディスク
それぞれにデータを記録するのに使われた最後のパワーこう（較）正値を記憶しようとする。ほとんどの
CD-Rドライブは，ホストソフトウェアが，現ディスクにデータを記録するために，ドライブで使われた
最新のパワーこう（較）正設定をドライブから検索し，将来それらを回復して使用する機構を備えている。
ここに示されるパワーこう（較）正表は，互換性のある処理システムで将来使用するため，こうして得
られたパワーこう（較）正情報をディスクに記録するのに使われる。表はヘッダで構成されており，この
ヘッダの後には，このディスクにデータを記録するため，異なる条件の下で多様なドライブ・ホストが使
用してきたパワーこう（較）正設定を含むレコードのリストが続く。記録済みこう（較）正設定のいずれ
が将来の状況で使用するのに適しているかを決定するのに使用できる，他の関連情報も続く。記録済みパ
ワーこう（較）正情報を効果的に使用するため，あらゆる必要な情報を予想し，含めるための努力が払わ
れてきたが，それらの情報が実際に使われるのか，使われる場合はいつどのような形でかを決定するには，
個々の処理システムに依存している。
パワーこう（較）正表は，3.3.5の規則に従って，ファイル集合記述子のシステムストリームとして記録
されなければならない。システムストリーム名は，次のとおりでなければならない。
“*UDF Power Cal Table”
パワーこう（較）正表を利用できない処理システムは，このシステムストリームを消去してはならない。
さらに，パワーこう（較）正表を利用可能な処理システムは，その処理システムがその使用によって，明
らかにかつ特定して使われていない又は更新した以外のレコードを表から消去したり修正してはならない。
ストリームは次のとおりに初期化しなければならない。
3.3.7.3.1
パワーこう（較）正表ストリーム（Power Calibration Table Stream）
表36−パワーこう（較）正表ストリーム
RBP
長さ
名前
内容
0
32
処理システム識別子（Implementation Identifier）
実体ID（2.1.5）
32
4
レコード数（Number of Records）
Uint32[1/7.1.5]
56
*
パワーこう（較）正表レコード（Power Calibration Table Records）
バイト
処理システム識別子については，2.1.5を参照。
レコード数は，パワーこう（較）正表に含まれるレコード数を指定しなければならない。
75
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
パワーこう（較）正表レコードは，このディスクに書き込んだドライブのための一連のパワーこう（較）
正表レコードとする。この表の長さは可変であるが，4バイトの倍数とする。未構造化欄のデータの記録
は左そろ（揃）えにしなければならず，右側は，#20バイトで埋めなければならない（表36参照）。
表37−パワーこう（較）正表レコードレイアウト
RBP
長さ
名前
内容
0
2
レコード長（Record Length）
Uint16[1/7.1.3]
2
2
ドライブ一意領域長[DUA̲L] （Drive Unique Area Length[DUA̲L]） Uint16[1/7.1.3]
4
32
ベンダID（Vendor ID）
バイト
36
16
製品ID（Product ID）
バイト
52
4
ファームウェア改正レベル（Firmware Revision Level）
バイト
56
16
連続番号又は装置一意ID（Serial Number/Device Unique ID）
バイト
72
8
ホストID（Host ID）
バイト
80
12
生成日時スタンプ（Originating Time Stamp）
日時スタンプ[1/7.3]
92
12
更新日時スタンプ（Updated Time Stamp）
日時スタンプ[1/7.3]
104
2
速度（Speed）
Uint16[1/7.1.3]
106
6
パワーこう（較）正値（Power Calibration Values）
バイト
112
[DUA̲L]
ドライブ一意領域（Drive Unique Area）
バイト
a) レコード長：このパワーこう（較）正表レコード（表37参照）のバイトの長さで，任意選択の可変長
ドライブ一意領域を含む。4バイトの倍数でなければならない。
b) ドライブ一意領域長：このレコードの最後のバイトに記録される任意選択のドライブ一意領域の長さ。
4バイトの倍数でなければならない。
c) ベンダID：ドライブによって報告されるベンダID。
d) 製品ID：ドライブによって報告される製品ID。
e) ファームウェア改正レベル：ドライブによって報告されるファームウェア改正レベル。
f)
連続番号又は装置一意ID：ベンダによって指定されるモデルの，特定ドライブに関する連続番号又は
その他の一意識別子，及びこのディスクにデータを記録するために報告されたパワーこう（較）正値
をうまく使用した，与えられた製品ID。
g) ホストID：ホスト連続番号，イーサネットID又はその他の値（又は値の組合せ）。これは，このディ
スクにデータを記録するために報告されるパワーこう（較）正値をうまく使用したときに，ドライブ
が接続されている特定のホストコンピュータを識別する処理システムによって使用される。処理シス
テムでは，各ホストに対して一意の値を提供しようとしなければならないが，値の一意性を保証する
必要はない。
h) 生成日時スタンプ：パワーこう（較）正値が記録された日時で，適切に使用されたことを最初に証明
している。
i)
更新日時スタンプ：パワーこう（較）正値が記録された日時で，適切に使用されたことを最近証明し
ている。
j)
速度：ドライブで報告される記録速度で，ここに記録されたパワーこう（較）正値が適切に使用され
た記録速度。この値は，データがドライブによってディスクに書き込まれた，毎秒のキロバイト（バ
イト／1 000分の1）数である（端数は切り捨てる。）。例えば，176という速度は，データがディスク
に毎秒176キロバイトで書き込まれたことを意味する。これは，基本的なCD-DA（ディジタルオーデ
ィオ）のデータ速度（CD-DAで別名“1X”）である。353の速度は，データがディスクに毎秒353キ
76
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ロバイト，つまり，CD-DAの基本速度の2倍の速度（CD-DAで別名“2X”）で書き込まれたことを
意味する。CD-ROMの記録速度は，正しい速度値（例えば，“1X”のCD-ROMデータ速度は，176の
速度である“1X”CD-DAとして記録することが望ましい。）を決定するために，対応するCD-DA速
度に対して高めに（約15 %）調整することが望ましい。注意することは，これらは未処理のデータで
あり，（追加の）ヘッダ，エラー訂正データなどに起因するオーバヘッドを全て反映しているわけでは
ない。
k) パワーこう（較）正値：ドライブによって報告されるベンダ固有のパワーこう（較）正値である。
l)
ドライブ一意領域：ドライブに対して一意の，非制限情報を記録するための任意選択の領域で，ある
処理システムは，記録済みパワーこう（較）正情報の使用，又は関連付けられたドライブの操作を拡
張するために，この領域を使用してもよい。この欄のデータの記録は，ドライブ製造業者が定義しな
ければならない。この領域は，4バイト長の整数倍でなければならない。
3.3.7.4
UDFバックアップ日時（UDF Backup Time）
このストリームの名前は
“*UDF Backup”
に設定しなければならない。
このストリームは，表38の内容をもつものとし，ICBに埋め込まなければならない。
表38−UDFバックアップ日時
RBP
長さ
名前
内容
0
12
バックアップ日時（Backup Time）
日時スタンプ
バックアップ日時は，このボリュームのバックアップが実行された最新の時間である。
3.3.8
UDF定義の非システムストリーム（UDF Defined Non-System Streams）
この細分箇条では，表39の非システムストリームを定義している。
表39−UDF定義の非システムストリーム
ストリーム名
ストリーム位置
メタデータフラグ
*UDF Macintosh Resource Fork
ファイル（Any File）
0
*UDF OS/2 EA
ファイル又はディレクトリ（Any File or directory）
0
*UDF NT ACL
ファイル又はディレクトリ（Any File or directory）
0
*UDF UNIX ACL
ファイル又はディレクトリ（Any File or directory）
0
3.3.8.1
Macintosh資源フォークストリーム（Macintosh Resource Fork Stream）
資源フォークは明瞭なインタフェースで参照するため，UDF処理システムでは，このストリームに正式
な名前を与えていない。交換のためには，名前は，次のとおりに設定しなければならない。
“*UDF Macintosh Resource Fork”
ファイル識別記述子のファイル特性（File Characteristics）欄のメタデータビットは，プラットフォーム
ファイルシステムインタフェースのクライアントに，このファイルの存在を知らせることが望ましいこと
を示すため，0に設定しなければならない。
3.3.8.2
OS/2 EAストリーム（OS/2 EA Stream）
OS/2で規定できる拡張属性は，全て名前付きストリームとして記録するものとし，その名前は，次のと
おりに設定しなければならない。
77
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
“*UDF OS/2 EA”
OS/2 EAストリーム（OS2EA Stream）は，表40に示すとおり，OS/2完全EA（FEA）の表を含む。
表40−FEAフォーマット
RBP
長さ
名前
内容
0
1
Flags
Uint8
1
1
Length of Name（= L̲N）
Uint8
2
2
Length of Value（= L̲V）
Uint16
4
L̲N
Name
バイト
4＋L̲N
L̲V
Value
バイト
完全EA（FEA）の完全な記述のためには，IBMの次の規定を参照。
“Installable File System for OS/2 Version 2.0”
OS/2 File Systems Department
PSPC Boca Raton, Florida
February 17, 1992
3.3.8.3
アクセス管理リスト（Access Control List）
ある種のオペレーティングシステム（OS）では，ファイルへのアクセスの制約を強化するためアクセス
管理リスト（ACL）の概念を利用可能としている。ACLの利用を促進するため，UDF 2.00では，システム
レベルの名前付きストリームの集合を規定している。このストリームの目的は，与えられたファイル対象
に関連するACLを記録することである。
UDFのACLは，3.3.5の規則に従って，名前付きストリームとして記録される。名前付きストリームACL
の内容は不明瞭であり，この規格では規定しない。名前付きストリームACLの内容の解釈は，ACLが意
図しているOSに任されなければならない。次の名前は，ACLを識別するのに使われ，予約されなければ
ならない。これらの名前はアプリケーション名前付きストリームに使用してはならない。
“*UDF NT ACL”
この名前は，Windows NT OSで，名前付きストリームACLを識別しなければならない。
“*UDF UNIX ACL”
この名前は，UNIX OSで，名前付きストリームACLを識別しなければならない。
4
利用者インタフェース要件
4.1
第3部 ボリューム構造
JIS X 0607規格類の第3部には，処理システムに依存して，利用者に提示しなければならないいろいろ
な識別子を含む。
a) ボリューム識別子（VolumeIdentifier）
b) ボリューム集合識別子（VolumeSetIdentifier）
c) 論理ボリューム識別子（LogicalVolumeIdentifier）
d) ファイル集合識別子（FileSetIdentifier）
これらの識別子は，CS0で記録され，利用者に表示可能にするために，ある翻訳方式を採らなければな
らないことがある。そのため，処理システムが前記の識別子について，オペレーションシステム（OS）固
有の解釈を実行しなければならないとき，処理システムは4.2.2.1に記載するアルゴリズムを使用しなけれ
78
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ばならない。
翻訳アルゴリズムのためのCのソースコードは，6.7に示す。
4.2
第4部 ファイル構造
4.2.1
ICBタグ（ICB Tag）
Struct icbtag {
/* JIS X 0607 4/14.6 */
Uint32
PriorRecordedNumberofDirectEntries;
Uint16
StrategyType;
byte
StrategyParameter[2];
Uint16
MaximumNumberofEntries;
byte
Reserved;
/* == #00 */
Uint8
FileType;
Lb̲addr
ParentICBLocation;
Uint16
Flags;
}
4.2.1.1
ファイル種別（FileType）
UNIXでないOS環境では，次に示す値のいずれかをこの欄の中にもつファイルに関するopen，close，
read及びwrite要求は，アクセス拒否エラーの状態でなければならない。
ファイル種別値−0（Unknown），6（ブロック装置），7（文字装置），9（FIFO）
及び10（C̲ISSOCK）
種別12［シンボリックリンク（SymbolicLink）］のファイルに関するopen，close，read及びwrite要求は，
このシンボリックリンクが指し示しているファイル又はディレクトリにアクセスしなければならない。
4.2.2
ファイル識別記述子（File Identifier Descriptor）
Struct FileIdentifierDescriptor{
/* JIS X 0607 4/14.4 */
struct tag
DescriptorTag;
Uint16
FileVersionNumber;
Uint8
FileCharacteristics;
Uint8
LengthofFileIdentifier;
struct long̲ad ICB;
Uint16
LengthofImplementationUse;
byte
ImplementationUse[];
char
FileIdentifier[];
byte
Padding[];
}
4.2.2.1
ファイル識別子（char FileIdentifier[]）
ほとんどのOSは，正当なファイル識別子（FileIdentifier）の特性に関するそれ自体の規定があるので，
これは交換に伴う問題となる。そのため，全ての処理システムが，ファイル識別子翻訳の何らかの方式を
実行しなければならないので，全ての処理システムが同一アルゴリズムを使用すれば，それは利用者にと
って有益となる。
ファイル識別子翻訳の問題は，次に示すa)〜e) のうちの一つ以上に分類される。
a) 名前長（Name Length）：ほとんどのOSは，ファイル識別子の長さに，ある決まった制限がある。
79
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
b) 無効文字（Invalid Characters）：ほとんどのOSは，ファイル識別子名中に不当と考えられる文字があ
る。
c) 表示可能文字（Displayable Characters）：UDFがUnicode文字集合を利用可能にするので，ファイル識
別子中の文字が，受領システムで表示可能でないものを含むことがある。
d) 大文字と小文字との区別（Case Insensitive）：幾つかのOSは，ファイル識別子に関して大文字と小文
字との区別を行わない。例えば，OS/2はファイルを作成するとき，ファイル識別子の元の状態を記録
するが，ファイル識別子にアクセスしているとき，大文字と小文字との区別をしない操作を使用する。
OS/2では，“Abc”及び“ABC”は同一ファイル名とする。
e) 予約名（Reserved Names）：幾つかのOSには，ファイル識別子名に使用できない名前がある。
4.2.2.1.1〜4.2.2.1.7は，この規格で扱う各特定OSに対するファイル識別子の翻訳アルゴリズムを概説す
る。全てのOSTA UDF適合処理システムは，このアルゴリズムを使用しなければならない。このアルゴリ
ズムは，不当なファイル識別子を読み出した場合だけに適用する。媒体中の元のファイル識別子名は，変
更してはならない。このアルゴリズムは，OSのファイル識別子の制約に合致させるために，ファイル識
別子の翻訳方式を実行する処理システムに適用しなければならない。
全てのOSTA UDF適合処理システムは，UDFの翻訳アルゴリズムを利用可能としなければならないが，
追加のアルゴリズムを利用可能にしてもよい。複数のアルゴリズムを利用可能にする場合，処理システム
の利用者に，UDF翻訳アルゴリズムの選択方法を提供しなければならない。デフォルトの表示可能アルゴ
リズムは，UDFが定義するアルゴリズムであることを推奨する。
これらのアルゴリズムの主目的は，ファイルが属するディレクトリの全てを調べずに，固有のOSの制
約に適合する一意のファイル名を作成することである。
次に示すアルゴリズムのためのCのソースコードは，6.7に示す。
特記事項1 次のアルゴリズムの定義では，常に，d文字は引用符中に指定され，Unicodeの16進の
数値が指定される。さらに，このアルゴリズムは，CS0の16進表示を参照する。これは，
16進数で値を表すのにUnicodeの値#0030〜#0039及び#0041〜#0046を使用することに
相当する。さらに，次のアルゴリズムは，CS0のBase41表示を参照する。これは，16
〜40数字を表すのにUnicodeの値#0047〜#005A，#0023，#005F，#007E，#002D及び#0040
を使用するCS0の16進表示を増大させることに相当する。
次のアルゴリズムは，処理システムの利用者に名前の重複を報告する結果となることもある。その理由
としては，（可能ならば，ファイル名の変更によって）ディレクトリ中のどんなファイルも利用者がアクセ
スできるときに，ディレクトリの内容への効率的なアクセス，並びに，複数の論理ボリュームマウント間
及び複数のファイルシステムドライバ処理システム間の名前の翻訳の一貫性の必要性を含む。
この細分箇条での幾つかの名前の変換は，与えられたディレクトリですぐに認識できる二つの名前空間
をもたらす。与えられたディレクトリとは，物理的にディレクトリに記録される基本の名前の空間，及び
基本の名前から得られる生成された名前の空間のことである。この変換は，システム上のディレクトリの
名前空間の一部とは考えられない不法な名前（変換しなければ不法な名前になる名前）を合法なフォーム
にする変換とは異なる。このような変換を使用するUDF処理システムでは，当該処理システムは，二つの
処理でディレクトリを探すことが望ましい。処理1は基本名前空間に一致することが望ましく，処理2は
生成された名前空間に一致することが望ましい。基本名前空間での一致は，生成された名前空間に対する
一致よりも望ましい。
定義：ファイル識別子は，ファイル名及びファイル拡張子の二つの部分で構成しなければならない。
80
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
文字“.”（#002E）は，ファイルのファイル識別子に関する分離子としなければならない。最後の“.”
（#002E）に続く文字が5文字以下の場合，それはファイル拡張子を構成しなければならない。5文字を超
える場合，ファイル拡張子は存在してはならない。ファイル拡張子に先行して現れ，最後の“.”（#002E）
を除いた文字は，ファイル名を構成しなければならない。
特記事項2 たとえ，OS/2，Macintosh及びUNIXが，ファイル拡張子の概念を形式的にもたないとし
ても，1〜5文字の拡張子がその後に続く“.”でもってファイルを終えることが，共通の
ファイル命名規則である。そのため，次のアルゴリズムでは，ファイル拡張子は最大5
文字までとしている。
4.2.2.1.1
MS-DOS
MS-DOS OS環境が，ファイルに関連するファイル識別子に制約を強いるため，上に挙げたOS環境でフ
ァイル識別子を扱うために，次に示す方法を使用しなければならない。
例外：通常，この変換を使用することで二元的な名前空間（8.3形式及び非8.3形式）を提供するかもしれ
ない非MS-DOSシステムの実現は，その使用を無効にするためのメカニズムを省略してもよいし，
提供してもよい。
制約：ファイル識別子のファイル名要素は，8文字を超えてはならない。ファイル識別子のファイル拡張
子要素は，3文字を超えてはならない。
a) ファイル識別子（FileIdentifier）の照合：ファイル識別子の“照合”に対する要求に，大文字と小文字
との区別をしない比較を実行しなければならない。
b) ファイル識別子の有効性確認：ファイル識別子が有効なMS-DOSファイル識別子である場合，次の段
階は適用しない。
c) スペースの除去：識別子中の全ての埋込みスペースは，削除されなければならない。
d) 無効文字：（先に定義した）ファイル名中の無効文字，ファイル拡張子中の無効文字，又は現状の環境
で表示不可能な文字を含むファイル識別子は，これらを“̲”（#005F）に翻訳しなければならない（媒
体中のファイル識別子は，変更しない。）。複数の連続する無効文字，又は表示不可能な文字は，1文
字の“̲”（#005F）に翻訳しなければならない。無効文字は6.7に示すCソースコードを参照。
e) 先行終止符：最初の“.”（#002E）文字の前に文字が存在しない場合，このヒューリスティックなアプ
リケーションでは，先行する“.”（#002E）を，最初の“.”（#002E）でない文字まで無視しなければ
ならない。
f)
複数終止符：複数の“.”（#002E）文字を含むファイル識別子の場合，最後の“.”（#002E）に続く全
ての文字が5文字以下の場合，ファイル拡張子を構成しなければならない。ファイル拡張子の前の最
後の“.”（#002E）を除く文字はファイル名を構成しなければならない。ファイル名中の“.”（#002E）
文字は，削除しなければならない。
g) 長拡張子：この処理のこの段階で，ファイル拡張子を構成する文字数が3を超える場合，このファイ
ル拡張子は，この処理のこの段階でのファイル拡張子を構成している文字の中の先頭の3文字で構成
するとみなさなければならない。
h) 長ファイル名：この処理のこの段階で，ファイル名を構成する文字数が8を超える場合，ファイル名
は4文字に切り縮めなければならない。
i)
ファイル識別子CRC：前述の処理によって，元のファイル識別子の文字情報が失われているので，同
一ディレクトリ中で重複ファイル識別子を作成する機会が増す。重複ファイル識別子をもつ機会を大
きく減らすために，ファイル名を元ファイル識別子のCRCを含むように変更しなければならない。フ
81
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ァイル名は，この処理のこの段階でファイル名を構成する4文字を先頭として，これに分離子“#”
（#0023）を続け，元のファイル名のUNICODE伸張の16ビットCRCをCS0 のBase41表示した3
数字を続けて構成しなければならない。
j)
新しいファイル識別子は，全て大文字に翻訳しなければならない。
4.2.2.1.2
OS/2
OS/2 OS環境が，ファイルに関連するファイル識別子に制約を強いるため，前述のOS環境でファイル
識別子を扱うために，次に示す方法を使用しなければならない。
a) ファイル識別子（FileIdentifier）の照合：ファイル識別子の“照合”に対する要求に，大文字と小文字
との区別をする比較を実行してもよい。大文字と小文字との区別をする比較が行われなかったり，失
敗した場合，大文字と小文字との区別をしない比較を実行しなければならない。
b) ファイル識別子の有効性確認：ファイル識別子が有効なOS/2ファイル識別子である場合，次の段階
は適用しない。
c) 無効文字：OS/2のファイル名として無効な文字，又は現状の環境で表示不可能な文字を含むファイル
識別子は，これらを“̲”（#005F）に翻訳しなければならない。複数の連続する無効文字又は表示不
可能な文字は，1文字の“̲”（#005F）に翻訳しなければならない。無効文字は6.7に示すCソースコ
ードを参照。
d) 末尾の終止符及びスペース：全ての末尾の“.”（#002E）及び“ ”（#0020）は削除しなければならな
い。
e) ファイル識別子CRC：前述の処理によって，元のファイル識別子の文字情報が失われるので，同一デ
ィレクトリ中で重複ファイル識別子を作成する機会が増す。重複ファイル識別子をもつ機会を大きく
減らすために，ファイル名を元のファイル識別子のCRCを含むように変更しなければならない。
ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先
頭の文字数から成らなければならず，その個数は次による。
254−（新ファイル拡張子の長さ＋1）−5
ここに，
1： “.”用
5： #CRC用
これに分離子“#”（#0023）が続き，元のCS0ファイル識別子の16ビットCRCをCS0の16進表示した
4数字を続けて，更に“.”（#002E）及びこの処理のこの段階でのファイル拡張子を続けて構成しなければ
ならない。
ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先
頭の［254−（#CRC用の）5］個の文字から成る。これに分離子“#”（#0023）を続け，元のCS0ファイル
識別子の16ビットCRCをCS0の16進表示した4数字を続けて構成する。
4.2.2.1.3
Macintosh OS 9以前
Macintosh OS 9以前の環境が，ファイルに関連するファイル識別子に制約を強いているため，前述のOS
環境でファイル識別子を扱うために，次に示す方法を使用しなければならない。
a) ファイル識別子（FileIdentifier）の照合：ファイル識別子の“照合”に対する要求に，大文字と小文字
との区別をする比較を実行してもよい。大文字と小文字との区別をする比較が行われなかったり，失
敗した場合，大文字と小文字との区別をしない比較を実行しなければならない。
b) ファイル識別子の有効性確認：ファイル識別子が有効なMacintosh OS 9以前のファイル識別子である
場合，次の段階を適用しない。
82
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
c) 無効文字：Macintosh OS 9以前のファイル名として無効な文字，又は現状の環境で表示不可能な文字
を含むファイル識別子は，これらを“̲”（#005F）に翻訳しなければならない。複数の連続する無効
文字又は表示不可能文字は，1文字の“̲”（#005F）に翻訳しなければならない。無効文字は6.7に示
すCソースコードを参照。
d) 長ファイル識別子：この処理のこの段階で，ファイル識別子を構成する文字数が31個（Macintosh OS
9以前での名前の最大長）より大きい場合，この処理のこの段階で，新しいファイル識別子はファイ
ル識別子の先頭26文字で構成する。
e) ファイル識別子CRC：前述の処理によって，元のファイル識別子の文字情報が失われているので，同
一ディレクトリ中で重複ファイル識別子を作成する機会が増す。重複ファイル識別子をもつ機会を大
きく減らすために，ファイル名を元のファイル識別子のCRCを含むように変更しなければならない。
ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先
頭の文字数から成らなければならず，その個数は次による。
31−（新ファイル拡張子の長さ＋1）−5
ここに，
1： “.”用
5： #CRC用
これに分離子“#”（#0023）が続き，元のCS0ファイル識別子の16ビットCRCをCS0の16進表示した
4数字を続けて，更に“.”（#002E）及びこの処理のこの段階でのファイル拡張子を続けて構成しなければ
ならない。
ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先
頭の［31−5（#CRC用）］個の文字から成る。これに分離子“#”（#0023）を続け，元のCS0ファイル識別
子の16ビットCRCをCS0の16進表示した4数字を続けて構成しなければならない。
4.2.2.1.4
Windows 95及びWindows NT
Windows 95及びWindows NT OS環境が，ファイルに関連するファイル識別子に制約を強いるため，前
述のOS環境でファイル識別子を扱うために，次に示す方法を使用しなければならない。
a) ファイル識別子（FileIdentifier）の照合：ファイル識別子の“照合”に対する要求に，大文字と小文字
との区別をする比較を実行してもよい。大文字と小文字との区別をする比較が行われなかったり，失
敗した場合，大文字と小文字との区別をしない比較を実行しなければならない。
b) ファイル識別子の有効性確認：ファイル識別子が有効なWindows 95又はWindows NTファイル識別子
である場合，下の段階を適用しない。
c) 無効文字：Windows 95又はWindows NTのファイル名として無効な文字，又は現状の環境で表示可能
でない文字を含むファイル識別子は，これらを“̲”（#005F）に翻訳しなければならない。複数の連
続する無効文字又は表示不可能な文字は，1文字の“̲”（#005F）に翻訳しなければならない。無効文
字は6.7に示すCソースコードを参照。
d) 末尾の終止符及びスペース：全ての末尾の“.”（#002E）及び“ ”（#0020）は削除しなければならな
い。
e) ファイル識別子CRC：前述の処理によって，元のファイル識別子の文字情報が失われているので，同
一ディレクトリ中で重複ファイル識別子を作成する機会が増す。重複ファイル識別子をもつ機会を大
きく減らすために，ファイル名を元のファイル識別子のCRCを含むように変更しなければならない。
ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先
頭の文字数から成らなければならず，その個数は次による。
83
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
255−（新ファイル拡張子の長さ＋1）−5
ここに，
1： “.”用
5： #CRC用
これに分離子“#”（#0023）が続き，元のCS0ファイル識別子の16ビットCRCのCS0の16進表示した
4数字を続けて，更に“.”（#002E）及びこの処理のこの段階でのファイル拡張子を続けて構成しなければ
ならない。
ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する最
初の［255−5（#CRC用）］個の文字から成らなければならない。これに分離子“#”（#0023）を続け，元
のCS0ファイル識別子の16ビットCRCをCS0の16進表示した4数字を続けて構成する。
4.2.2.1.5
UNIX
UNIX OS環境による制約のため，ファイルに関連するファイル識別子に関して，前述のOS環境でファ
イル識別子を扱うために，次の方法を採用しなければならない。
a) ファイル識別子（FileIdentifier）の照合：ファイル識別子の“照合”に対する要求に，大文字と小文字
との区別をする比較を実行しなければならない。
b) 有効ファイル識別子：ファイル識別子が，現在のシステム環境に有効なUNIXファイル識別子である
場合，次の段階には適応しない。
c) 無効ファイル識別子：現在のシステム環境に関して，UNIXファイル名内で無効と考えられる文字，
又は，現在の環境で表示できないと考えられる文字を含むファイル識別子は，それらを“̲”（#005F）
に変換しなければならない。複数の連続無効文字又は表示不能文字は，1文字の“̲”（#005F）に変換
しなければならない。無効文字の完全リストについては6.7に示すCソースコードを参照。
d) 長ファイル識別子：この処理のこの段階でファイル識別子を構成する文字数が最大名前長（特定の
UNIXOSの最大名前長）より大きい場合，新しいファイル識別子は，この処理のこの段階のファイル
識別子の，最初の5文字の最大名前長から成る。
e) ファイル識別子CRC：前述の手順によって，元のファイル識別子の文字情報が失われるので，同一の
ディレクトリに，重複ファイル識別子を作成する機会が増える。重複ファイル識別子を作成する機会
を大幅に減らすためには，元のファイル識別子のCRCを含むように，ファイル名を変更しなければな
らない。
ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先
頭の文字数から成らなければならず，その個数は次による。
最大名前長−（新しいファイル拡張子長＋1）−5
ここに，
1： “.”用
5： #CRC用
これに分離子“#”（#0023）を続け，元のCS0ファイル識別子の16ビットCRCのCS0の16進表示した
4数字を続け，更に“.”及びこの処理のこの段階でのファイル拡張子を続けて構成しなければならない。
ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する，
先頭［最大名前長−5（#CRC用）］の数文字で構成しなければならない。これに，分離子“#”（#0023）が
続き，元のCS0ファイル識別子の16ビットのCRCをCS0の16進表示した4数字が続く。
4.2.2.1.6
OS/400
OS/400 OS環境が，ファイルに関連するファイル識別子に制約を強いているため，前述のOS環境でフ
ァイル識別子を扱うために，次に示す方法を使用しなければならない。
84
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
a) ファイル識別子（FileIdentifier）の照合：ファイル識別子の“照合”に対する要求に，大文字と小文字
との区別をする比較を実行してもよい。大文字と小文字との区別をする比較が行われなかったり，失
敗した場合，大文字と小文字との区別をしない比較を実行しなければならない。
b) ファイル識別子の有効性確認：ファイル識別子が有効なOS/400ファイル識別子である場合，次の段
階を適用しない。
c) 無効文字：OS/400ファイル名として無効な文字，又は現状の環境で表示不可能な文字を含むファイル
識別子は，これらを“̲”（#005F）に翻訳しなければならない。複数の連続する無効文字又は表示不
可能文字は，1文字の“̲”（#005F）に翻訳しなければならない。
d) 末尾のスペース：全ての末尾の“.”（#002E）は削除しなければならない。
e) ファイル識別子CRC：前述の処理によって，元のファイル識別子の文字情報が失われるので，同一デ
ィレクトリ中で重複ファイル識別子を作成する機会が増す。重複ファイル識別子をもつ機会を大きく
減らすために，ファイル名を元のファイル識別子のCRCを含むように変更しなければならない。
ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先
頭の文字数から成らなければならず，その個数は次による。
255−（新ファイル拡張子の長さ＋1）−5
ここに，
1： “.”用
5： #CRC用
これに分離子“#”（#0023）が続き，元のCS0ファイル識別子の16ビットCRCをCS0の16進表示した
4数字を続けて，更に“.”（#002E）及びこの処理のこの段階でのファイル拡張子を続けて構成しなければ
ならない。
ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先
頭の［255−（#CRC用の）5］個の文字から成る。これに分離子“#”（#0023）を続け，元のCS0ファイル
識別子の16ビットCRCをCS0の16進表示した4数字を続けて構成する。
特記事項 OS/400の無効文字は，“/”（#002F）だけである。OS/400の表示不可能な文字は，EBCDIC
Multilingualの500ページのコードに翻訳しない文字である。
4.2.2.1.7
Macintosh OS X
Mac OS X環境による制約のため，ファイル又はディレクトリに関連するファイル識別子に関して，前
述のOS環境でファイル識別子を扱うために，次の方法を採用しなければならない。
a) ファイル識別子（FileIdentifier）の照合：ファイル識別子の“照合”に対する要求に，大文字と小文字
との区別をする比較を実行しなければならない。大文字と小文字との区別をする比較が失敗した場合
は，大文字と小文字との区別をしない比較を実行してもよい。
b) 有効ファイル識別子：ファイル識別子が，現在のシステムインタフェースに有効なMac OS Xファイ
ル識別子である場合，c)以降の段階は適応しない。
c) 無効ファイル識別子：現在のシステム環境に関して，Mac OS Xファイル名内で無効と考えられる文
字，又は，現在の環境で表示できないと考えられる文字を含むファイル識別子は，それらを“̲”
（#005F）に変換しなければならない。複数の連続無効文字又は表示不能文字は，1文字の“̲”（#005F）
に変換しなければならない。無効文字の完全リストについては6.7.2に示すCソースコードを参照。
d) 長ファイル識別子：この処理のこの段階でファイル識別子が現在のシステムインタフェースの制限に
適合しない場合，新しいファイル識別子は，この処理のこの段階のファイル識別子の，最初のN文字
から成るものとし，ここでNはファイル識別子の最初のN文字に5文字（CRCの長さ）を足したも
85
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ので現在のシステムインタフェースに適合する最大の可能な値とする。
e) ファイル識別子CRC：前述の手順によって，元のファイル識別子の文字情報が失われるので，同一の
ディレクトリに，重複ファイル識別子を作成する機会が増える。重複ファイル識別子を作成する機会
を大幅に減らすためには，元のファイル識別子のCRCを含むように，ファイル名を変更しなければな
らない。
CRCは5文字である。分離子“#”（#0023）で始まり，元のCS0ファイル識別子の16ビットCRCのCS0
の16進表示した4数字が続く。
ファイル拡張子がある場合，新しいファイル識別子は，次のように変換される。
［手順c)の直後に得られたファイル識別子からファイル拡張子を除いたものの最初のN文字及びファイ
ル拡張子の前の“.”］“#”（4文字のCRC）“.”（ファイル拡張子）
そうでなければ，ファイル拡張子がない場合，新しいファイル識別子は，次のように変換される。
［手順c)の直後に得られたファイル識別子の最初のN文字］“#”（4文字のCRC）
いずれの場合もNは変換されたファイル識別子が現在のシステムインタフェースに適合する可能な最大
の値とする。
5
参考情報
5.1
記述子長
表41は，JIS X 0607規格類に記載する記述子の長さに対するUDF制限を要約する。
表41−JIS X 0607規格類に規定する記述子の長さに対するUDF制限
記述子
長さ
開始ボリューム記述子ポインタ（Anchor Volume Descriptor Pointer）
512
ボリューム記述子ポインタ（Volume Descriptor Pointer）
512
処理システム用ボリューム記述子（Implementation Use Volume Descriptor）
512
基本ボリューム記述子（Primary Volume Descriptor）
512
区画記述子（Partition Descriptor）
512
論理ボリューム記述子（Logical Volume Descriptor）
最大値なし
未割付け空間記述子（Unallocated Space Descriptor）
最大値なし
終端記述子（Terminating Descriptor）
512
論理ボリューム保全記述子（Logical Volume Intrgrity Descriptor）
最大値なし
ファイル集合記述子（File Set Descriptor）
512
ファイル識別記述子（File Identifier Descriptor）
論理ブロック長
割付けエクステント記述子（Allocation Extent Descriptor）
24
間接エントリ（Indirect Entry）
52
終端エントリ（Terminal Entry）
36
ファイルエントリ（File Entry）
論理ブロック長
拡張ファイルエントリ（Extended File Entry）
論理ブロック長
拡張属性ヘッダ記述子（Extended Attribute Header Descriptor）
24
未割付け空間エントリ（Unallocated Space Entry）
論理ブロック長
空間ビットマップ記述子（Space Bitmap Descriptor）
最大値なし
区画保全エントリ（Partition Integrity Entry）
N/A
予備表（Sparing Table）
最大値なし
N/A：規定しない
86
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5.2
処理システム用領域の使用
5.2.1
実体識別子（Entity Identifiers）
実体識別子は，この規格のはじめに定義する実体識別子に関する2.1.5を参照。
5.2.2
孤立空間（Orphan Space）
孤立空間が論理ボリューム中に存在してもよいが推奨はしない。それは，幾つかの論理ボリュームの修
理機能によって再割付けされる可能性があるためである。孤立空間は，JIS X 0607規格類で定義する処理
システム用記述子以外のいずれかの記述子で，直接又は間接に参照しない空間として定義する。
特記事項 処理システム用欄中だけに参照が存在する割付け済みのエクステントを孤立空間とみな
す。
5.3
起動記述子（Boot Descriptor）
将来，決定する。
5.4
未記録セクタの明確化（Clarification of Unrecorded Sectors）
[3/8.1.2.2]には，次のように記載されている。
“論理セクタを構成するどのような未記録構成セクタであっても全て#00バイトを含むものとして解釈
されなければならない。論理セクタの最後のバイトを含むセクタの中では，その最後のバイトの後のどの
ようなバイトの解釈も，この第3部によって規定されない。
記録の規格がセクタが未記録かどうかの検出方法を規定しており，論理セクタを構成するセクタの全て
が未記録の場合，論理セクタは未記録である。論理セクタの構成セクタは，全て記録されているか，又は
全て記録されていないことが望ましい（[3/8.1.2.2]参照）。”
交換の目的のために，UDFはこのセクションの正しい解釈を明確にしなければならない。
上記の部分は，未記録セクタは論理的に#00バイトを含むことを規定している。しかし，#00バイトだけ
を含むセクタが未記録であるという逆の主張は成立せず，そのようなセクタはJIS X 0607規格類において
は，“未記録”ではない。媒体におけるセクタの記録を支配する規格だけが，セクタが未記録であるか否か
を決定するための規則を提供できる。例えば，ブランクチェック状態は，追記形ディスクのための正しい
決定を提供できる。
JIS X 0607規格類[3/8.4.2]，[3/8.8.2]，[4/3.1]，[4/8.3.1]及び[4/8.10]は，[3/8.1.2.2]に定義された規則を参照
している。これによって，この規格の6.6（ICB方策種別4 096のアルゴリズム）も影響を受ける。未記録
のセクタ又はブロックは，記述子の列の終了条件である。したがって，処理システムは，使用されている
記録媒体が未記録セクタの検知可能性をもっていることを確認しなければならず，セクタに書き込まれて
いないことが検出可能であることを前提としてはならない。そうでない場合は，正しくない上記の逆の主
張を，結果として信用してしまうことがあり得る。適切な未記録セクタが検出されない場合には，明白な
終端記述子が使われなければならない。
87
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6
関連する規定
6.1
UDF実体識別記述子（表42参照）
表42−UDF実体識別記述子
実体識別子
記述
“*OSTA UDF Compliant”
論理ボリューム規定の内容，又はファイル集合の内容が，この規格で定義する適合範囲
であることを示す。
“*UDF LV Info”
付加的な論理ボリューム識別情報を含む。
“*UDF FreeEASpace”
処理システム用拡張属性空間中の未使用の空き空間を含む。
“*UDF FreeAppEASpace”
アプリケーション用拡張属性空間中に未使用の空き空間を含む。
“*UDF DVD CGMS Info”
DVD著作権管理情報を含む。
“*UDF OS/2 EALength”
OS/2拡張属性長を含む。
“*UDF Mac Volume Info”
Macintoshボリューム情報を含む。
“*UDF Mac FinderInfo”
Macintoshファインダ情報を含む。
“*UDF Virtual Partition”
UDF仮想区画を記載する。
“*UDF Sparable Partition”
UDF予備区画を記載する。
“*UDF OS/400 DirInfo”
OS/400拡張ディレクトリ情報
“*UDF Sparing Table”
媒体で欠陥領域を扱う情報を含む。
“*UDF Metadata Partition” UDFメタデータ区画を記載する。
6.2
UDF実体識別子値（表43参照）
表43−UDF実体識別子値
実体識別子
バイト値
“*OSTA UDF Compliant”
#2A, #4F, #53, #54, #41, #20, #55, #44, #46, #20, #43, #6F, #6D, #70, #6C, #69, #61, #6E, #74
“*UDF LV Info”
#2A, #55, #44, #46, #20, #4C, #56, #20, #49, #6E, #66, #6F
“*UDF FreeEASpace”
#2A, #55, #44, #46, #20, #46, #72, #65, #65, #45, #41, #53, #70, #61, #63, #65
“*UDF FreeAppEASpace”
#2A, #55, #44, #46, #20, #46, #72, #65, #65, #41, #70, #70, #45, #41, #53, #70, #61, #63, #65
“*UDF DVD CGMS Info”
#2A, #55, #44, #46, #20, #44, #56, #44, #20, #43,#47, #4D, #53, #20, #49, #6E, #66, #6F
“*UDF OS/2 EALength”
#2A, #55, #44, #46, #20, #4F, #53, #2F, #32, #20, #45, #41, #4C, #65, #6E, #67, #74, #68
“*UDF OS/400 DirInfo”
#2A, #55, #44, #46, #20, #4F, #53, #2F, #34, #30, #30, #20, #44, #69, #72, #49, #6E, #66, #6F
“*UDF Mac VolumeInfo”
#2A, #55, #44, #46, #20, #4D, #61, #63, #20, #56, #6F, #6C, #75, #6D, #65, #49, #6E, #66, #6F
“*UDF Mac FinderInfo”
#2A, #55, #44, #46, #20, #4D, #61, #63, #20, #49, #69, #6E, #64, #65, #72, #49, #6E, #66, #6F
“*UDF Virtual Partition”
#2A, #55, #44, #46, #20, #56, #69, #72, #74, #75, #61, #6C, #20, #50, #61, #72, #74, #69, #74,
#69, #6F, #6E
“*UDF Sparable Partition”
#2A, #55, #44, #46, #20, #53, #70, #61, #72, #61, #62, #6C, #65, #20, #50, #61, #72, #74, #69,
#74, #69, #6F, #6E
“*UDF Sparing Table”
#2A, #55, #44, #46, #20, #53, #70, #61, #72, #69, #6E, #67, #20, #54, #61, #62, #6C, #65
“*UDF Metadata Partition” #2A, #55, #44, #46, #20, #4D, #65, #74, #61, #64, #61, #74, #61, #20, #50, #61, #72, #74, #69,
#74, #69, #6F, #6E
6.3
オペレーティングシステム識別子（OS識別子）
6.3では，実体識別子の識別子添字中のOSクラス欄及びOS識別子欄に対して現状許可する値を定義す
る。2.1.5.3参照。
OSクラス及びOS識別子に関する値の最新の表については，直近のUDF仕様を参照。OSTAのWebサ
イトには，ISV（Independent Software Vendor）達によってOSTAへ提供された必須の情報がある。対応団
体規格UDF 2.60の6.18参照。
88
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.3.1
OSクラス（OS Class）
OSクラス（OS Class）欄は，記述子を記録したOSのクラスを識別する。この欄の有効な値を表44に示
す。
表44−OSクラス欄の値
値
OSクラス
0
未定義（Undefined）
1
DOS
2
OS/2
3
Macintosh OS
4
UNIX
5
Windows 9x
6
Windows NT
7
OS/400
8
BeOS
9
Windows CE
10〜255
予約（Reserved）
6.3.2
OS識別子（OS Identifier）
OS識別子（OS Identifier）欄は，記述子を記録したOSを識別する。この欄の有効な値は，表45のとお
りである。
表45−OS識別子の値
OSクラス
OS識別子
識別されるOS
0
任意の値
未定義（Undefined）
1
0
DOS/Windows 3.x
2
0
OS/2
3
0
Macintosh OS 9以前
3
1
Macintosh OS X-generic（Cheetah，Puma，Jaguar，Panther，
Tiger，及び同じコードベースの以降の版を含む。）
4
0
UNIX-Generic
4
1
UNIX-IBM AIX
4
2
UNIX-SUN OS/Solaris
4
3
UNIX-HP/UX
4
4
UNIX-Silicon Graphics Irix
4
5
UNIX-Linux
4
6
UNIX-MKLinux
4
7
UNIX-FreeBSD
4
8
UNIX-NetBSD
5
0
Windows 9x-generic（Windows 98及びMEを含む。）
6
0
Windows NT-generic（Windows 2000，XP，Server 2003，及
び同じコードベースの以降の版を含む。）
7
0
OS/400
8
0
BeOS-generic
9
0
WindowsCE-generic
OSクラス及びOS識別子に関する値の最新の表については，OSTAに連絡し，UDF実体識別子ディレク
トリのコピーを要求する。このディレクトリには，必須情報をOSTAへ提供したISVらの処理システム識
89
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
別子も含まれる。
6.4
OSTA圧縮Unicodeの圧縮アルゴリズム
/*****************************************************************************
* OSTA compliant unicode compression, uncompression routines.
* Copyright 1995 Micro Design International, Inc,
* Written by Jason M. Rinn.
* Micro Design International gives permission for the free use of the
* following source code.
*/
#include <stddef.h>
/******************************************************************************
* The follwing two typedef's are to remove compiler dependancies.
* byte needs to be unsigned 8-bit, and unicode̲t needs to be
* unsigned 16-bits.
*/
typedef unsigned short unicode̲t;
typedef unsigned char byte;
/***********************************************************************************
* Takes an OSTA CS0 compressed unicode name, and converts
* it to unicode.
* The unicode output will be in the byte order
* that the local compiler uses for 16-bit values.
* NOTE: This routine only performs error checking on the compID.
* It is up to the user to ensure that the unicode buffer is large
* enough, and that the compressed unicode name is correct.
*
* RETURN VALUE
*
* The number of unicode characters which were uncompressed.
* A -1 is returned if the compression ID is invalid.
*/
int UncompressUnicode(
int numberOfBytes, /* (Input) number of bytes read from media. */
byte *UDFCompressed, /* (Input) bytes read from media. */
unicode̲t *unicode) /* (Output) uncompressed unicode characters. */
{
unsigned int compID;
int returnValue, unicodeIndex, byteIndex;
/* Use UDFCompressed to store courrent byte being read. */
compID=UDFCompressed[0];
/* First check for valid compID. */
if (compID !=8 && compID !=16)
{
returnValue =-1;
}
else
{
unicodeIndex =0;
byteIndex =1;
/* Loop through all the bytes. */
90
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
while (byteIndex < numberOfBytes)
{
if (compID ==16)
{
/*Move the first byte to the high bits the unicode char. */
unicode[unicodeIndex] = UDFCompressed[byteIndex++] <<8;
}
else
{
unicode[unicodeIndex]=0;
}
if (byteIndex < numberOfBytes)
{
/*Then the next byte to the low bits. */
unicode[unicodeIndex] |= UDFCompressed[byteIndex++];
}
unicodeIndex++;
}
returnValue = unicodeIndex;
}
return(returnValue);
}
/***************************************************************************
* DESCRIPTION:
* Takes a string of unicode wide characters and returns an OSTA CS0
* compressed unicode string. The unicode MUST be in the byte order of
* the compiler in order to obtain correct results. Returns an error
* if the commpression ID is invalid.
*
* NOTE: This routine assumes the implementation already knows, by
* the local environment, how many bits are appropriate and
* therefore does no checking to test if the input characters fit
* into that number of bits or not.
*
* RETURN VALUE
*
* The total number of bytes in the compressed OSTA CS0 string,
* including the compression ID.
* A -1 is returned if the compression ID is invarild.
*/
int CompressUnicode(
int numberOfChars, /* (Input) number of unicode characters. */
int compID, /* (Input) compression ID to be used. */
unicode̲t *unicode, /* (Input) unicode characters to compress. */
byte *UDFCompressed) /* (Output) compressed string, as bytes. */
{
int byteIndex, unicodeIndex;
if (compID != 8 && compID != 16)
{
byteIndex = -1; /* Unsupported compression ID ! */
}
else
{
/* place compression code in first byte. */
91
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
UDFCompressed[0] = compID;
byteIndex = 1;
unicodeIndex = 0;
while (unicodeIndex < numberOfChars)
{
if (compID == 16)
{
/* First, place the high bits of the char
* into the byte stream.
*/
UDFCompressed[byteIndex++] =
(unicode[unicodeIndex] & 0xFF00) >> 8;
}
/* Then place the low bits into the stream. */
UDFCompressed[byteIndex++] = unicode[unicodeIndex] & 0x00FF;
unicodeIndex++;
}
}
return(byteIndex);
}
6.5
CRC計算
次に示すCプログラムは，JIS X 0607規格類のタグ記述子に使用するCRC-CCITTチェックサムを計算
するために利用する。
なお，次に示すプログラムは，アルゴリズムを表現するものであって，標準のCでそのままコンパイル
できないことがある。
/*
* CRC 010041
*/
static unsigned short crc̲table[256] = {
0x0000,
0x1021, 0x2042,
0x3063,
0x4084,
0x50A5, 0x60C6, 0x70E7,
0x8108,
0x9129, 0xA14A,
0xB16B,
0xC18C,
0xD1AD, 0xE1CE, 0xF1EF,
0x1231,
0x0210, 0x3273,
0x2252,
0x52B5,
0x4294, 0x72F7, 0x62D6,
0x9339,
0x8318, 0xB37B,
0xA35A,
0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
0x2462,
0x3443, 0x0420,
0x1401,
0x64E6, 0x74C7, 0x44A4, 0x5485,
0xA56A,
0xB54B, 0x8528,
0x9509,
0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
0x3653,
0x2672, 0x1611,
0x0630,
0x76D7, 0x66F6, 0x5695, 0x46B4,
0xB75B,
0xA77A, 0x9719,
0x8738,
0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
0x48C4,
0x58E5, 0x6886,
0x78A7,
0x0840, 0x1861, 0x2802, 0x3823,
0xC9CC,
0xD9ED, 0xE98E,
0xF9AF,
0x8948, 0x9969, 0xA90A, 0xB92B,
0x5AF5,
0x4AD4, 0x7AB7,
0x6A96,
0x1A71, 0x0A50, 0x3A33, 0x2A12,
0xDBFD,
0xCBDC, 0xFBBF,
0xEB9E,
0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
0x6CA6,
0x7C87, 0x4CE4,
0x5CC5,
0x2C22, 0x3C03, 0x0C60, 0x1C41,
0xEDAE,
0xFD8F, 0xCDEC,
0xDDCD,
0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
0x7E97,
0x6EB6, 0x5ED5,
0x4EF4,
0x3E13, 0x2E32, 0x1E51, 0x0E70,
0xFF9F,
0xEFBE, 0xDFDD,
0xCFFC,
0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
0x9188,
0x81A9, 0xB1CA,
0xA1EB,
0xD10C, 0xC12D, 0xF14E, 0xE16F,
0x1080,
0x00A1, 0x30C2,
0x20E3,
0x5004, 0x4025, 0x7046, 0x6067,
0x83B9,
0x9398, 0xA3FB,
0xB3DA,
0xC33D, 0xD31C, 0xE37F, 0xF35E,
0x02B1,
0x1290, 0x22F3,
0x32D2,
0x4235, 0x5214, 0x6277, 0x7256,
0xB5EA,
0xA5CB, 0x95A8,
0x8589,
0xF56E, 0xE54F, 0xD52C, 0xC50D,
92
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
0x34E2,
0x24C3, 0x14A0,
0x0481,
0x7466, 0x6447, 0x5424, 0x4405,
0xA7DB,
0xB7FA, 0x8799,
0x97B8,
0xE75F, 0xF77E, 0xC71D, 0xD73C,
0x26D3,
0x36F2, 0x0691,
0x16B0,
0x6657, 0x7676, 0x4615, 0x5634,
0xD94C,
0xC96D, 0xF90E,
0xE92F,
0x99C8, 0x89E9, 0xB98A, 0xA9AB,
0x5844,
0x4865, 0x7806,
0x6827,
0x18C0, 0x08E1, 0x3882, 0x28A3,
0xCB7D,
0xDB5C, 0xEB3F,
0xFB1E,
0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
0x4A75,
0x5A54, 0x6A37,
0x7A16,
0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
0xFD2E,
0xED0F, 0xDD6C,
0xCD4D,
0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
0x7C26,
0x6C07, 0x5C64,
0x4C45,
0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
0xEF1F,
0xFF3E, 0xCF5D,
0xDF7C,
0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
0x6E17,
0x7E36, 0x4E55,
0x5E74,
0x2E93, 0x3EB2, 0x0ED1, 0x1EF0
};
unsigned short
cksum(s, n)
register unsigned char *s;
register int n;
{
register unsigned short crc=0;
while (n-- > 0)
crc = crc̲table[(crc>>8 ^ *s++) & 0xff] ^ (crc<<8);
return crc;
}
/* UNICODE Checksum */
unsigned short
unicode̲cksum(s, n)
register unsigned short *s;
register int n;
{
register unsigned short crc=0;
while (n-- > 0) {
/* Take high order byte first-corresponds to a big endian byte stream.*/
crc = crc̲table [(crc >>8 ^ (*s>>8) & 0xff] ^ (crc <<8);
crc = crc̲table [(crc >>8 ^ (*s++ & 0xff)) & 0xff] ^ (crc <<8);
}
return crc;
}
#ifdef MAIN
unsigned char bytes[] = { 0x70, 0x6A, 0x77};
main()
{
usigned short x;
x = cksum(bytes, sizeof bytes);
printf("checksum: calculated=%4.4x, correct=%4.4x\en", x, 0x3299);
exit(0);
}
#endif
先に挙げたCRC表は，次のプログラムで生成した。
#include <stdio.h>
93
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/*
* a.out 010041 for CRC-CCITT
*/
main(argc, argv)
int argc; char *argv[];
{
unsigned long crc, poly;
int n, i;
sscanf(argv[1], "%lo", &poly);
if(poly & 0xffff0000){
fprintf(stderr, "polynomial is too large\en");
exit(1);
}
printf("/*\en * CRC 0%o\en */\en", poly);
printf("static unsigned short crc̲table[256] = {\en");
for(n =0; n < 256; n++){
if(n % 8 ==0)
printf(" ");
crc = n <<8;
for(i = 0; i < 8; i++){
if(crc & 0x8000)
crc = (crc << 1) ^ poly;
else
crc <<= 1;
crc &= 0xFFFF;
}
if(n == 255)
printf("0x%04X ", crc);
else
printf("0x%04X, ", crc);
if(n % 8 == 7)
printf("\en");
}
printf("};\en");
exit(0);
}
これらの全てのCRC符号は，AT&T Bell研究所のDon P. Mitchell及びSoftware System GroupのNed W.
Rhodesが考案した。これは，既に文献“Design and Validation of Computer Protocols”（Prentice Hall, Englewood
Cliffs, NJ, 1991, Chapter 3, ISBN 0-13-539925-4）で公開されており，AT&Tが著作権をもっている。
AT&Tは，上記のソースコードの自由使用の許可を与えている。
6.6
ICB方策種別4 096のアルゴリズム
この細分箇条は，ICB階層を構成するための方策を記載する。ICB方策種別4 096のルートICB階層は，
1個の直接エントリ及び1個の間接エントリを含まなければならない。1個の直接エントリがあることを示
すために，ICBタグ欄の方策パラメタ欄中のUint16に値1を記録する。ICBタグ欄のエントリの最大個数
（MaximumNumberOfEntries）欄に値2を記録する。
間接エントリが，1個の直接エントリ及び1個の間接エントリをも含む他のICB番地を指定し，この間
接エントリは，同一種別の他のICB番地を指定しなければならない（図1を参照）。
94
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図1−ICB番地の規定
特記事項 この方策は，直接エントリの簡単なリンクリストのICB階層を構成する。
6.7
識別子翻訳アルゴリズム
次に示すサンプルソースコードの例は，この規格に記載するファイル識別子翻訳アルゴリズムを与えて
いる。
次に示す基本アルゴリズムは，ボリューム識別子（VolumeIdentifier），ボリューム集合識別子
（VolumeSetIdentifier），論理ボリューム識別子（LogicalVolume Identifier）及びファイル集合識別子（FileSet
Identifier）のOS固有の翻訳を扱うために利用してもよい。
6.7.1
DOSアルゴリズム（DOS Algorithm）
次に示すプログラムは，アルゴリズムを表現するものであって，標準のCでそのままコンパイルできな
いことがある。
/* OSTA UDF compliant file name translation routine for DOS and */
/* Windows short namespaces */
/* Define constants for namespace translation */
#define DOS̲NAME̲LEN 8
#define DOS̲EXT̲LEN 3
#define DOS̲LABEL̲LEN 11
#define DOS̲CRC̲LEN 4
#define DOS̲CRC̲MODULUS 41
/* Define standard types used in example code. */
typedef BOOLEAN int;
typedef short INT16;
typedef unsigned short UINT16;
typedef UINT16 UNICODE̲CHAR;
#define FALSE 0
#define TRUE 1
static char crcChar[] =
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ#̲~-@";
/* FUNCTION PROTOTYPES */
UNICODE̲CHAR UnicodeToUpper(UNICODE̲CHAR value);
BOOLEAN IsFileNameCharLegal(UNICODE̲CHAR value);
BOOLEAN IsVolumeLabelCharLegal(UNICODE̲CHAR value);
INT16 NativeCharLength(UNICODE̲CHAR value);
BOOLEAN IsDeviceName(UNICODE̲CHAR* name, UINT16 nameLen);
/***********************************************************************/
DE
IE
DE ：直接エントリ
IE ：間接エントリ
DE
IE
DE
IE
95
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/* UDFDOSName() */
/* Translate udfName to dosName using OSTA compliant algorithm. */
/* dosName must be a Unicode string buffer at least 12 characters */
/* in length. */
/***********************************************************************/
UINT16 UDFDOSName(UNICODE̲CHAR* dosName, UNICODE̲CHAR* udfName,
UINT16 udfNameLen)
{
INT16 index;
INT16 targetIndex;
INT16 crcIndex;
INT16 extLen;
INT16 nameLen;
INT16 charLen;
INT16 overlayBytes;
INT16 bytesLeft;
UNICODE̲CHAR current;
BOOLEAN needsCRC;
UNICODE̲CHAR ext[DOS̲EXT̲LEN];
needsCRC = FALSE;
/* Start at the end of the UDF file name and scan for a period */
/* ('.'). This will be where the DOS extension starts (if */
/* any). */
index = udfNameLen;
while (index-- > 0) {
if (udfName[index] == '.')
break;
}
if (index < 0) {
/* There name was scanned to the beginning of the buffer */
/* and no extension was found. */
extLen = 0;
nameLen = udfNameLen;
}
else {
/* A DOS extension was found, process it first. */
extLen = udfNameLen−index−1;
nameLen = index;
targetIndex = 0;
bytesLeft = DOS̲EXT̲LEN;
while (++index < udfNameLen && bytesLeft > 0) {
/* Get the current character and convert it to upper */
/* case. */
current = UnicodeToUpper(udfName[index]);
if (current == ' ') {
/* If a space is found, a CRC must be appended to */
/* the mangled file name. */
needsCRC = TRUE;
}
else {
/* Determine if this is a valid file name char and */
/* calculate its corresponding BCS character byte */
/* length (zero if the char is not legal or */
96
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/* undisplayable on this system). */
charLen = (IsFileNameCharLegal(current)) ?
NativeCharLength(current) : 0;
/* If the char is larger than the available space */
/* in the buffer, pretend it is undisplayable. */
if (charLen > bytesLeft)
charLen = 0;
if (charLen == 0) {
/* Undisplayable or illegal characters are */
/* substituted with an underscore ("̲"), and */
/* required a CRC code appended to the mangled */
/* file name. */
needsCRC = TRUE;
charLen = 1;
current = '̲';
/* Skip over any following undiplayable or */
/* illegal chars. */
while (index +1 <udfNameLen &&
(!IsFileNameCharLegal(udfName[index + 1]) ||
NativeCharLength(udfName[index + 1]) == 0))
index++;
}
/* Assign the resulting char to the next index in */
/* the extension buffer and determine how many BCS */
/* bytes are left. */
ext[targetIndex++] = current;
bytesLeft -= charLen;
}
}
/* Save the number of Unicode characters in the extension */
extLen = targetIndex;
/* If the extension was too large, or it was zero length */
/* (i.e. the name ended in a period), a CRC code must be */
/* appended to the mangled name. */
if (index < udfNameLen || extLen == 0)
needsCRC = TRUE;
}
/* Now process the actual file name. */
index = 0;
targetIndex = 0;
crcIndex = 0;
overlayBytes = -1;
bytesLeft = DOS̲NAME̲LEN;
while (index < nameLen && bytesLeft > 0) {
/* Get the current character and convert it to upper case. */
current = UnicodeToUpper(udfName[index]);
if (current ==' ' ||current == '.') {
/* Spaces and periods are just skipped, a CRC code */
/* must be added to the mangled file name. */
needsCRC = TRUE;
97
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
}
else {
/* Determine if this is a valid file name char and */
/* calculate its corresponding BCS character byte */
/* length (zero if the char is not legal or */
/* undisplayable on this system). */
charLen = (IsFileNameCharLegal(current)) ?
NativeCharLength(current) : 0;
/* If the char is larger than the available space in */
/* the buffer, pretend it is undisplayable. */
if (charLen > bytesLeft)
charLen = 0;
if (charLen == 0) {
/* Undisplayable or illegal characters are */
/* substituted with an underscore ("̲"), and */
/* required a CRC code appended to the mangled */
/* file name. */
needsCRC = TRUE;
charLen = 1;
current = '̲';
/* Skip over any following undiplayable or illegal */
/* chars. */
while (index +1 <nameLen &&
(!IsFileNameCharLegal(udfName[index + 1]) ||
NativeCharLength(udfName[index + 1]) == 0))
index++;
/* Terminate loop if at the end of the file name. */
if (index >= nameLen)
break;
}
/* Assign the resulting char to the next index in the */
/* file name buffer and determine how many BCS bytes */
/* are left. */
dosName[targetIndex++] = current;
bytesLeft -= charLen;
/* This figures out where the CRC code needs to start */
/* in the file name buffer. */
if (bytesLeft >= DOS̲CRC̲LEN) {
/* If there is enough space left, just tack it */
/* onto the end. */
crcIndex = targetIndex;
}
else {
/* If there is not enough space left, the CRC */
/* must overlay a character already in the file */
/* name buffer. Once this condition has been */
/* met, the value will not change. */
if (overlayBytes < 0) {
98
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/* Determine the index and save the length of */
/* the BCS character that is overlayed. It */
/* is possible that the CRC might overlay */
/* half of a two-byte BCS character depending */
/* upon how the character boundaries line up. */
overlayBytes = (bytesLeft + charLen > DOS̲CRC̲LEN)?1 :0;
crcIndex = targetIndex−1;
}
}
}
/* Advance to the next character. */
index++;
}
/* If the scan did not reach the end of the file name, or the */
/* length of the file name is zero, a CRC code is needed. */
if (index < nameLen || index == 0)
needsCRC = TRUE;
/* If the name has illegal characters or and extension, it */
/* is not a DOS device name. */
if (needsCRC == FALSE && extLen == 0) {
/* If this is the name of a DOS device, a CRC code should */
/* be appended to the file name. */
if (IsDeviceName(udfName, udfNameLen))
needsCRC = TRUE;
}
/* Append the CRC code to the file name, if needed. */
if (needsCRC) {
/* Get the CRC value for the original Unicode string */
UINT16 udfCRCValue = CalculateCRC(udfName, udfNameLen);
/* Determine the character index where the CRC should */
/* begin. */
targetIndex = crcIndex;
/* If the character being overlayed is a two-byte BCS */
/* character, replace the first byte with an underscore. */
if (overlayBytes > 0)
dosName[targetIndex++] = '̲';
/* Append the encoded CRC value with delimiter. */
dosName[targetIndex++] = '#';
dosName[targetIndex++] =
crcChar[udfCRCValue / (DOS̲CRC̲MODULUS * DOS̲CRC̲MODULUS)];
udfCRCValue %= DOS̲CRC̲MODULUS * DOS̲CRC̲MODULUS;
dosName[targetIndex++] =
crcChar[udfCRCValue / DOS̲CRC̲MODULUS];
udfCRCValue %= DOS̲CRC̲MODULUS;
dosName[targetIndex++] = crcChar[udfCRCValue];
}
/* Append the extension, if any. */
if (extLen > 0) {
99
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/* Tack on a period and each successive byte in the */
/* extension buffer. */
dosName[targetIndex++] = '.';
for (index = 0; index < extLen; index++)
dosName[targetIndex++] = ext[index];
}
/* Return the length of the resulting Unicode string. */
return (UINT16)targetIndex;
}
/*******************************************************************/
/* UDFDOSVolumeLabel() */
/* Translate udfLabel to dosLabel using OSTA compliant algorithm. */
/* dosLabel must be a Unicode string buffer at least 11 characters */
/* in length. */
/*******************************************************************/ UINT16
UDFDOSVolumeLabel(UNICODE̲CHAR* dosLabel, UNICODE̲CHAR*
udfLabel, UINT16 udfLabelLen)
{
INT16 index;
INT16 targetIndex;
INT16 crcIndex;
INT16 charLen;
INT16 overlayBytes;
INT16 bytesLeft;
UNICODE̲CHAR current;
BOOLEAN needsCRC;
needsCRC = FALSE;
/* Scan end of label to see if there are any trailing spaces. */
index = udfLabelLen;
while (index-- > 0) {
if (udfLabel[index] != ' ')
break;
}
/* If there are trailing spaces, adjust the length of the */
/* string to exclude them and indicate that a CRC code is */
/* needed. */
if (index +1 !=udfLabelLen) {
udfLabelLen = index + 1;
needsCRC = TRUE;
}
index = 0;
targetIndex = 0;
crcIndex = 0;
overlayBytes = -1;
bytesLeft = DOS̲LABEL̲LEN;
while (index < udfLabelLen && bytesLeft > 0) {
/* Get the current character and convert it to upper case. */
current = UnicodeToUpper(udfLabel[index]);
if (current == '.') {
/* Periods are just skipped, a CRC code must be added */
100
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/* to the mangled file name. */
needsCRC = TRUE;
}
else {
/* Determine if this is a valid file name char and */
/* calculate its corresponding BCS character byte */
/* length (zero if the char is not legal or */
/* undisplayable on this system). */
charLen = (IsVolumeLabelCharLegal(current)) ?
NativeCharLength(current) : 0;
/* If the char is larger than the available space in */
/* the buffer, pretend it is undisplayable. */
if (charLen > bytesLeft)
charLen = 0;
if (charLen == 0) {
/* Undisplayable or illegal characters are */
/* substituted with an underscore ("̲"), and */
/* required a CRC code appended to the mangled */
/* file name. */
needsCRC = TRUE;
charLen = 1;
current = '̲';
/* Skip over any following undiplayable or illegal */
/* chars. */
while (index +1 <udfLabelLen &&
(!IsVolumeLabelCharLegal(udfLabel[index + 1]) ||
NativeCharLength(udfLabel[index + 1]) == 0))
index++;
/* Terminate loop if at the end of the file name. */
if (index >= udfLabelLen)
break;
}
/* Assign the resulting char to the next index in the */
/* file name buffer and determine how many BCS bytes */
/* are left. */
dosLabel[targetIndex++] = current;
bytesLeft -= charLen;
/* This figures out where the CRC code needs to start */
/* in the file name buffer. */
if (bytesLeft >= DOS̲CRC̲LEN) {
/* If there is enough space left, just tack it */
/* onto the end. */
crcIndex = targetIndex;
}
else {
/* If there is not enough space left, the CRC */
/* must overlay a character already in the file */
/* name buffer. Once this condition has been */
/* met, the value will not change. */
if (overlayBytes < 0) {
/* Determine the index and save the length of */
/* the BCS character that is overlayed. It */
101
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/* is possible that the CRC might overlay */
/* half of a two-byte BCS character depending */
/* upon how the character boundaries line up. */
overlayBytes = (bytesLeft + charLen >
DOS̲CRC̲LEN)
?1 :0;
crcIndex = targetIndex−1;
}
}
}
/* Advance to the next character. */
index++;
}
/* If the scan did not reach the end of the file name, or the */
/* length of the file name is zero, a CRC code is needed. */
if (index < udfLabelLen || index == 0)
needsCRC = TRUE;
/* Append the CRC code to the file name, if needed. */
if (needsCRC) {
/* Get the CRC value for the original Unicode string */
UINT16 udfCRCValue = CalculateCRC(udfName, udfNameLen);
/* Determine the character index where the CRC should */
/* begin. */
targetIndex = crcIndex;
/* If the character being overlayed is a two-byte BCS */
/* character, replace the first byte with an underscore. */
if (overlayBytes > 0)
dosLabel[targetIndex++] = '̲';
/* Append the encoded CRC value with delimiter. */
dosLabel[targetIndex++] = '#';
dosLabel[targetIndex++] =
crcChar[udfCRCValue / (DOS̲CRC̲MODULUS * DOS̲CRC̲MODULUS)];
udfCRCValue %= DOS̲CRC̲MODULUS * DOS̲CRC̲MODULUS;
dosLabel[targetIndex++] =
crcChar[udfCRCValue / DOS̲CRC̲MODULUS];
udfCRCValue %= DOS̲CRC̲MODULUS;
dosLabel[targetIndex++] = crcChar[udfCRCValue];
}
/* Return the length of the resulting Unicode string. */
return (UINT16)targetIndex;
}
/*******************************************************************/
/* UnicodeToUpper() */
/* Convert the given character to upper-case Unicode. */
/*******************************************************************/
UNICODE̲CHAR UnicodeToUpper(UNICODE̲CHAR value)
{
102
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/* Actual implementation will vary to accommodate the target */
/* operating system API services. */
/* Just handle the ASCII range for the time being. */
return (value >= 'a' && value <= 'z') ?
value−('a'−'A') : value;
}
/*******************************************************************/
/* IsFileNameCharLegal() */
/* Determine if this is a legal file name id character. */
/*******************************************************************/
BOOLEAN IsFileNameCharLegal(UNICODE̲CHAR value)
{
/* Control characters are illegal. */
if (value <' ')
return FALSE;
/* Test for illegal ASCII characters. */
switch (value) {
case '\\':
case '/':
case ':':
case '*':
case '?':
case '\"':
case '<':
case '>':
case '|':
case ';':
case '^':
case ',':
case '&':
case '+':
case '=':
case '[':
case ']':
return FALSE;
default:
return TRUE;
}
}
/*******************************************************************/
/* IsVolumeLabelCharLegal() */
/* Determine if this is a legal volume label character. */
/*******************************************************************/
BOOLEAN IsVolumeLabelCharLegal(UNICODE̲CHAR value)
{
/* Control characters are illegal. */
if (value <' ')
return FALSE;
/* Test for illegal ASCII characters. */
switch (value) {
103
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
case '\\':
case '/':
case ':':
case '*':
case '?':
case '\"':
case '<':
case '>':
case '|':
case '.':
case ';':
case '^':
case ',':
case '&':
case '+':
case '=':
case '[':
case ']':
return FALSE;
default:
return TRUE;
}
}
/*******************************************************************/
/* NativeCharLength() */
/* Determines the corresponding native length (in bytes) of the */
/* given Unicode character. Returns zero if the character is */
/* undisplayable on the current system. */
/*******************************************************************/
INT16 NativeCharLength(UNICODE̲CHAR value)
{
/* Actual implementation will vary to accommodate the target */
/* operating system API services. */
/* This is an example of a conservative test. A better test */
/* will utilize the platformʼs language/codeset support to */
/* determine how wide this character is when converted to the */
/* active variable width character set. */
return 1;
}
/*******************************************************************/
/* IsDeviceName() */
/* Determine if the given Unicode string corresponds to a DOS */
/* device name (e.g. "LPT1", "COM4", etc.). Since the set of */
/* valid device names with vary from system to system, and */
/* a means for determining them might not be readily available, */
/* this functionality is only suggested as an optional */
/* implementation enhancement. */
/*******************************************************************/
BOOLEAN IsDeviceName(UNICODE̲CHAR* name, UINT16 nameLen)
{
/* Actual implementation will vary to accommodate the target */
/* operating system API services. */
104
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
/* Just return FALSE for the time being. */
return FALSE;
}
6.7.2
OS/2, Macintosh，Windows 95，Windows NT及びUNIXアルゴリズム（OS/2，Macintosh，Windows
95，Windows NT and UNIX Algorithm）
次に示すプログラムは，アルゴリズムを表現するものであって，標準のCでそのままコンパイルできな
いことがある。
/***********************************************************************
* OSTA UDF compliant file name translation routine for OS/2,
* Windows 95, Windows NT, Macintosh and UNIX.
* Copyright 1995 Micro Design International, Inc.
* Written by Jason M. Rinn.
* Micro Design International gives permission for the free use of the
* following source code.
***********************************************************************
*
* To use these routines with different operating systems.
*
* OS/2
* Define OS2
* Define MAXLEN = 254
*
* Windows 95
* Define WIN̲95
* Define MAXLEN = 255
*
* Windows NT
* Define WIN̲NT
* Define MAXLEN = 255
*
* Macintosh OS 9/older:
* Define MAC9.
* Define MAXLEN = 31.
*
* Macintosh OS X:
* Define MACOSX
* Define MAXLEN = 255
*
* UNIX
* Define UNIX.
* Define MAXLEN as specified by unix version.
*/
#define ILLEGAL̲CHAR̲MARK 0x005F
#define CRC̲MARK 0x0023
#define EXT̲SIZE 5
#define TRUE 1
#define FALSE 0
#define PERIOD 0x002E
#define SPACE 0x0020
/***********************************************************************
* The following two typedef's are to remove compiler dependancies.
105
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
* byte needs to be unsigned 8-bit, and unicode̲t needs to
* be unsigned 16-bit.
*/
typedef unsigned short unicode̲t;
typedef unsigned char byte;
/*** PROTOTYPES ***/
int IsIllegal(unicode̲t ch);
unsigned short unicode̲cksum(register unsigned short *s, register int n);
/* Define a function or macro which determines if a Unicode character is
* printable under your implementation.
*/
int UnicodeIsPrint(unicode̲t);
#ifdef MACOSX
size̲t GetMaxUnicodeLen(unicode̲t *name, /* the unicode name */
size̲t charcnt, /* number of unicode characters */
size̲t maxUtf8Len); /* maximum size of the utf-8 buffer in bytes */
/***********************************************************************
* this function returns the number of bytes required to encode
* bytecnt/2 unicode characters into the encoding required by the
* current system.
*
* For example, in Mac OS X 10.4 (Tiger), this is UTF-8 encoding
* normalized to NFD (decomposed) from.
*
* The implementation of this function is not included in this standard.
*/
size̲t UTF8EncodeLength(unicode̲t *str, size̲t bytecnt, int flag);
#endif
/***********************************************************************
* Translates a long file name to one using a MAXLEN and an illegal
* char set in accord with the OSTA requirements. Assumes the name has
* already been translated to Unicode.
*
* RETURN VALUE
*
* Number of unicode characters in translated name.
*/
int UDFTransName(
unicode̲t *newName,/*(Output)Translated name. Must be of length MAXLEN*/
unicode̲t *udfName, /* (Input) Name from UDF volume.*/
int udfLen) /* (Input) Length of UDF Name. */
{
int index, newIndex = 0, needsCRC = FALSE;
int extIndex = 0, newExtIndex = 0, hasExt = FALSE;
#if defined(OS2) || defined(WIN̲95) || defined(WIN̲NT)
int trailIndex = 0;
#endif
#ifdef MACOSX
int decomposedUtf8len = 0;
106
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
#endif
unsigned short valueCRC;
unicode̲t current;
const char hexChar[] = "0123456789ABCDEF";
for (index = 0; index < udfLen; index++)
{
current = udfName[index];
if (IsIllegal(current) || !UnicodeIsPrint(current))
{
needsCRC = TRUE;
/* Replace Illegal and non-displayable chars with underscore. */
current = ILLEGAL̲CHAR̲MARK;
/* Skip any other illegal or non-displayable characters. */
while(index+1 < udfLen && (IsIllegal(udfName[index+1])
|| !UnicodeIsPrint(udfName[index+1])))
{
index++;
}
}
/* Record position of extension, if one is found. */
if (current == PERIOD && (udfLen−index -1) <= EXT̲SIZE)
{
if (udfLen == index + 1)
{
/* A trailing period is NOT an extension. */
hasExt = FALSE;
}
else
{
hasExt = TRUE;
extIndex = index;
newExtIndex = newIndex;
}
}
#if defined(OS2) || defined(WIN̲95) || defined(WIN̲NT)
/* Record position of last char which is NOT period or space. */
else if (current != PERIOD && current != SPACE)
{
trailIndex = newIndex;
}
#endif
if (newIndex < MAXLEN)
{
newName[newIndex++] = current;
}
else
{
needsCRC = TRUE;
}
107
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
#ifdef MACOSX
decomposedUtf8len += UTF8EncodeLength(¤t, 2, UTF̲DECOMPOSED);
if (decomposedUtf8len >= MAXLEN)
needsCRC = TRUE;
#endif
}
#if defined(OS2) || defined(WIN̲95) || defined(WIN̲NT)
/* For OS2, 95 & NT, truncate any trailing periods and\or spaces. */
if (trailIndex != newIndex−1)
{
newIndex = trailIndex + 1;
needsCRC = TRUE;
hasExt = FALSE; /* Trailing period does not make an extension. */
}
#endif
if (needsCRC)
{
unicode̲t ext[EXT̲SIZE];
int localExtIndex = 0;
if (hasExt)
{
int maxFilenameLen;
/* Translate extension, and store it in ext. */
for(index = 0; index<EXT̲SIZE && extIndex + index +1 < udfLen;
index++)
{
current = udfName[extIndex + index + 1];
if (IsIllegal(current) || !UnicodeIsPrint(current))
{
/* Replace Illegal and non-displayable chars
* with underscore.
*/
current = ILLEGAL̲CHAR̲MARK;
/* Skip any other illegal or non-displayable
* characters.
*/
while(index + 1 < EXT̲SIZE
&& (IsIllegal(udfName[extIndex + index + 2])
|| !UnicodeIsPrint(udfName[extIndex + index + 2])))
{
index++;
}
}
ext[localExtIndex++] = current;
}
/* Truncate filename to leave room for extension and CRC. */
#ifdef MACOSX
maxFilenameLen = (MAXLEN−5) -
UTF8EncodeLength(ext, localExtIndex*2, UTF̲DECOMPOSED)−1;
newIndex = GetMaxUnicodeLen(newName, newExtIndex, maxFilenameLen);
#else
maxFilenameLen = ((MAXLEN−5)−localExtIndex−1);
108
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
if (newIndex > maxFilenameLen)
{
newIndex = maxFilenameLen;
}
else
{
newIndex = newExtIndex;
}
#endif
}
else if (newIndex > MAXLEN−5)
{
/*If no extension, make sure to leave room for CRC. */
#ifdef MACOSX
newIndex = GetMaxUnicodeLen(newName, newIndex, MAXLEN−5);
#else
newIndex = MAXLEN−5;
#endif
}
newName[newIndex++] = CRC̲MARK; /* Add mark for CRC. */
/*Calculate CRC from original filename from FileIdentifier. */
valueCRC = unicode̲cksum((unsigned short *)udfName, udfLen);
/* Convert 16-bits of CRC to hex characters. */
newName[newIndex++] = hexChar[(valueCRC & 0xf000) >> 12];
newName[newIndex++] = hexChar[(valueCRC & 0x0f00) >> 8];
newName[newIndex++] = hexChar[(valueCRC & 0x00f0) >> 4];
newName[newIndex++] = hexChar[(valueCRC & 0x000f)];
/* Place a translated extension at end, if found. */
if (hasExt)
{
newName[newIndex++] = PERIOD;
for (index = 0;index < localExtIndex ;index++)
{
newName[newIndex++] = ext[index];
}
}
}
return(newIndex);
}
#if defined(OS2) || defined(WIN̲95) || defined(WIN̲NT)
/***********************************************************************
* Decides if a Unicode character matches one of a list
* of ASCII characters.
* Used by OS2 version of IsIllegal for readability, since all of the
* illegal characters above 0x0020 are in the ASCII subset of Unicode.
* Works very similarly to the standard C function strchr().
*
* RETURN VALUE
*
* Non-zero if the Unicode character is in the given ASCII string.
*/
int UnicodeInString(
109
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
unsigned char *string, /* (Input) String to search through. */
unicode̲t ch) /* (Input) Unicode char to search for. */
{
int found = FALSE;
while (*string != '\0' && found == FALSE)
{
/* These types should compare, since both are unsigned numbers. */
if (*string == ch)
{
found = TRUE;
}
string++;
}
return(found);
}
#endif /* if defined(OS2) || defined(WIN̲95) || defined(WIN̲NT) */
/***********************************************************************
* Decides whether the given character is illegal for a given OS.
*
* RETURN VALUE
*
* Non-zero if char is illegal.
*/
int IsIllegal(unicode̲t ch)
{
#ifdef MAC9
/* Only illegal character on the Mac OS 9/older is the colon. */
if (ch == 0x003A)
{
return(1);
}
else
{
return(0);
}
#elif defined(UNIX) || defined(MACOSX)
/* Illegal UNIX and Mac OS X characters are NULL and slash. */
if (ch == 0x0000 || ch == 0x002F)
{
return(1);
}
else
{
return(0);
}
#elif defined(OS2) || defined(WIN̲95) || defined(WIN̲NT)
/* Illegal char's for OS/2 according to WARP toolkit. */
if (ch < 0x0020 || UnicodeInString("\\/:*?\"<>|", ch))
{
return(1);
}
else
{
return(0);
}
110
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
#endif
return 1; // should never reach here
}
#ifdef MACOSX
/***********************************************************************
* given the maximum size of the utf8 buffer, return the number of
* unicode characters that can fit in the utf8 buffer
*/
size̲t GetMaxUnicodeLen(
unicode̲t *name, /* the unicode name */
size̲t charcnt, /* number of unicode characters */
size̲t maxUtf8Len) /* maximum size of the utf-8 buffer in bytes */
{
size̲t len, i;
len = 0;
for (i=0; i<charcnt; i++)
{
len += UTF8EncodeLength(name++, 2, UTF̲DECOMPOSED);
if (len > maxUtf8Len)
break;
}
return i;
}
int UnicodeIsPrint(unicode̲t ch)
{
return 1;
}
#endif
6.8
拡張属性ヘッダチェックサムアルゴリズム（Extended Attribute Header Checksum Algorithm）
次に示すプログラムは，アルゴリズムを表現するものであって，標準のCでそのままコンパイルできな
いことがある。
/*
* Calculates a 16-bit checksum of the Implementation Use
* Extended Attribute header or Application Use Extended Attribute
* header. The fields AttributeType through ImplementationIdentifier
* (or ApplicationIdentifier) inclusively represent the
* data covered by the checksum (48 bytes).
*
*/
Uint16 ComputeEAChecksum(byte *data)
{
Uint16 checksum = 0;
Uint count;
for(count =0; count < 48; count++)
{
checksum += *data++;
}
return(checksum);
111
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
}
6.9
DVD-ROMに関する要件
この細分箇条は，ユニバーサルディスクフォーマット（UDFS）のDVD-ROMディスクに対する要件及
び制約を定義する。
a) DVD-ROMディスクは，UDFファイルシステムで作成しなければならない。
b) DVD-ROMディスクは，単一ボリューム及び単一区画から成らなければならない。
特記事項 ディスクは，JIS X 0606ファイルシステムも含んでよい。ディスクがUDFファイルシステ
ム及びJIS X 0606ファイルシステムの両方を含むとき，UDFブリッジディスクとしなけれ
ばならない。UDFブリッジディスクは，JIS X 0606だけを利用可能なコンピュータで直接
DVD-ROM媒体を再生することを可能にする。UDFコンピュータ処理システムの提供によ
って，JIS X 0606の必要性はなくなり，将来のディスクはUDFだけを含むことが望ましい。
6.9.1
DVD-Videoに関するUDFの制約（Constraints imposed by UDF for DVD-Video）
この6.9.1は，専用DVDプレーヤのためのUDFで初期化したDVD-Videoディスクに対する制限及び要
件を記載する。DVD-Videoは，家電市場向けにUDFを使用するDVD-ROMの一つの専用アプリケーショ
ンである。DVDプレーヤ中では，コンピュータ資源が限られているのでDVDプレーヤがUDF定義の全
ての機能を利用可能にしなくともよいように制限及び要件を作成した。
全てのDVD-Videoディスクは，JIS X 0607規格類（追補を含まない。）及びUDFの規定に従って，全て
の必要なデータを含むように作成しなければならない。これによって，DVD-Videoをコンピュータシステ
ムで再生することが可能になる。そのデータの例は，日時及び許可条件のビット並びに使用可能空間表（使
用可能な空間がないことを示す。）を含む。DVDプレーヤの処理システムは，これらの欄を無視してもよ
いが，UDFコンピュータの処理システムがこれらを無視することはしない。娯楽用の内容及びコンピュー
タ用の内容が，同一のディスクに共存できる。
特記事項 UDF 1.02以外の版に従って作成されたDVD-VideoディスクはDVD-Videoプレーヤと互換
性がない。DVD-Videoプレーヤは，UDF 1.02フォーマットの媒体であることを前提にして
いる。
符号量の削減及び効率の向上を意図して，全ての除算は整数で記載し，全ての除数は2のn乗でなけれ
ばならない。その結果，全ての除算は論理シフト演算で行ってよい。
a) DVDプレーヤは，UDFだけを利用可能とし，JIS X 0606は利用可能としてはならない。
b) 作成システムは，各ファイルの長さを（230−論理ブロック長）バイト以下としなければならない。
c) 各ファイルのデータは，単一エクステントに記録する。各ファイルエントリは，ICB方策種別4を用
いて記録しなければならない。
d) ファイル名及びディレクトリ名は，OSTA圧縮Unicode形式で，1文字当たり8ビットに圧縮しなけれ
ばならない。
e) DVDプレーヤは，どんなファイルに対するシンボリックリンクにも従ってはならない。
f)
DVD-Videoファイルは，ルートディレクトリの下の“VIDEO̲TS”という名前のサブディレクトリに
記録しなければならない。ディレクトリ名は，文献“DVD Specifications for Read-Only Disc”において
標準化されている。
特記事項 DVD Specification for Read-Only Discは，DVDフォーマット ロゴ ライセンシング株式会
社が出版する規定であり，媒体上に記録するDVD-Videoファイルの名前及びDVD-Video
112
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ディレクトリの名前を記載している。さらに，DVD-Videoファイルの内容についても記載
している。6.9.3参照。
g) VIDEO̲TSサブディレクトリにおいて“VIDEO̲TS.IFO”と名付けられたファイルを最初に読み出さ
なければならない。
これら全ての制約は，DVDプレーヤがアクセスする必要があるディレクトリ及びファイルだけに適用す
る。媒体中にはDVDプレーヤ向けではなく，これらの制約に適合しない，他のファイル及びディレクト
リが存在してもよい。これらの他のファイル及びディレクトリを，DVDプレーヤは無視する。これによっ
て，同一ディスク上に娯楽用の内容及びコンピュータ用の内容の両方をもつことができる。
6.9.2
UDFディスクの読出し法（How to read a UDF DVD-Video disc）
この6.9.2は，DVDプレーヤが，UDFで初期化したDVD-Videoディスクを読み出すために実行する基
本的な手続きを記載する。
6.9.2.1
手順1 ボリューム認識列（Volume Recognition Sequence）
論理セクタ16から開始しなければならないボリューム認識列中のJIS X 0607の記述子を見つける。
6.9.2.2
手順2 開始ボリューム記述子ポインタ（Anchor Volume Descriptor Pointer）
開始位置の開始ボリューム記述子ポインタを見つけなければならない。二つの開始位置は，論理セクタ
256及び論理セクタNに記録されなければならない。ここで，Nはディスクの論理セクタに番号付けした
最大数とする。
DVDプレーヤは，論理セクタ256だけを見ればよい。論理セクタNのコピーは冗長であり，欠陥対応
のためだけに必要とする。開始ボリューム記述子ポインタは，次の3項目を含む。
a) ディスクの識別及び保全検証のために使用してもよい静的構造
b) 主ボリューム記述子列の位置（絶対論理セクタ番号）
c) 主ボリューム記述子列の長さ（バイト）
開始ボリューム記述子ポインタのバイト0〜3及び5にあるデータは，必要に応じて初期化検証に使用し
てもよい。バイト4のタグチェックサム及びバイト8〜11の記述子CRCの検証は，実行すべき適切な追加
検証である。MVDS̲Location及びMVDS̲Lengthを，この構造から読み出す。
6.9.2.3
手順3 ボリューム記述子列（Volume Descriptor Sequence）
次の論理セクタを読み出す。
MVDS̲Location 〜 MVDS̲Location ＋（MVDS̲Length−1）／セクタ長
論理セクタ長は，DVD媒体では2 048バイトでなければならない。この列が読み出せない場合，予備ボ
リューム記述子列を読み出すことが望ましい。
区画記述子は，値5のタグ識別子をもつ記述子でなければならない。区画番号及び論理セクタ番号によ
る区画位置が記録されなければならない。
この構造から，Partition̲Location及びPartition̲Lengthを得る。
論理ボリューム記述子は，値6のタグ識別子をもつ記述子でなければならない。ファイル集合記述子の
位置及び長さが論理ブロック番号で記録されなければならない。
この構造から，FSD̲Location及びFSD̲Lengthを得る。
6.9.2.4
手順4 ファイル集合記述子列（File Set Descriptor）
ファイル集合記述子は，次に示す論理セクタ番号の論理セクタに存在する。
Partition̲Location＋FSD̲Location 〜
Partition̲Location＋FSD̲Location ＋（FSD̲Length−1）／ブロック長
113
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
RootDir̲Location及びRootDir̲Lengthを，論理ブロック番号によってファイル集合記述子から読み出さ
なければならない。
6.9.2.5
手順5 ルートディレクトリのファイルエントリ（Root Directory File Entry）
RootDir̲Location及びRootDir̲Lengthは，ファイルエントリの位置を定義する。このファイルエントリ
は，ルートディレクトリのデータ空間及び許可条件を記載する。
ルートディレクトリの位置及び長さを得る。
6.9.2.6
手順6 ルートディレクトリ（Root Directory）
“VIDEO̲TS”サブディレクトリを見つけるために，ルートディレクトリエクステント中のデータを解
釈する。
VIDEO̲TSファイル識別子記述子を見つける。その名前は，8ビットの圧縮UDFフォーマットとしなけ
ればならない。VIDEO̲TSが，ディレクトリであることを検証する。
ファイル識別子記述子を読み出し，VIDEO̲TSディレクトリを記載するファイルエントリの位置及び長
さを得る。
6.9.2.7
手順7 VIDEO̲TSのファイルエントリ（File Entry of VIDEO̲TS）
前述の段階で見つけたファイルエントリは，VIDEO̲TSディレクトリのデータ空間及び許可条件を含む。
VIDEO̲TSディレクトリの位置及び長さを得る。
6.9.2.8
手順8 VIDEO̲TSディレクトリ（VIDEO̲TS Directory）
前述の段階で見つけたエクステントは，ファイル識別子記述子の集合を含む。このパスでは，エントリ
がファイルをポイントしており，かつ，VIDEO̲TS.IFOという名前をもつことを検証する。
6.9.2.9
手順9 VIDEO̲TS.IFOのファイルエントリ（File Entry of VIDEO̲TS.IFO）
前述の段階で見つけたファイルエントリは，VIDEO̲TS.IFOファイルのデータ空間及び許可条件を含む。
VIDEO̲TS.IFOファイルの位置及び長さを得る。
必要ならば，他のファイルは，VIDEO̲TS.IFOファイルと同じ方法で見つけることができる。
6.9.3
DVD関連文献の入手（Obtaining DVD Document）
文献“DVD Specifications for Read-Only Disc”及び他のDVD関連資料のコピーを入手するには，次に連
絡されたい。
DVD Format/Logo Licensing Corporation
Shiba Shimizu Bldg. 6F,
2-3-6 Shibadaimon, Minato-ku,
Tokyo, 105-0012 JAPAN
TEL: 03-5777-2883
FAX: 03-5777-2884
6.10 CD媒体に関する勧告
CD媒体（CD-R及びCD-RW）は，その特徴によって，特別な配慮を必要とする。CDは元々，再生専用
アプリケーションのために設計されており，そのことが書込み方法に影響する。次の指針は，交換を確実
に行うために作られた。
各ファイル及びディレクトリは，1個の直接ICBで記載しなければならない。そのICBは，書込み中の
データ不足を見込んで，ファイルデータの後で書き込まれることが望ましいが，これは，ファイルデータ
の論理ギャップを引き起こす。ICBは，後で書き込むことができるが，このことは，ファイルデータの全
てのエクステントを正しく識別する。ICBは，データトラック，ファイルシステムトラック（もし存在す
114
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
れば），又は両方に書き込まれなければならない。
6.10.1 CD-R媒体でのUDFの使用
CD-Rについては，6.11の規定が6.10.1の追加とともに適用される。
VATは，未完成媒体の場合にはREAD TRACK INFORMATIONを使用するか，又は完成媒体の場合には
READ TOC若しくはREAD CD RECORDED CAPACITYを使用して，位置を決めてもよい。X3T10-1048D
（SCSI-3 マルチメディアコマンド）を参照する。
6.10.1.1 CD-Rでのモードの要件
a) 書込みでは，モード1又はモード2フォーム1のセクタを使用しなければならない。1枚のディスク
で，モード1又はモード2フォーム1のどちらかを使用しなければならない。1枚のディスクでモー
ド1とモード2フォーム1のセクタとを混合して使用することはできない。
特記事項 JIS X 6282の箇条10（複セションディスク及び複合形ディスク）によると，ディスクのデ
ータセションの全ては，同じ種別（モード1又はモード2フォーム1）でなければならな
い。
b) モード2フォーム1を使用する場合，利用者データファイル及びUDF構造で使用される全てのセクタ
のサブヘッダバイトは，次の値をもたなければならない。
ファイル数 = 0
チャネル数 = 0
サブモード = 08h
コード化情報 = 0
6.10.1.2 CD-RでのUDFブリッジフォーマット
JIS X 0606ブリッジディスクにモード2フォーム1セクタが含まれる場合，JIS X 0606用CD-ROM XA
拡張を使用しなければならない。さらに，6.11.4の規定が適用される。
6.10.2 CD-RW媒体でのUDFの使用
CD-RW媒体は，任意の位置の読出し及びブロックの書込みができる。つまり，個々のセクタを読みと
るとき，複数セクタを含むブロックで書込みが行われなければならない。CD-RWシステムでは，不良領
域の予備は用意しない。書込み規則及び予備機構は定義されている。
6.10.2.1 要件
a) 6.10.2.1に適合する書込みを行う場合，固定長パケットを使用しなければならない。
b) 書込みは，モード1又はモード2フォーム1のセクタを使用して行わなければならない。1枚のディ
スクではモード1又はモード2フォーム1のいずれかを使用しなければならない。
特記事項 JIS X 6282の箇条10によると，ディスクのデータセションの全ては，同じ種別（モード
1又はモード2のフォーム1）でなければならない。
c) モード2フォーム1を使用する場合，利用者データファイル及びUDF構造で使用する全てのセクタの
サブヘッダバイトは，次の値をもたなければならない。
ファイル数 = 0
チャネル数 = 0
サブモード = 08h
コード化情報 = 0
d) ホストでは，2 Kセクタの書込みを明確に行えるように，読み出し変更し書き込む動作を実行しなけ
ればならない。
115
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
e) パケット長は，ディスクの初期化時に設定しなければならない。パケット長は，32セクタ（64 KB）
でなければならない。
f)
初期化時に知られている欠陥パケットは，割付け禁止空間ストリームによって割り付けられなければ
ならない（3.3.7.2参照）。
g) 予備は，予備区画及び予備表を介してホストが管理しなければならない。
h) ディスクは，使用前に初期化しなければならない。
6.10.2.2 初期化
初期化は，リードイン，利用者データ領域及びリードアウトの書込みから成らなければならない。これ
らの領域は，任意の順序で書込みをしてもよい。この物理的フォーマットには，検証パスが続いてもよい。
検証パスの間に見つかる欠陥パケットは，割付け禁止空間ストリームに列挙しなければならない（3.3.7.2
参照）。最後にファイルシステムルート構造が記録されなければならない。これらの強制的なファイルシス
テム及びルート構造にはボリューム認識列，開始ボリューム記述子ポインタ，ボリューム記述子列，ファ
イル集合記述子，及びルートディレクトリが含まれる。
開始ボリューム記述子ポインタは，セクタ256及びN−256に記録しなければならない。ここで，Nは，
番地付け可能な最後のセクタの論理セクタ番号とする。
予備の割付けは，初期化プロセスの間に行わなければならない。予備割付けの長さは0でもよい。
未割当て空間記述子を，欠陥領域及びセクタ予備領域に割り付けられた空間を反映するように，記録し
なければならない。
フォーマットは，媒体で利用可能な全ての空間を含んでよい。しかし，利用者が要求した場合，初期化
時間を節約するため，部分集合を初期化してもよい。その少量のフォーマットを，後に，完全に利用可能
な空間に“成長”させてもよい。
6.10.2.3 成長するフォーマット
媒体を部分的に初期化し，後に大きく成長させてもよい。この動作は次の要素から成る。
a) 最後のセションのリードインを任意選択で消去する。
b) 最後のセションのリードアウトを任意選択で消去する。
c) パケットの書込みを，事前に記録した最後のパケットのすぐ後から始める。
d) 予備表の更新は，新しい予備領域を反映する。
e) 区画マップを適宜調節する。
f)
新しく利用可能な領域を示すために，未割付け空間ビットマップ又は未割付け空間表を更新する。
g) 最後のAVDPを新しい（N−256）に移動する。
h) リードイン（新しいトラックサイズを反映する。）の書込みをする。
i)
リードアウトの書込みをする。
6.10.2.4 ホストベースの欠陥管理
ホストでは欠陥管理動作を行わなければならない。CDフォーマットは欠陥管理を含めないで定義され
たので，現存の技術及びコンポーネントと互換性をもたせるには，ホストで欠陥を管理しなければならな
い。欠陥管理には2段階がある。すなわち，初期化時に不良セクタをマーク付けすること，及びオンライ
ンで予備を割り当てることである。ホストは現在の媒体に表を保持しなければならない。
6.10.2.5 読み出し変更し書き込む動作
CD-RW媒体は大きな書込み可能単位を必要とする。これは，各装置が，14 KBオーバヘッドを受けるた
めである。ファイルシステムは2 KBの書込み可能単位を必要とする。書込みサイズの差は，ホストの読
116
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
み出し変更し書き込む動作で処理される。パケット全体が読み取られ，適切な部分が変更され，パケット
全体がCDに書き込まれる。
パケット及びトラックは，32セクタ境界に整列しなければならない。
6.10.2.6 適合のレベル
6.10.2.6.1 レベル1
ディスクは，厳密に1個のリードイン，プログラム領域，及びリードアウトで初期化しなければならな
い。プログラム領域は，厳密に1個のトラックを含まなければならない。
6.10.2.6.2 レベル2
最後のセションはUDFファイルシステムを含まなければならない。その前のセションの全ては，一つの
読出し専用区画内に含まれなければならない。
6.10.2.6.3 レベル3
いかなる制約も適用してはならない。
6.10.3 複セション及び混合モード
CD-R及びCD-RWについては，6.11の規定が，次の追加規定とともに適用される。
ランダム書込みモードを使用する場合，媒体は0又は1のオーディオセションでフォーマットし，その
後に，1個のトラックを含む，書込み可能なデータセションを厳密に1個続けてもよい。他のセションの
構成も可能だが，ここでは記載していない。
ランダムアクセスモードで記録するとき，重複ボリューム認識列は，セクタN−16から記録を始めるこ
とが望ましい。
複セションCDディスクはオーディオセションを含むことがある。UDFブリッジフォーマットはCD強
化ディスクの作成を許可している（6.11.5の例を参照）。
6.11 異なる媒体への記録での共通側面
6.11では，異なる媒体への記録での共通側面について規定する。
側面としては，次がある。
a) Real-Timeファイル
b) VATを用いるインクリメンタル記録
c) 複セションディスク
d) UDFブリッジディスク
セションを利用できない媒体は，論理セクタ0から始まり，番地付け可能な最大の論理セクタ番号で終
わる単一のセションをもつものとして扱われる。トラックを利用できない媒体は，セションと同じ大きさ
かつ同じ開始番地である単一のトラックをもつものとして扱われる。媒体によってはトラック及びセショ
ンに対して異なる用語が使われることがある，例えばDVD+Rでは，トラックはフラグメント（Fragment）
ト呼ばれる。
6.11.1 Real-Timeファイル（Real-Time Files）
Real-Timeファイルは，ファイルのICBタグのファイル種別欄のファイル種別249によって識別される。
Real-Timeファイルは，例えば，オーディオビデオデータを書き込むとき又は読み出すときに，最低限のデ
ータ転送レートの保証が必要なファイルである。これらのファイルは，特別な読出しコマンドと書込みコ
マンドとを必要とする。例えば，CD及びDVDでは，これらの特別なコマンドは，SCSI-3 MMC command
set specificationで見つけることができる。
6.11.2 VATを用いるインクリメンタル記録
117
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
この方式の記録は論理ボリューム記述子内に仮想区画マップ（Virtual Partition Map）が記録された逐次
記録媒体で使用される（2.2.8参照）。VATの使用方法は2.2.11に記述されている。VAT ICBは媒体の最大
の記録済みの論理セクタ番号の箇所に記録されている。この論理セクタ番号は関連する媒体に対する
READ TRACK INFORMATION命令を使用して，位置を決めてもよい，例えばX3T10-1048D（SCSI-3 マル
チメディアコマンド）を参照。
JIS X 0607規格類では，セクタ256，N又は（N−256）（この場合，Nは，媒体に最後に記録された物理
番地とする。）のうち少なくとも2か所に開始ボリューム記述子ポインタ（AVDP）を必要とする（2.2.3参
照）。VAT ICBが最後として記録されるため，NはAVDPには使用できない。最終セションが閉じられた場
合だけ，AVDPは（N−256）になければならない。ファイルシステムは，閉じる前は中間状態にあり，ま
だ交換可能状態であるが，JIS X 0607規格類と厳密に互換性がなくてもよい。中間状態では，ただ一つの
AVDPが存在する。セクタ256に存在することが望ましいが，トラック予約のためにそれが不可能な場合
は，セクタ512に存在しなければならない。512にあるAVDPは，256，（N−256）又はNにAVDPが存在
する場合は無視されなければならない。512にあるAVDPは中間状態だけで使用される臨時のボリューム
記述子列を指すことができる。
処理システムでは，ファイルシステム管理構造を仮想空間に，ファイルデータは，現実の空間に置くこ
とが望ましい。読取装置処理システムは，VAT全体をキャッシュメモリに入れてもよい。VATの大きさは，
UDFに基づくソフトウェアで検討することが望ましい。
6.11.2.1 要件
a) 中間状態は，ただ一つのAVDPが記録される媒体で可能とする。この一つのAVDPは，セクタ256又
はセクタ512にあるものとし，6.11.3の複セション規則に従う。
b) 論理ボリューム保全記述子は，記録するものとし，ボリュームは開放と表示しなければならない。論
理ボリュームの保全性は，最後に記録された物理番地にVAT ICBを見つけることで証明できる。もし，
VAT ICBが存在すれば，ボリュームはクリーンであり，もし，存在していなければ，ダーティである。
c) 区画ヘッダ記述子は，未割付け空間表，未割付け空間ビットマップ，空き空間表，及び空き空間ビッ
トマップは規定してはならない。ドライブは，空き空間を直接報告することができ，別々の記述子の
必要性を取り除く。
d) 各表面には，0個又は1個の再生専用区画，0個又は1個の追記区画，及び0個又は1個の仮想区画が
含まれなければならない。VATを使用する媒体は，1個の追記区画，及び1個の仮想区画を含むこと
が望ましい。
6.11.2.2 セションデータの末端
幾つかの再生専用ドライブ（例えば，CD-ROM，DVD-ROM）は閉じられたセションしか読取りが行え
ない。ディスク上の最後の完全セションは完全にJIS X 0607規格類に従い，2個のAVDPを記録しなけれ
ばならない。これは，表46のセションデータの末端に従って，データを書き込むことで完成しなければ
ならない。
表46−セションデータの末端
数
記述
1
開始ボリューム記述子ポインタ
255
処理システム仕様。利用者データ，ファイルシステム構造・リンク領域を含んでもよい。
1
VAT ICB
118
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
処理システム仕様データは，VAT及び，VAT ICBの反復コピーを含んでもよい。最後のセクタの位置を
正確に報告しないドライブとの互換性が高まる。処理システムでは，セションデータの最後尾を記録する
のに十分な空間が利用できることを確実にしなければならない。セションデータの最後尾を記録すること
によって，ボリュームはJIS X 0607規格類に一致する。
6.11.3 複セションの使用方法
ボリューム認識列及び開始ボリューム記述子ポインタの位置は，ディスクの始まりに関連する位置であ
ると，JIS X 0607規格類で規定されている。ディスクの始まりは，VRS及びAVDPを見つける目的で，基
本番地Sから決定しなければならない。
“S”は，ボリュームの最後の既存のセション内に記録された，最初のデータトラックの，最初のデータ
セクタの物理番地である。“S”は，複セションのJIS X 0606の記録で使われているものと同じ値である。
このセションの最初のトラックはデータトラックでなければならない。
“N”はボリューム上の番地付け可能な最後のデータセクタの論理セクタ番号である。
1回に1個だけ書込み可能区画又はセションがあるものとし，このセションはディスクでは最後のセシ
ョンでなければならない。
新しい主ボリューム記述子列及び予備ボリューム記述子列は，各追加セションに存在してもよく，前の
VDSと異なってもよい。
媒体の最後のセションが有効なUDFファイルシステムを含まない場合，そのディスクはUDFディスク
ではない。最後のセションの中のUDF構造，並びにそのUDF構造を通じて参照される全てのUDF構造及
びデータだけが有効とする。
UDFセションは，他のセションにあるデータ若しくはメタデータへのポインタ，そのUDFセション内
だけにあるデータ又はメタデータへのポインタ，又は両方の組合せを含んでいてもよい。
6.11.3.1 ボリューム認識列
複セションディスクを扱うために，次の記載をUDFに加える（JIS X 0607規格類の第2部参照）。
a) UDFブリッジフォーマット（6.11.4参照）のボリューム認識領域は，（2 Kセクタであるとした場合）
セクタS＋16で始まるボリューム空間の一部でなければならない。
b) ボリューム認識空間の，始まりと終わりのセションは同じでなければならない。この定義の結果，ボ
リューム認識領域は常にディスクの最後のセションに存在する。
6.11.3.2 開始ボリューム記述子ポインタ
開始ボリューム記述子ポインタ（AVDP）は，S＋256，N−256及びNの論理セクタ数の場所のうち少な
くとも2か所に記録しなければならない。セクタN又はN−256のAVDPはセション開放している間は，
記録してはならない。S＋512にあるAVDPは，S＋256，N−256又はNにAVDPが存在する場合は無視さ
れなければならない。
6.11.4 UDFブリッジフォーマット
UDFブリッジフォーマットによって，UDFは，別のファイルシステムを含んでいるディスクに加えるこ
とができる。UDFブリッジディスクは，最後のセションにUDFファイルシステムを含まなければならな
い。最後のセションは，6.11.3に記載された規則に従わなければならない。このディスクは，JIS X 0606，
CDオーディオ若しくはベンダ独自のファイルシステム，又はそれらのファイルシステムの組合せに基づ
くセションを含んでもよい。
JIS X 0606では，（2 Kセクタであるとした場合）セクタ16に基本ボリューム記述子（ISO PVD）を要求
する。JIS X 0606のファイルシステムが要求すれば，JIS X 0607規格類の構造でアクセスされる，同一フ
119
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ァイルへのアクセスを含んでもよい。また，異なるファイル集合へのアクセス，又は両方の組合せを含ん
でもよい。
6.11.5 複セションUDF及びUDFブリッジの例
複セションUDFディスク及びUDFブリッジディスクの幾つかの例を図2〜図5に示す。
図2−複セションUDFディスク
図3−CD強化ディスク
図4−JIS X 0606のUDFへの変換
図5−異種フォーマットのUDFへの変換
6.12 DVD-R，DVD-RW及びDVD-RAMの交換可能性に関する要件
この規定は，コンピュータシステムと家電のユーザとの情報交換のために，DVD-RAMディスク（6.12.1
第1セション
第2セション
第3セション
データセション
データセション
UDFセション
UDFで管理されている領域
他のファイルシステムで書かれた領域
第1セション
第2セション
第3セション
JIS X 0606セション
JIS X 0606セション
UDFセション
UDFで管理されている領域
JIS X 0606フォーマットで書かれた領域
第1セション
第2セション
UDFセション
UDFに使用されている領域
従来のCDプレーヤにかかる演奏可能な領域
LSN=256へのアクセス
LSN=16+xへのアクセス
16セクタ
256セクタ
16セクタ
256セクタ
最終セションで最初に記録されたトラック
第1セション
ボリューム認識領域
開始点（Anchor point）
120
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
参照），DVD-RWディスク（6.12.2参照），DVD-Rディスク（6.12.3参照）を含むがそれに限らない，書込
み可能なDVD媒体に対するボリューム構造及びファイル構造の要件及び制約を規定する。これらの要件
はコンピュータシステム環境だけで使われ，家電との交換性のないディスクには適応されない。これらの
DVDディスクに対する共通の要件を，次に示す。
a) ボリューム及びファイル構造はUDF 2.00に従わなければならない。
b) UDF読出し最小版数及びUDF書込み最小版数は2.00でなければならない。
c) 論理セクタ長及び論理ブロック長は2 048バイトでなければならない。
d) 一つの主ボリューム記述子列及び一つの予備ボリューム記述子列が記録されなければならない。
6.12.1 DVD-RAMに関する要件
DVD-RAMディスクに対する要件はUDF 2.00によっている。ボリューム構造及びファイル構造は非逐
次記録を用いる上書き可能形のディスクとして単純化されている。
ボリューム構造に関する要件を，次に示す。
a) DVD-RAMディスクの区画は，アクセス種別4で指定される上書き可能区画でなければならない。
b) 仮想区画マップ及び仮想割付け表は記録してはならない。
c) 予備区画マップ及び予備表は記録してはならない。
ファイル構造に関する要件を，次に示す。
d) 未割付け空間表又は未割付け空間ビットマップを用いて空間を示さなければならない。空き空間表及
び空き空間ビットマップは，記録してはならない。
e) 割付け禁止空間ストリームは，記録してはならない。
6.12.2 DVD-RWに関する要件
リストリクテッドオーバライトモードで記録されたDVD-RWディスクに対する要件は，UDF 2.00によ
っている。ボリューム構造及びファイル構造は，非逐次記録を用いる書換形のディスクとして単純化され
ている。
ボリューム構造に関する要件を，次に示す。
a) ディスクの各面は，一つの予備区画をもつ一つのボリュームで構成されなければならない。
b) 予備区画表及び予備表が記録されなければならない。
c) パケット長は16セクタ（32 KB）でなければならず，パケットの最初のセクタ番号は16の倍数でな
ければならない。
d) 仮想区画マップ及び仮想割付け表は，記録してはならない。
ファイル構造に関する要件を，次に示す。
e) 未割付け空間ビットマップを用いて空間を示さなければならない。未割付け空間表，空き空間表及び
空き空間ビットマップは記録してはならない。
f)
割付け禁止空間ストリームが記録されなければならない。
g) ICB方策種別4を用いなければならない。
h) ファイルエントリ又は拡張ファイルエントリの割付け記述子欄には，短割付け記述子又は埋込みデー
タが記録されなければならない。この欄には長割付け記述子を記録してはならない。
6.12.3 DVD-Rに関する要件
ディスクアトワンス記録モード及びインクリメンタル記録モードで記録されたDVD-Rディスクに対す
る要件は，UDF 2.00によっている。ボリューム構造及びファイル構造は逐次記録を用いる追記形のディス
クとして単純化されている。
121
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ボリューム構造に関する要件を，次に示す。
a) パケット長は16セクタ（32 KB）でなければならず，パケットの最初のセクタ番号は16の倍数でな
ければならない。
b) 予備区画マップ及び予備表は記録してはならない。
c) インクリメンタル記録モードでは，論理ボリューム保全列には開いた保全記述子は一つだけしか記録
してはならない。
d) インクリメンタル記録モードでは，仮想区画マップが記録されなければならない。
ファイル構造に関する要件を，次に示す。
e) 未割付け空間表，未割付け空間ビットマップ，空き空間表及び空き空間ビットマップは記録してはな
らない。
f)
ファイル集合記述子は一つだけしか記録してはならない。
g) 割付け禁止空間ストリームは記録してはならない。
h) インクリメンタル記録モードでは，仮想割付け表及びVAT ICBが記録されなければならない。
i)
インクリメンタル記録モードでは，ICB方策種別4を用いなければならない。
j)
インクリメンタル記録モードでは，仮想割付け表のVATエントリは，次のように割り当てられなけれ
ばならない。
1) 仮想アドレス0は，ファイル集合記述子のために使わなければならない。
2) 仮想アドレス1は，ルートディレクトリのICBのために使わなければならない。
3) 仮想アドレス2〜255の範囲は，DVD̲RTAVディレクトリのファイルエントリ及びDVD̲RTAVディ
レクトリ下のファイルのファイルエントリのために使わなければならない。
6.12.4 DVDディスク上のReal-Timeファイル記録に関する要件
DVDビデオ記録規定は，DVD固有のサブディレクトリ“DVD̲RTAV”及びDVD̲RTAVディレクトリ
下のDVD固有の全てのファイルを規定している。DVD固有のファイルは，ファイル種別249のReal-Time
ファイルと関連する情報ファイルとから構成されている。
ボリューム構造に関する要件を，次に示す。
a) DVD-RAMディスク及びDVD-RWディスクでは，ディスクの各面は，一つの区画をもつ一つのボリ
ュームで構成されなければならない。DVD-Rディスクでは，ディスクの各面は，一つの追記形区画と
一つの仮想区画とをもつ一つのボリュームで構成されなければならない。
b) DVD-RWディスクでは，第1予備表及び第2予備表が記録されなければならない。
ファイル構造に関する要件を，次に示す。
c) DVD-RAMディスク及びDVD-RWディスクでは，未割付け空間ビットマップだけを用いなければな
らない。
d) DVD-RWディスクでは，未割付け空間ビットマップのエクステントは，使用可能な記録領域を示すた
めに，空間ビットマップ記述子の長さをもつことが望ましい。
e) 家電の記録機は，ルートディレクトリにある特別なサブディレクトリであるDVD̲RTAVに全てのデ
ータを記録する。DVD̲RTAVディレクトリ及びその内容は，DVDフォーマットロゴライセンシング
株式会社が出版するDVD規定に定められた特別なファイルシステム制約をもつ（6.9.3参照）。実装又
はアプリケーションは，上記DVD仕様によって定められた制約に従えない場合は，このディレクト
リ内のファイルを作成又は変更するのは望ましくない。
122
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.13 DVD+R及びDVD+RW媒体に関する勧告
DVD+R及びDVD+RW媒体は，1層及び2層の媒体であり，その性質によって特別な配慮を必要とする。
次に示すガイドラインは，交換を確実にするために制定された。
a) 論理セクタ長 2 048バイト
b) 読出し及び書込みのユーザデータ転送2 048バイト
c) ECCブロック長は32 768バイト（32 KB）及びECCブロックの最初のセクタ番号は16の整数倍でな
ければならない。
1層のDVD+R及びDVD+RW媒体は最大4.7 Gバイトの容量をもつ。2層のDVD+R DL及びDVD+RW DL
媒体は最大8.5 Gバイトの容量をもつ。より詳細な情報については，SCSI-3 MMC command set specification
及びDVD+R及びDVD+RWのBasic Format Specification documentを参照。マウントレイニアフォーマット
されたDVD+MRW媒体については6.14を参照。
UDFの構造を“物理的に離れている”場所に記録することが望ましい場合，特別な配慮が必要になる。
2.2.3.2及び2.2.13.1を参照する。2層の媒体では，物理的に離れていることと論理的に離れていることは
同じではない。
6.13.1 DVD+R媒体での追記のためのUDFの使用
1層及び2層のDVD+R媒体はディスクアトワンス，セションアトワンス及びインクリメンタル記録に
使用することができる。複セションは利用可能である。6.11の一般的な規定が適用される。
6.13.2 DVD+RW媒体でのUDFの使用
1層及び2層のDVD+RW媒体はランダムに読み書き可能である。必要な場合，DVD+RWドライブが読
出し-変更-書込みのサイクルを行ってこれを実現する。ドライブはDVD+RW媒体のためには欠陥管理を行
わない。DVD+RW媒体は次に示す機能を提供する。
a) ランダムアクセス読出し及び書込み
b) バックグラウンドでの物理フォーマッティング
c) 媒体種別は上書き可能形（区画アクセス種別4，上書き可能形）。
DVD+RW媒体では複セションは利用できない。
6.13.2.1 要件
a) 予備は，予備区画及び予備表を介して，ホストによって管理されなければならない。
b) 予備パケット長は16セクタ（32 KB，一つのECCブロック）でなければならない。UDF 1.50及びUDF
2.00では，予備パケット長が32論理ブロックである可能性がある（正誤表DCN-5163参照）。
c) 初期化時に知られている欠陥パケットは，割付け禁止空間ストリームによって割り付けられなければ
ならない（3.3.7.2参照）。
ブランクであるDVD+RW媒体をUDFで使用するために準備するのは，物理フォーマッティング及び論
理フォーマッティングによって行われる。物理フォーマッティングは基本的な物理構造の書込み，及び再
生専用形装置への互換性のためのデアイシング（JIS X 6250参照）である全てのセクタへの一度の書込み
である。論理フォーマッティングは必須である基本的なUDFファイルシステム構造の書込みである
（6.13.2.3参照）。物理フォーマッティングは論理フォーマッティングに先だって行うことができる。これ
は物理プリフォーマッティングと呼ばれる。しかし，これには多くの時間がかかる。DVD+RWはバック
グラウンド物理フォーマッティングの可能性を提供する（6.13.2.2参照）。論理フォーマッティング，ユー
ザデータの書込み及び媒体の排出・再挿入はバックグラウンド物理フォーマッティングの進行中に行うこ
とができる。物理フォーマッティングには，検証パスが続いてもよい。
123
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.13.2.2 バックグラウンド物理フォーマッティング
バックグラウンド物理フォーマッティングが開始されるとある程度の最小限の初期化が行われた後，デ
アイシングはバックグラウンドで続けられる。この時から論理フォーマッティング及びユーザデータの書
込みが実行可能になる。ディスクはバックグラウンドフォーマッティングが終了する前に排出することが
可能である。このような早期排出のため，バックグラウンドフォーマッティング処理は保留されなければ
ならず，いわゆる互換性停止又は迅速停止を使う。互換性停止の後，媒体は再生専用形装置と互換性があ
る。互換性停止のため，ドライブはディスクの内側の記録済み領域との間の全ての未記録領域をフォーマ
ッティングしなければならない。これは，早期排出処理を非常に遅らせる原因になり得る。バックグラウ
ンドフォーマッティングがまだ終了していない間，ファイルシステムの割付け方策の一時的変更によって
互換性停止の遅延を非常に減らすことが可能である（6.13.2.4参照）。バックグラウンドフォーマッティン
グが保留された媒体への書込みが再開されたときは，バックグラウンド物理フォーマッティング処理も再
開されなければならない。バックグラウンド物理フォーマッティングはディスクの内側から始まる。互換
性停止の後は，L0層のディスクの内側に中断のない領域が，2層のディスクでは更にL1層のディスクの
内側の相等しい領域が記録される。これらのL0及びL1の領域の対応する二つの相等しい部分は，各々UDF
ボリューム空間の始まり及び終わりにある。
6.13.2.3 論理フォーマッティング
論理フォーマッティングは必須である基本的なUDFファイルシステム構造，例えばVRS，AVDP，VDS，
FSD，ルートディレクトリ及び予備表等を書き込むことである。
AVDPは256，N−256及びNのうち，2か所に記録されなければならない，Nはボリューム空間の最後
の有効な番地とする。しかし，特にDVD+RW DLディスクでは，AVDPが記録される領域がディスクの内
側の両方の層となり物理的に離れていないため，AVDPを3か所全てに記録することが推奨される。予備
のための割付けは論理フォーマッティング処理の最中に行われなければならない。予備割付けの長さは0
であってよい。論理フォーマッティング時に知られている欠陥パケットは予備表によって予備化してはな
らないが，割付け禁止空間ストリームに追加される。予備化されていない欠陥パケット及び予備表のイン
スタンス又は予備領域は，常に割付け済みと表示されなければならない。UDF区画空間の内部では，これ
らのパケットは割付け禁止空間ストリームに追加されなければならず，その結果として区画空間集合で割
付け済みと表示される（2.2.12及び3.3.7.2参照）。UDF区画空間の外部では，これらのパケットは未割付
け空間記述子によって割付け済みと表示されなければならない。
バックグラウンド物理フォーマッティングの状態はLVIDの記録には影響してはならない。早期排出の
場合，LVIDはバックグラウンド物理フォーマッティングの利用できない上書き可能形媒体に記録される
のと同様に記録されなければならない。
6.13.2.4 バックグラウンドフォーマッティング時のDVD-ROMとの互換性に関する制約
ここで示す制約は，バックグラウンド物理フォーマッティングがまだ完了していない場合の早期排出時
にDVD-ROMとの互換性が要求された場合にだけ推奨する。バックグラウンド物理フォーマッティングが
完了すると，DVD-ROMとの互換性が実現し制約は必要とされない。これらの制約は早期排出の場合の互
換性停止の遅延を減らすことを狙ったものである。
バックグラウンド物理フォーマッティング時の制約を，次に示す。
a) 1層のDVD+RWについては，バックグラウンド物理フォーマッティングが開始されたら，セクタ256
に最初のAVDPだけを記録しなければならない。二つ目の及び三つ目のAVDPは，バックグラウンド
物理フォーマッティングが終了した後に書き込まれなければならない。AVDPが一つだけ記録されて
124
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
いるときには，ファイルシステムは中間状態にあり，JIS X 0607規格類との厳密な互換性がない。2
層のDVD+RW DLはバックグラウンドフォーマッティングが始まった直後に全てのAVDPの記録が可
能になるためこの制約はない。これは，6.13.2.2で述べられている両方の層の物理フォーマッティング
で可能になる。
b) 早期排出時の互換性停止の遅延を減らすために，バックグラウンドフォーマッティングがまだ完了し
ていないときには，割付け方策は制約される。ボリューム空間の始まりにある最小の論理セクタ番地
及び2層のDVD+RW DLでは，更にボリューム空間の終わりにある最大の論理セクタ番地は，互換性
停止の遅延を減らすために，最初に割り付けられ，かつ，記録されなければならない。
6.14 マウントレイニアフォーマット媒体に関する勧告
次に示すガイドラインは，マウントレイニア（MRW）フォーマット媒体の交換を確実にするために規定
された。
6.14.1 CD-MRW媒体，DVD+MRW媒体及びドライブの属性
MRW媒体及びドライブの主要な属性のリストを次に示す。
a) 物理セクタサイズ 2 048バイト
b) ドライブが，必要に応じて読出し-変更-書込みのサイクルを行う。ホストとMRWドライブとの間の
データ転送は2 048バイトの倍数とする。
c) ランダムアクセス読出し及び書込みが可能
d) ドライブによる欠陥管理
e) ドライブは，バックグラウンド物理フォーマッティングを行う。
f)
媒体種別は上書き可能形（区画アクセス種別4，上書き可能）
g) 割付け禁止空間リスト，割付け禁止空間ストリーム，予備表はMRWフォーマット媒体には使用して
はならない。
6.14.2 バックグラウンド物理フォーマッティング
ファイルシステムの初期化時に，バックグラウンド物理フォーマッティングが開始されたら，ホストは
セクタ256に最初のAVDPを記録しなければならない。二つ目のAVDPは，バックグラウンド物理フォー
マッティングが終了した後に記録されなければならない。二つ目のAVDPが記録される前では，ファイル
システムは中間状態にあり，JIS X 0607規格類とは厳密な互換性がない。媒体はバックグラウンドフォー
マッティングが終了する前に排出でき，その場合AVDPが一つだけMRW媒体上に存在する。早期排出時
には，ドライブはホストによって記録された最大セクタ番号までの全ての未記録領域を初期化しなければ
ならないことに注意する。これは早期排出処理を非常に遅らせる原因になり得る。バックグラウンド物理
フォーマッティングが行われている場合，実装は利用できる最小の番号のブロックを割り付けることが推
奨される。
バックグラウンド物理フォーマッティングの状態は，LVIDの記録に影響してはならない。LVIDは早期
排出時に，バックグラウンド物理フォーマッティングが行えない書換形媒体に記録されるのと同様に，記
録されなければならない。
6.15 疑似上書き可能機構の導入
以前の版のUDFでは（UDF 1.50〜UDF 2.50で記述されているとおり），複セション又はVATは，CD-R，
DVD-R，及びDVD+R媒体で逐次記録機能を実現するために使用されてきた。次世代のドライブがサポー
トする逐次記録可能媒体での疑似上書き能力は，ファイルシステムの複雑さを減らすことに寄与する。こ
の6.15で記述されるUDF疑似上書き（UDF Pseudo OverWrite）方式は，このような疑似上書き記録可能媒
125
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
体に適用できる。
UDF疑似上書き方式の利点は，
− ドライブが疑似上書き機能及び欠陥管理をサポートすることによって，増大した互換性を確実にする。
− 欠陥管理がドライブで処理されるため，（少なくとも論理セクタの粒度では）ボリューム全体が上書き
可能となり，ファイルシステム処理システムの複雑さを減少する。
− UDF処理システムは，メタデータファイルをメタデータを配置するために論理的に切れ目のないやり
方で使用できる。このメタデータは，要望される堅ろう（牢）性を実現するために，メタデータ控え
ファイルに任意選択で複製することができる。
6.15.1 疑似上書き可能形に初期化された媒体の特徴
疑似上書き可能形に初期化された媒体は，複トラック記録を利用可能である。媒体上のボリューム空間
にある全ての論理セクタは，上書き可能とする。
ファイルシステムは，複数のトラックに並行して記録できる。トラックは“予約”又は“使用済み”と
して定義できる（1.3.2参照）。各トラックは逐次記録だけを可能とする。トラック内の次に記録可能な論
理セクタを指す記録可能次アドレス（NWA）は，ファイルシステムがドライブに問い合わせることによっ
て得られる。
逐次記録に加えて，トラック内のNWAより前の全ての論理セクタは，独立に上書き可能とする。同様
に（有効なNWAをもたない）使用済みトラック内のセクタは，上書き可能とする。（線形置換えアルゴリ
ズムによる）予備領域内又はボリューム空間内のNWAまでのいずれでも，ドライブが更新されたデータ
を記録することによって，上書きを可能にする。現状ではUDFは，上書きされたデータの物理的配置をフ
ァイルシステムが管理するための明示可能な方針を提案していない。トラックのNWAの要求後の媒体へ
の逐次書込みを実行している間，UDFの処理システムがそのトラックのNWAを再度要求するまでは，ド
ライブシステムは，NWAが予想されずに又は通知なしに変更されることのないように振る舞わなければ
ならない。疑似上書きが実行されると，全てのNWAは無効になる。
ボリューム空間内に関連付けられることが可能性がある論理セクタの再配置情報を維持することは，ド
ライブに完全に責任がある。
6.15.2 書込み方策
トラックは，異なるデータ種別を論理的に隣接した方法で記録するために利用できる（例えば，メタデ
ータ，メタデータ複製及びデータを別々のトラックに記録できる。）。予約トラック中の未記録であるセク
タが尽きた場合，UDF処理システムは，適切な大きさの新しい予約トラックを（既存の予約トラックを分
割することによって）割り当てることができる。
予約トラックが分割されることを許したため，ドライブはJIS X 0607に従って（ボリューム構造を構成
する）AVDPをLSN 256，ボリューム内の最大LSN又は（最大LSN−256）のうちの2か所に記録できる。
UDF処理システムは，メタデータをメタデータ控えファイルに複製することが望ましい。
図6は，メタデータ控えファイルが記録されずに初期化された直後の媒体のトラック配置を例示する。
トラック1はボリューム構造（LSN 256のAVDPを含む。）に加えて関連するファイル構造を含む。メタデ
ータ区画マップの複製メタデータフラグは，ZEROにセットされる。初期化ユーティリティは，一つのエ
クステント（トラック）をメタデータの記録のために割り当て，そしてトラック3は，要求に応じ利用さ
れる記録可能なボリューム空間のほとんどを含む。
126
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図6−初期化直後の媒体−メタデータ控えファイルなし
図7は，メタデータ控えファイルが記録されるように初期化された直後の媒体のトラック配置を例示す
る。メタデータ区画マップの複製メタデータフラグはONEにセットされる。したがって，メタデータ控
えファイルの内容のためのエクステントが割り当てられている。
図7−初期化直後の媒体−メタデータ控えファイルが記録される
図8は，ファイルが記録された後の媒体のトラック配置を例示する（この場合，メタデータ控えファイ
ルは記録されていないことに注意）。この例では，トラック2は使用済み状態になっており，したがって，
トラック4は追加のメタデータの記録のために割り当てられている（トラック3はデータの記録のために
使用済み。）。
予
備
領
域
ボ
リ
ュ
ー
ム
構
造
メ
タ
デ
ー
タ
フ
ァ
イ
ル
F
E
フ
ァ
イ
ル
集
合
記
述
子
F
E
(
ル
ー
ト
デ
ィ
レ
ク
ト
リ
)
未
記
録
領
域
未
記
録
領
域
A
V
D
P
予
備
領
域
メ
タ
デ
ー
タ
複
製
フ
ァ
イ
ル
F
E
ボリューム空間
トラック1
（使用済み）
トラック2
（予約）
トラック3
（予約）
トラック4
（使用済み）
メタデータファイルのエクステント
予
備
領
域
ボ
リ
ュ
ー
ム
構
造
メ
タ
デ
ー
タ
フ
ァ
イ
ル
F
E
フ
ァ
イ
ル
集
合
記
述
子
F
E
(
ル
ー
ト
デ
ィ
レ
ク
ト
リ
)
未
記
録
領
域
未
記
録
領
域
A
V
D
P
予
備
領
域
メ
タ
デ
ー
タ
複
製
フ
ァ
イ
ル
F
E
ボリューム空間
トラック1
（使用済み）
トラック2
（予約）
トラック3
（予約）
トラック5
（使用済み）
メタデータファイルのエクステント
フ
ァ
イ
ル
集
合
記
述
子
F
E
(
ル
ー
ト
デ
ィ
レ
ク
ト
リ
)
未
記
録
領
域
トラック4
（予約）
メタデータ控えファイルのエクステント
127
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図8−媒体へのデータの記録（メタデータ控えファイルなし）
6.15.3 UDF処理システムに関する要件
UDF処理システムは，次に示す要件を満たすことを期待されている。
− 疑似上書き可能に初期化された逐次記録形媒体は，区画記述子のアクセス種別は0（疑似上書き可能）
にセットされなければならない（2.2.14.2参照）。
− 未割付け空間ビットマップ及び未割付け空間表は，記録してはならない。
− メタデータ区画マップが記録されなければならない。
− メタデータビットマップファイルは記録されてはならない。
− 最大四つのトラックが並行して“予約”状態になることが可能である。
− 複セション・複ボーダ記録は，疑似上書きと一緒に使用してはならない。
6.15.4 UDF処理システムに関する実装特記事項
− 初期化済み媒体が上書き可能かどうかを判断するために，ドライブに問い合わせる。初期化時に（UDF
処理システム方針に従って）媒体の疑似上書き属性をセットする。
− 以前に未記録であるセクタにデータを書き込むには，トラック内のNWAを確定するためにドライブ
に問い合わせる必要がある。戻り値は，絶対論理セクタ番号（ボリューム空間のLSN 0に対する相対）
になる。
− 削除と印付けられたファイルに以前に割り付けられたセクタの再利用を企てない。
− 上書きされるデータの総量を最小化する。
− 新たな予約トラックを（既存の予約トラックを分割することによって）割り付けるより前に，データ・
メタデータのために予約された現在のトラックを必ず“使用済み”の状態にする。
− メタデータファイル及びメタデータ控えファイルは，一つのトラックに一つ以上のエクステントをも
つことができる。これらのファイルのエクステントは，そのセクタの一部がドライブによって疑似上
書き又は欠陥管理に使われることがあるため，事前に割り付けないことが望ましい。
6.16 Blu-ray Disc媒体に関する勧告
この規定は，Blu-ray Disc（BD）媒体に関するボリューム及びファイル構造の要件及び勧告を定義し，
コンピュータシステムと家電との間でのデータ交換を支援する。これらの要件は，ディスクの使用がコン
ピュータシステムに限られ，しかも家電との交換性を提供する必要のない場合には，適用されない。BDAV
予
備
領
域
ボ
リ
ュ
ー
ム
構
造
メ
タ
デ
ー
タ
フ
ァ
イ
ル
F
E
フ
ァ
イ
ル
集
合
記
述
子
F
E
(
ル
ー
ト
デ
ィ
レ
ク
ト
リ
)
A
V
D
P
予
備
領
域
メ
タ
デ
ー
タ
複
製
フ
ァ
イ
ル
F
E
ボリューム空間
トラック1
（使用済み）
トラック2
（使用済み）
トラック3
（使用済み）
トラック6
（使用済み）
メタデータファイルのエクステント
未
記
録
領
域
トラック5
（予約）
メタデータファイルのエクステント
..
F
E
(
デ
ー
タ
A
)
F
E
(
デ
ー
タ
B
)
デ
ー
タ
A
デ
ー
タ
B
ル
ー
ト
デ
ィ
レ
ク
ト
リ
F
E
(
デ
ー
タ
C
)
..
..
デ
ー
タ
C
未
記
録
領
域
トラック4
（予約）
128
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
及びBDMVアプリケーション処理に関係する特定要件は，6.16.4に示す。
Blu-ray Discには，次の3種類の媒体がある。
a) 再生専用Blu-ray Discフォーマット（BD-ROM），特記事項参照。
b) 書換形Blu-ray Discフォーマット（BD-RE）
c) 追記形Blu-ray Discフォーマット（BD-R）
BD-Rは，LOWありSRM又はLOWなしSRMのどちらかで使用可能とする，詳細については6.16.3を
参照。BD-ROM，BD-RE及びLOWなしSRMを使用するBD-Rは，全てUDF 2.50版を使用する。LOWあ
りSRMを使用するBD-Rは，UDF 2.50版ではなく，UDF 2.60版を使用する。
これらの3種類の媒体に共通する特徴及び要件を次に示す。
a) 論理セクタ長は2 048バイトとする。
b) ECCブロック長は65 536バイト（64 KB）とする。
c) 予備区画マップ及び予備表は記録してはならない。
d) 割付け禁止空間ストリームは記録してはならない。
特記事項 容量4.7 Gバイト又は8.5 Gバイトのディスク上に“BDMVアプリケーション”を規定し
た，再生専用Blu-ray Discフォーマットがある。そのECCブロック長は32 768（32 KB）
である。これ以外のこのフォーマットに対する全ての要件はBD-ROMと同様である。
6.16.1 再生専用Blu-ray Discフォーマット（BD-ROM）に関する要件
再生専用Blu-ray Disc（BD-ROM）は再生専用形媒体とする，特記事項参照。
BD-ROMファイルシステムフォーマットはUDF 2.50に従わなければならず，かつ，次の追加の要件を
伴う。
ボリューム構造に関する要件を次に示す。
a) 区画記述子アクセス種別は1（再生専用）でなければならない。
b) 三つの開始ボリューム記述子ポインタ（AVDP）が記録されることが望ましい。
ファイル構造に関する要件を次に示す。
c) 未割付け空間表及び未割付け空間ビットマップは記録してはならない。
d) メタデータビットマップファイルは記録してはならない。
特記事項 メタデータファイルのデータの複製は任意選択とする。堅ろう（牢）性が要求される場合，
複製が用いられ，かつ，メタデータファイル及び複製メタデータファイルのデータと記述
子とは，物理的に内側の環状領域と外側の環状領域とにそれぞれ記録されることが推奨さ
れる。
6.16.2 書換形Blu-ray Discフォーマット（BD-RE）に関する要件
書換形Blu-ray Disc（BD-RE）は書換形媒体とする。BD-REドライブは，必要に応じて読出し修正書込
みの動作を行う。欠陥のない論理空間が，線形置換えアルゴリズムを実行するBD-REドライブによって提
供される。
BD-REファイルシステムフォーマットは，UDF 2.50に従わなければならず，かつ，次の追加の要件を伴
う。
ボリューム構造に関する要件を次に示す。
a) 区画記述子アクセス種別は4（上書き可能）でなければならない。
ファイル構造に関する要件を次に示す。
b) 未割付け空間ビットマップを記録しなければならず，未割付け空間表を記録してはならない。
129
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
特記事項1 メタデータファイルのデータの複製は任意選択とする。利用者が書込み性能より堅ろう
（牢）性を要求する場合，複製が用いられ，かつ，メタデータファイル及び複製メタデ
ータファイルのデータと記述子とは，物理的に内側の環状領域と外側の環状領域とにそ
れぞれ記録されることが推奨される。
欠陥管理への要件を次に示す。UDFファイルシステムが要求するドライブシステムによるドライブ欠陥
管理どおりに，BD-REディスクには予備領域が割り当てられなければならない。一般に，デフォルトのサ
イズの予備領域が初期化時に割り当てられる。
特記事項2 予備領域の利用可能なクラスタが枯渇した場合，全てのデータを別の媒体に退避した後
に，追加の予備領域を割り付けることが可能である。他方，特別なユーティリティツー
ルが，ボリューム空間を切り詰めるのに必要なディスク上の幾つかのファイルのデータ
とボリューム構造を移動できれば，ファイルのデータをディスク上に保ったまま予備領
域を拡張できる。
6.16.3 追記形Blu-ray Discフォーマット（BD-R）に関する要件
追記形Blu-ray Disc（BD-R）は追記形媒体であり，逐次記録モード（SRM）を論理上書きモード（LOW）
あり又はなしのどちらででも使用できる。ドライブによる線形置換えアルゴリズムを使用した欠陥管理を
利用できる。LOWありSRMを使用して初期化されたBD-R媒体には，6.15に示す疑似上書き（POW）方
式を適用できる。
BD-Rファイルシステムフォーマットは，LOWありSRM（POW）はUDF 2.60に従わなければならず，
LOWなしSRM（非POW）はUDF 2.50に従わなければならない。次に示す追加の要件が適用される。
ボリューム構造に関する要件を次に示す。
a) LOWありSRMでは，区画記述子アクセス種別は0（疑似上書き可能）でなければならない。
b) LOWなしSRMでは，区画記述子アクセス種別は1（再生専用）又は2（追記）でなければならない。
ファイル構造に関する要件を次に示す。
c) 未割付け空間表及び未割付け空間ビットマップを記録してはならない。
d) ICB方策種別4だけを使用しなければならない。
欠陥管理への要件を次に示す。LOWありSRM（POW）で初期化されたBD-R媒体には，予備領域が割
り当てられなければならない。一般に，デフォルトのサイズの予備領域が初期化時に割り当てられる。
6.16.4 AVアプリケーションについての情報
Blu-ray Discフォーマットには“BDAVアプリケーション（BDAV Application）”及び“BDMVアプリケ
ーション（BDMV Application）”の2種類のAVアプリケーションフォーマットがある。
− BDAVアプリケーション用についての情報を次に示す。
“BDAVアプリケーション（BDAV Application）”は，BD-REディスク及びBD-Rディスクのための動画
記録フォーマットであり，AVストリーム及びAVストリームの再生のためのデータベースを含む。
ルートディレクトリの直下の“BDAV”，“BDAV1”，“BDAV2”，“BDAV3”，及び“BDAV4”ディレクト
リがBDAVアプリケーションのために予約されている。
− BDMVアプリケーション用についての情報を次に示す。
“BDMVアプリケーション（BDMV Application）”は，BD-ROMディスクのための動画アプリケーショ
ンのフォーマットであり，AVストリーム及びAVストリームの再生のためのデータベースを含む。また，
インタラクティブなアプリケーションの証明が利用できる。
ルートディレクトリの直下の“BDMV”及び“CERTIFICATE”ディレクトリがBDMVアプリケーショ
130
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ンのために予約されている。
6.16.4.1 BDAV及びBDMVのアプリケーションの使用方法に対する要件
次のBDAV及びBDMVアプリケーション処理に対する追加の要件が適用される。
a) 一つのボリューム集合が一つだけのボリュームから構成されなければならない。
b) 一つだけの優勢な区画記述子がボリューム識別子列に記録されなければならない。
c) メタデータ区画マップが記録されなければならない。
d) 全てのファイル及びディレクトリにシンボリックリンクを使用してはならない（ICBのファイル種別
欄の値は12であってはならない）。
e) 全てのファイル及びディレクトリにハードリンクを使用してはならない。
f)
複セション及びVAT記録を使用してはならない。
6.17 UDF媒体フォーマット改正履歴
表47は，媒体に記録できるUDFフォーマットに影響するUDF定義の変更がいつ行われたかを示す。各
変更を示す文書変更通知（DCN）が表中に記入してある。変更UDF版数の欄には，変更を含むUDF規定
の版数を示す。UDF読出し最小版数及びUDF書込み最小版数の欄は，2.2.6.4で記載する版数アクセス制
御欄に関連する。
表47−改正履歴
記述
DCN
変更UDF
版数
UDF読出し
最小版数
UDF書込み
最小版数
UDF 1.02
割付けエクステント記述子
2-002
1.02
1.02
1.02
パス要素ファイル版数
2-003
1.02
1.02
1.02
親ディレクトリエントリ
2-004
1.02
1.02
1.02
装置仕様拡張属性
2-005
1.02
1.01
1.02
最大論理エクステント長
2-006
1.02
1.02
1.02
未割付け空間エントリ
2-008
1.02
1.01
1.02
DVD著作権管理情報
2-009
1.02
1.02
1.02
論理ボリューム識別子
2-010
1.02
1.01
1.02
割付け記述子のエクステント長欄
2-012
1.02
1.01
1.02
再配置禁止フラグ及び連続フラグ
2-013
1.02
1.01
1.02
DVD-ROMに対する要件の改版
2-014
1.02
1.02
1.02
版数アクセス制御
2-015
1.02
1.01
1.02
ボリューム集合識別子
2-017
1.02
1.01
1.02
拡張IDの一意属性
2-018
1.02
1.02
1.02
dstringの明確化
2-010
1.02
1.01
1.02
アプリケーションFreeEASpace拡張属性
2-020
1.02
1.02
1.02
識別子添字の1.02への変更
2-021
1.02
1.02
1.02
UDF 1.50
識別子添字の1.50への変更
2-025
1.50
1.50
1.50
仮想区画マップエントリ
2-026
1.50
1.50
1.50
予備区画マップの割付け
2-027
1.50
1.50
1.50
仮想割付け表の追加
2-028
1.50
1.50
1.50
予備表の追加
2-029
1.50
1.50
1.50
割付け禁止空間リストの追加
2-030
1.50
1.02
1.50
CD媒体の推薦
2-031
1.50
1.50
1.50
131
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表47−改正履歴（続き）
記述
DCN
変更UDF
版数
UDF読出し
最小版数
UDF書込み
最小版数
UDF 2.00
1.50から2.00への変更
2-033
2.00
1.02
2.00
明確化されたドメインフラグ
2-034
2.00
1.02
2.00
Unicode2.0の利用
2-035
2.00
1.02
2.00
名前付きストリーム
2-036
2.00
2.00
2.00
名前付きストリームとしての一意ID表
2-037
2.00
1.02
2.00
名前付きストリームとしてのMacリソースフォーク
2-038
2.00
2.00
2.00
拡張属性ヘッダの位置欄
2-043
2.00
1.02
2.00
アクセス管理リスト
2-044
2.00
2.00
2.00
ブロック境界にまたがる記述子タグ
2-047
2.00
1.02
2.00
パワーこう（較）正ストリーム
2-048
2.00
1.02
2.00
要求されるCD-R複セションの提供
2-050
2.00
1.50
2.00
CD-Rの仮想区画用LVIDの欄の値
2-051
2.00
1.50
2.00
ボリュームバックアップ日時を示すシステムストリーム
2-055
2.00
2.00
2.00
新VAT
2-056
2.00
2.00
2.00
制約的仮想番地
2-057
2.00
1.50
2.00
ファイル日時拡張属性
2-058
2.00
1.02
2.00
OS/2 EAストリーム
2-061
2.00
2.00
2.00
割付け禁止空間ストリーム
2-062
2.00
1.02
2.00
UDF 2.01
タグ通し番号及び障害回復
5000
2.01
1.02
1.02
DOSの名前の翻訳アルゴリズムの変更
5002
2.01
−
1.02
二つの名前空間でのディレクトリを探す順序
5004
2.01
1.02
1.02
方策種別4 096での終了条件の明確化
5006
2.01
1.02
1.02
圧縮識別子254及び255の明確化
5007
2.01
2.00
2.00
Mac資源フォークはファイルだけに存在する
5008
2.01
2.00
2.00
CD媒体での要件
5009
2.01
1.50
1.50
AVDPの配置
5013
2.01
1.50
1.50
再配置不可ビットの明確化
5014
2.01
1.02
1.02
種々の編集上の修正
5015
2.01
−
−
パワーこう（較）正ストリームの修正
5018
2.01
2.00
2.00
システムストリームディレクトリの親
5019
2.01
2.00
2.00
OS/400に関する更新
5020
2.01
2.00
2.00
欠落した実体識別子の定義
5021
2.01
2.00
2.00
種々の編集上の修正
5024
2.01
−
−
新規のOS種別
5025
2.01
2.00
2.00
PVDのアプリケーション識別子欄の明確化
5026
2.01
1.02
1.02
記述子CRC長
5027
2.01
1.02
1.02
POSIXの許可条件の明確化
5029
2.01
2.00
2.00
ボリューム認識列
5031
2.01
1.02
2.00
パス長
5032
2.01
1.02
1.02
FIDの処理システム用長（LengthOfImplementationUse）欄
5034
2.01
1.02
1.02
編集上の修正−割付け禁止空間ストリーム
5035
2.01
−
−
割付けエクステント記述子のCRC長
5036
2.01
2.00
2.00
248〜255のファイル種別
5037
2.01
2.00
2.00
DVD-RAM上のReal-Timeファイル
5038
2.01
2.00
2.00
132
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表47−改正履歴（続き）
記述
DCN
変更UDF
版数
UDF読出し
最小版数
UDF書込み
最小版数
パケット長の規定
5039
2.01
2.00
2.00
相反する欄をもつ重なり合う構造
5040
2.01
2.00
2.00
情報の長さの再構成
5041
2.01
2.00
2.00
時間帯の解釈
5042
2.01
1.02
1.02
欠落した区画記述子及び予備区画
5044
2.01
1.02
1.02
基本制約及び基本要件の区画記述子の訂正
5045
2.01
1.50
1.50
PVD及びLVDのボリューム順序番号
5046
2.01
1.02
1.02
5.1記述子長の表への追加
5047
2.01
2.00
2.00
EA及びストリームでの一意IDの使用の明確化
5048
2.01
2.00
2.00
UDF 2.50
FIDのファイル識別子長及びユニコードの一意性
5049
2.50
1.02
2.01
重なり合う区画の禁止
5061
2.50
1.02
1.02
方策種別4 096は追記形媒体だけに許される
5062
2.50
1.02
1.02
UDF一意IDマッピングデータ
5063
2.50
2.50
2.50
拡張属性ブロック境界
5064
2.50
1.02
1.02
UDF定義名前付きストリームの細分箇条
5065
2.50
2.00
2.00
ファイル識別子翻訳コードの修正
5066
2.50
1.02
1.02
ソフト書込み保護の規定の修正
5069
2.50
2.00
2.00
ディレクトリのハードリンクの禁止
5070
2.50
1.02
2.50
DVD-R，DVD-RW及びDVD-RAMの交換可能性に関する
要件
5071
2.50
2.00
2.00
システムストリームディレクトリの一意ID
5072
2.50
2.50
2.50
LVID及びVATの欄の共通記述
5074
2.50
2.01
2.01
マウントレイニアフォーマット媒体に関する勧告
5075
2.50
1.02
1.02
DVD+R及びDVD+RWに関する勧告
5076
2.50
1.50
1.50
3.3.5の削除
5077
2.50
2.00
2.00
UDF一意IDの明確化
5078
2.50
2.00
2.00
区画アクセス種別3及び4の明確化
5079
2.50
2.01
2.01
ICBタグの親ICB位置の問題
5081
2.50
1.02
2.50
ボリューム識別列の明確化
5082
2.50
1.02
2.01
メタデータ区画マップ
5086
2.50
2.50
2.50
区画境界及びECCブロック長の定義
5089
2.50
1.02
2.50
割付け禁止空間ストリーム使用法の明確化
5090
2.50
1.50
1.50
UDF 2.60
UDF 2.50以降の編集上の修正
5100
2.60
−
−
仮想，メタデータ，再生専用区画
5101
2.60
2.50
2.50
メタデータビットマップファイルを再生専用形に記録し
てはならない
5102
2.60
2.50
2.50
メタデータファイル及び控えファイルの同一性
5103
2.60
2.50
2.50
メタデータファイル及びメタデータ控えファイルの次エ
クステント
5104
2.60
2.50
2.50
メタデータ区画の終端記述子
5105
2.60
2.50
2.50
メタデータ控えファイルのFE及びAEDは分離して配置
される
5106
2.60
2.50
2.50
区画及び予備表の重なり合いの明確化
5107
2.60
1.50
1.50
記述子CRC長のUint16の桁あふれの規則
5108
2.60
1.02
1.02
133
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表47−改正履歴（続き）
記述
DCN
変更UDF
版数
UDF読出し
最小版数
UDF書込み
最小版数
2.2.13の特記事項の明確化
5109
2.60
2.50
2.50
OS識別子のUNIXへのNetBSDの追加
5110
2.60
1.02
1.02
疑似上書き可能機構
5111
2.60
2.60
2.60
UDF 2.50の非POWのBD媒体への勧告
5112
2.60
2.50
2.50
主ボリューム記述子列及び予備ボリューム記述子列は分
離して配置される
5113
2.60
2.50
2.50
BD-RのUDF 2.60への勧告
5114
2.60
2.60
2.60
POWをUDF 2.50で読出し可能にする
5115
2.60
2.50
2.50
疑似上書き可能方式の導入による変更
5116
2.60
2.60
2.60
異なる媒体への記録での共通側面
5117
2.60
2.01
2.01
区画ヘッダ記述子の位置の明確化
5118
2.60
1.02
1.02
割付け禁止空間ストリームの情報長は0
5119
2.60
2.60
2.60
UDF 2.60媒体の読出し最小版数
5120
2.60
2.60
2.60
親FIDのディレクトリビットの明確化
5121
2.60
2.00
2.00
HD DVDディスクに関する要件
5154
x.yz
2.50
2.50
拡張ファイルエントリのより重要な役割
5160
x.yz
2.00
2.00
固定パケットをECCブロックと同じに扱う
5161
x.yz
1.50
1.50
注記 x.yzは2.60より後の次のUDFの版を示す。
6.18 開発者登録フォーム
このJISでは規定しない。
6.19 DVD-R DL LJR（マルチボーダ記録）に関する勧告
DVD-R DL LJRは，MMC規定及びMt Fuji規定に示される，層ジャンプ記録（Layer Jump Recording, LJR）
と呼ばれる新しい記録方式を導入する。この新しい記録方式は，インクリメンタル記録方式と類似してい
るが幾分異なる。予約Rゾーン及びDVD-R DL LJRの層ジャンプブロック（Layer Jump Block, LJB）は，
一つのUDFトラックの定義に適合しないが，二つの論理トラックに適合する。その結果，ボーダはUDF
のセションの定義に適合しない。LJRは，開始点セクタに再配置する可能性も導入する。副セションUDF
は，そのままではDVD-R DL LJRに適用できない，そのため6.19では，DVD-R DL LJR上の副ボーダ及び
副セションの記録の実行方法を示す。
この規定は，DVD-R DL LJR媒体に関するボリューム及びファイル構造の勧告を定義し，コンピュータ
システムのユーザ間でのデータ交換を支援する。
a) ボリューム及びファイル構造はUDF 2.00に従わなければならない。
b) UDF読出し最小版数及びUDF書込み最小版数は2.00でなければならない。
c) 論理セクタ長及び論理ブロック長は2 048バイトでなければならない。
さらに，DVD-R DL LJRには次の追加の勧告が適用される。
DVD-R DL LJRは通常のセションの規定に従わない。DVD-R DL LJRでは各ボーダの始まりは通常と同
じに，新規のセションの始まりと関連する。しかし各セションの終わりは常に各ディスクの終わりである。
これによる重なり合うセションは，1.3.2によるセションの定義に厳密には従っていない。
DVD-R DL LJRは固定長の媒体である。各Rゾーンは一つ以上のLJBを含む。各RゾーンはREAD TRACK
INFORMATION命令に（物理）トラック数1を返すが，UDFの処理系はLJBごとに，層0に一つと層1
に一つの二つの論理トラックがあると考えなければならない。論理トラックの境界は次層ジャンプ番地
134
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
（Next Layer Jump Address）で示される現在のRゾーンのNWAを含む。
（層1上の）2番目の論理トラックの開始番地の計算式はMt. Fuji規定にある。ファイルは層0又は1
の各々のトラックで始まり，層1又は0の各々のトラックへ続く。このためUDFの処理系は関連するファ
イルのエクステントの書込みに留意しなければならない。
DVD-ROMドライブへの互換性のため，UDF処理系はボーダを閉じなければならない。
6.19.0 DVD-R DL LJRの特徴
再配置を使用するDVD-R DL LJRは6.11の勧告とは若干異なる。
6.11.3の複セションの使用方法との相違点は次の点である。
a) 第一セションの後，論理セクタ番号256，N−256及びNのうち少なくとも2か所にAVDPがあり，更
に少なくとも以前のセションに再配置されたAVDPは，最後のセションから再配置されている。最終
セションの位置タグ256，N−256又は／及びNをもつAVDPの書込みには再配置が必要となるため，
ドライブにSEND DISC STRUCTUREコマンドの再配置番地（フォーマットコード = 24h）で開始点
番号（Anchor Point Number）2，3又は／及び4を各々256，N−256又は／及びNに用いて，再配置を
指示する。
b) 第一セションの後，AVDPのうち少なくとも二つが論理セクタ番号S＋256，C−256，Cに書き込まれ
る。Cは最終セションのLRAである。
6.20 HD DVDディスクに関する要件
この規定は，コンピュータシステムと家電のユーザとの情報交換のために，HD DVD-ROMディスク
（6.20.1参照），HD DVD-RAMディスク（6.20.2参照），及びSL/DLのHD DVD-Rディスク（6.20.3参照）
を含むがそれに限らない，HD DVD媒体に対するボリューム構造及びファイル構造の要件及び制約を規定
する。これらの要件はコンピュータシステム環境だけで使われ，家電との交換性のないディスクには適応
されない。
これらのHD DVDディスクに対する共通の要件を，次に示す。
a) ボリューム及びファイル構造はUDF 2.50に従わなければならない。
b) 論理セクタ長及び論理ブロック長は2 048バイトでなければならない。
c) ECCブロック長は32セクタ（64 KB）とする。
d) 一つの主ボリューム記述子列及び一つの予備ボリューム記述子列が記録されなければならない。
e) HD DVDディスクは一面当たり単一の区画記述子をもつ単一のボリュームをもたなければならない。
そのため，ボリューム順序番号は1でなければならず，最大ボリューム順序番号は1でなければなら
ない。さらに，基本ボリューム記述子の交換水準は2でなければならない。
f)
ICB方策種別4だけが使用されなければならない。
6.20.1 HD DVD-ROMに関する要件
ボリューム及びファイル構造は再生専用形ディスクとして単純化されている。
ボリューム構造に関する要件を，次に示す。
a) HD DVD-ROMディスクの区画は，アクセス種別1で指定される再生専用区画でなければならない。
b) 開始ボリューム記述子ポインタの一つが論理セクタ256に記録されていることが望ましい。
c) ボリューム記述子列のエクステントに終端のための終端記述子が記録されなければならない。
d) 未割付け空間表及び未割付け空間ビットマップは記録してはならない。
e) 予備区画マップ及び予備表は記録してはならない。
f)
仮想区画マップは記録してはならない。
135
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
g) メタデータ区画マップ，メタデータファイル及びメタデータ控えファイルが記録されなければならな
い。メタデータビットマップファイルは記録してはならない。
ファイル構造に関する要件を，次に示す。
HD DVDディスクに対する共通の要件が適用されなければならない。
6.20.2 HD DVD-RAMに関する要件
ボリューム及びファイル構造は非逐次記録を用いる上書き可能形ディスクとして単純化されている。
ボリューム構造に関する要件を，次に示す。
a) HD DVD-RAMディスクの区画は，アクセス種別4で指定される上書き可能区画でなければならない。
b) 予備区画マップ及び予備表は記録してはならない。
c) 仮想区画マップは記録してはならない。
d) メタデータ区画マップ，メタデータファイル及びメタデータビットマップファイルが記録されなけれ
ばならない。
ファイル構造に関する要件を，次に示す。
e) 割付け禁止空間ストリームは記録してはならない。
6.20.3 SL/DLのHD DVD-Rに関する要件
SL/DLのHD DVD-Rディスクに対する要件は，データ更新可能な構造（VAT）によるものであるか，HD
DVD-ROM互換の構造によるものである。ボリューム構造及びファイル構造は逐次記録を用いる追記形の
ディスクとして単純化されている。
HD DVD-ROM互換の構造の場合は，要件はHD DVD-ROMのためのものと同じである。6.20.1を参照。
HD DVD-R DLでは単一セションだけが利用可能である。
データ更新可能な構造（VAT）の場合は，次に示す要件が適用される。
ボリューム構造に関する要件を，次に示す。
a) 区画は，アクセス種別2で指定される追記形区画でなければならない。
b) 未割付け空間表，未割付け空間ビットマップは記録してはならない。
c) 予備区画マップ及び予備表は記録してはならない。
d) 論理ボリューム保全列には開いた保全記述子は一つだけしか記録してはならない。
e) 仮想区画マップが記録されなければならない。そのため，メタデータ区画マップは記録してはならな
い。
ファイル構造に関する要件を，次に示す。
f)
ファイル集合記述子は一つだけしか記録してはならない。
g) 割付け禁止空間ストリームは記録してはならない。
h) 仮想割付け表及びVAT ICBが記録されなければならない。
i)
メタデータファイル，メタデータ控えファイル及びメタデータビットマップファイルは記録してはな
らない。
136
X 0614：2015
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書JA
（参考）
商標又は登録商標
この附属書（参考）は，この規格にある商標又は登録商標について記載するものであって，規定の一部
ではない。
この規格における商標又は登録商標は，次による。
a) Universal Disk Format及びUDFは，OSTAの米国における登録商標である。
b) Blu-ray及びBlu-ray Discは，Blu-ray Disc Associationの商標である。
c) IBM，OS/2及びOS/400は，IBM Corp.の米国及び／又はその他の国における商標又は登録商標である。
d) Macintosh，Mac OS及びOS Xは，Apple Inc.の米国及び／又はその他の国における商標又は登録商標
である。
e) UNIXは，The Open Groupの米国及び／又はその他の国における商標又は登録商標である。
f)
Microsoft，Windows及びMS-DOSは，Microsoft Corp.の米国及び／又はその他の国における商標又は
登録商標である。
この他にも商標又は登録商標があり得ることに注意を喚起する。
参考文献 JIS X 6250 120 mm（4.7 GB／面）及び80 mm（1.46 GB／面）＋RWフォーマット光ディスク
（4倍速まで）