JIS X 0613:2015 ユニバーサルディスクフォーマット(UDF)2.50 | ページ 4

                                                                                             13
X 0613 : 2015
ばならない値を示す。
表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識別子添字
“*UDF Virtual Partition”
仮想割付け表 処理システム用 “*Developer ID” 処理システム識別子添字
(任意選択)
予備区画マップ 区画種別識別子 “*UDF Sparable Partition” UDF識別子添字
予備表 予備識別子 “*UDF Sparing Table” UDF識別子添字
メタデータ区画マップ 区画種別識別子 “*UDF Metadata Partition” UDF識別子添字
注記 N/Aは,“規定しない”ことを示す。
特記事項1 表4の識別子値欄の値は,バイトの列として解釈し,CS0で規定するdstringとしては解
釈しない。UDFで容易に使用するために,この欄で使用する値は,ASCII文字列で指定
する。UDFで定義する実体識別子で使用するバイト列は,6.2で規定する。
特記事項2 表4の識別子値欄の“*Application ID”は,書込みを行ったアプリケーションを一意に識
別する識別子を示す。
表4の識別子値欄の“*Developer ID”は,現状の処理システムを一意に識別する実体識別子を示す。指

――――― [JIS X 0613 pdf 16] ―――――

14
X 0613 : 2015
定した値は,新しい記述子を作成するときに使用することが望ましい。規定した値は,指定した実体識別
子欄の有効範囲内で何かを更新する場合には,存在する記述子にも使用することが望ましい。
特記事項3 “*Developer ID”のために選択された値は,処理システムに関する社名及び製品名を識
別できるだけの情報を含むことが望ましい。例えば,DataOneというUDF製品をもつ
XYZという会社は,Developer IDとして“*XYZ DataOne”を選択してもよい。Developer
IDの添字においても,DataOne製品の現在の版数を記録することを選択してもよい。こ
の情報は,異なる会社の複数の製品が媒体に記録していた場合,どの処理システムが媒
体の一部に不適切な構造を書き込んだのかを決定するとき,非常に助けになる。
表4の添字種別欄は,相当する実体識別子で使用する添字のフォーマットを定義する。これらの異なる
添字種別は,以降で定義する。
特記事項4 この規格で定義する全ての識別子(6.1)は,UDF識別子としてOSTAによって登録され
ていなければならない。
2.1.5.3 識別子添字(char IdentifierSuffix[8])
識別子添字(IdentifierSuffix)欄のフォーマットは,識別子の種別に依存する。
この規格で規定するOSTA範囲実体識別子(6.1)に関しては,識別子添字欄は,表5に示す構成でなけ
ればならない。
表5−範囲識別子添字欄フォーマット(Domain Identifier Suffix field format)
RBP 長さ 名前 内容
0 2 UDF版数(UDF Revision) Uint16(= #0250)
2 1 範囲フラグ(Domain Flags) Uint8
3 5 予約(Reserved) バイト(= #00)
UDF版数(UDFRevision)欄は,この規格の対応団体規格の規定の版数2.50を示す値#0250を設定する。
この欄は,この規格の対応団体規格の規定の改正版に加えられた変更を,処理システムが検出することを
可能にする。OSTA範囲識別子は,論理ボリューム記述子及びファイル集合記述子だけに使用する。範囲
フラグ(Domain Flags)欄は,表6に示すビットフラグを定義する。
表6−範囲フラグ(Domain Flags)
Bit 意味
0 ハード書込み保護(Hard Write-Protect)
1 ソフト書込み保護(Soft Write-Protect)
27 予約(Reserved)
ソフト書込み保護(SoftWriteProtect)フラグは,利用者が設定可能なフラグであり,このフラグが存在
する記述子の有効範囲で,ボリューム構造又はファイルシステム構造が書込み保護されていることを示す。
ソフト書込み保護フラグの値が1の場合,利用者の書込み保護を示さなければならない。このフラグは,
利用者が設定及び解除してもよい。ハード書込み保護(HardWriteProtect)フラグは,処理システムが設定
可能なフラグであり,このフラグが存在する記述子の有効範囲で永久的な書込み保護を示さなければなら
ない。ハード書込み保護フラグの値が1の場合,永久的な書込み保護を示さなければならない。このフラ
グは,一度設定した場合解除してはならない。ハード書込み保護フラグは,ソフト書込み保護フラグに優
先する。

――――― [JIS X 0613 pdf 17] ―――――

                                                                                             15
X 0613 : 2015
書込み保護フラグは,論理ボリューム記述子及びファイル集合記述子の中に現れる。それらは次のとお
りに解釈しなければならない。
isfilesetwriteprotected = LVD.HardWriteProtect || LVD.SoftWriteProtect ||
FSD.HardWriteProtect || FSD.SoftWriteProtect
isfilesethardprotected = LVD.HardWriteProtect || FSD.HardWriteProtect
isfilesetsoftprotected = (LVD.SoftWriteProtect || FSD.SoftWriteProtect) &&
! isfilesethardprotected
isvolwriteprotected = LVD.HardWriteProtect || LVD.SoftWriteProtect
isvolhardprotected = LVD.HardWriteProtect
isvolsoftprotected = LVD.SoftWriteProtect && !LVD.HardWriteProtect
UDFで定義する実体識別子(6.1)に対しては,識別子添字欄は,表7に示す構成でなければならない。
表7−UDF識別子添字(UDF Identifier Suffix)
RBP 長さ 名前 内容
0 2 UDF版数(UDF Revision) Uint16(= #0250)
2 1 オペレーティングシステムクラス(OS Class)Uint8
3 1 オペレーティングシステム識別子(OS Identifier) Uint8
4 4 予約(Reserved) バイト(= #00)
オペレーティングシステムクラス(OS Class)及びオペレーティングシステム識別子(OS Identifier)欄
の内容は,6.3に規定する。
UDFで定義しない実体識別子に対しては,識別子添字欄は,表8に示す構成でなければならない。
表8−処理システム識別子添字(Implementation Identifier Suffix)
RBP 長さ 名前 内容
0 1 オペレーティングシステムクラス(OS Class)Uint8
1 1 オペレーティングシステム識別子(OS Identifier) Uint8
2 6 バイト
処理システム用領域(Implementation Use Area)
注記 OSクラス欄及びOS識別子欄の,意図した使用及び重要性を理解することが重要になる。これ
らの欄の主な目的は,UDFボリューム中で問題を検出したときに,誤りを取り除く支援をする
ことである。この欄は,利用者に提供可能な有効な情報も提供する。これらの二つの欄を正し
く設定した場合,処理システムに次の情報を提供する。
− 最後に特定の構造を更新したOSを識別する。
− 最後に特定のファイル又はディレクトリを更新したOSを識別する。
− 開発者が処理システムとともに複数OSを提供する場合,問題が発生したOSを決定する支
援をする。
UDFで定義しないアプリケーション実体識別子に対しては,識別子添字(IdentifierSuffix)欄は,特記し
ない限り,表9に示す構成としなければならない。

――――― [JIS X 0613 pdf 18] ―――――

16
X 0613 : 2015
表9−アプリケーション識別子添字(Application Identifier Suffix)
RBP 長さ 名前 内容
0 8 バイト
処理システム用領域(Implementation Use Area)
2.1.6 初期化時の記述子タグ通し番号(Descriptor Tag Serial Number at Formatting Time)
障害回復に対応するため,全てのUDF記述子のタグ通し番号(TagSerialNumber)は初期化時に記録さ
れ,ボリュームの再初期化時には,以前に記録した値と異なる値を設定しなければならない。
障害回復が対応されない場合は,全てのUDF記述子のタグ通し番号欄には,初期化時に値0(#0000)
を記録しなければならない([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[{
Uint16 TagIdentifier;
Uint16 DescriptorVersion;
Uint8 TagChecksum;
byte Reserved;

――――― [JIS X 0613 pdf 19] ―――――

                                                                                             17
X 0613 : 2015
Uint16 TagSerialNumber;
Uint16 DescriptorCRC;
Uint16 DescriptorCRCLength;
Uint32 TagLocation;
}]
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[{
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 charspecDescriptorCharacterSet;
struct charspecExplanatoryCharacterSet;
struct extentadVolumeAbstract;
struct extentadVolumeCopyrightNotice;
struct EntityIDApplicationIdentifier;
RecordingDateandTime;
struct timestamp
struct EntityIDImplementationIdentifier;

――――― [JIS X 0613 pdf 20] ―――――

次のページ PDF 21

JIS X 0613:2015の国際規格 ICS 分類一覧

JIS X 0613:2015の関連規格と引用規格一覧

規格番号
規格名称