所以这可能有点太具体了，任何人都无法阅读，任何人都无法提供帮助。但也许有人以前做过这件事。
我目前正在使用可靠但不是很准确的 libdvdread 库来读取 ISO 文件/设备。但在这种情况下，具体的实现并不那么重要。更多关于如何读取 UDF 文件系统的内容。我已经阅读了很多 Ecma-167 和 udf260 PDF 文件。
因此，首先，让我们看一下来自 IMGBURN 的 ISO 映像，它似乎可以正常工作，就像从零售蓝光复制的映像一样。
块布局如下：
Block 32 TagID: 1 TAGID_PRI_VOL
Block 33 TagID: 4 TAGID_IMP_VOL
Block 34 TagID: 5 TAGID_PARTITION
Block 35 TagID: 6 TAGID_LOGVOL
Block 36 TagID: 7 TAGID_UNALLOC_SPACE
Block 37 TagID: 8 TAGID_TERM
Block 64 TagID: 9 TAGID_LOGVOL_INTEGRITY
Block 65 TagID: 8 TAGID_TERM
Block 256 TagID: 2 TAGID_ANCHOR
Block 288 TagID: 266 TAGID_EXTFENTRY
Block 320 TagID: 256 TAGID_FSD
Block 321 TagID: 8 TAGID_TERM
Block 322 TagID: 266 TAGID_EXTFENTRY
Block 323 TagID: 257 TAGID_FID
Block 324 TagID: 266 TAGID_EXTFENTRY
Block 325 TagID: 266 TAGID_EXTFENTRY
Block 326 TagID: 257 TAGID_FID
Block 327 TagID: 266 TAGID_EXTFENTRY
所以我们开始读取 ISO 镜像；
* Read Block 256 which is 2 TAGID_ANCHOR
* Read Block 32 which is 1 TAGID_PRI_VOL
* Read Block 33 which is 4 TAGID_IMP_VOL
* Read Block 34 which is 5 TAGID_PARTITION
Partiton: number 0, start 288, length 2291200, AccessType 1
* Read Block 35 which is 6 TAGID_LOGVOL
LogVolume 2048:70:2
Volume 0 type 01 (len 6) Seq 0001 Part 0000
Volume 1 type 02:
Partition identifier: '*UDF Metadata Partition'
Metadata Partition MainLoc 00000000, MirrorLoc 0022F5A9, BitmapLoc FFFFFFFF, AllocSize 00000020, AlignSize 0020, Flags 1.
returning Start 288
Found partition at 288 length 2291200
Starting scan from 288 (metadata adjusted)
到目前为止，一切都很好。你可以看到我取“元数据主文件位置”，在这个例子中是0，并将它添加到分区开始，去寻找FSD。这似乎适用于“元数据主文件位置”不为 0 的示例。稍后会详细介绍。
现在寻找FSD，我们找到的第一个项目是：
* Read Block 288 which is 266 TAGID_EXTFENTRY
TagID 266 with filetype 250
Metadata Main at location 32 (+partition.start 320)
Ecma-167 定义 filetype=250 具有“元数据主文件”，并且 AD.Location 指向元数据。也有可能找到一个filetype=251（元数据镜像文件）
我使用“元数据主文件”位置（此处为 32）作为“真正”查找 FSD 的位置的间接指针。出于某种原因，这是 partition.Start + Location (288 + 32) = 320。
在块 320，我们找到了 FSD。所以也许我在正确的轨道上。
Now Scanning from 320
* Read Block 320 which is 256 TAGID_FSD
RootICB at 2 length 2048
MapICB starting at 320,2 -> 322
太好了，我们阅读了 FSD，它的 RootICB 位于“+2”。现在我本来希望这是“partition.Start + 2”（288+2），但这不起作用。起作用的是“FSD_Location + 2”（320+2）。真的可以这样吗？
在 DVD ISO 中，FSD_Location=0（分区上的第一个块，因为没有 EXTFileInfo+250 的方式），所以使用这个逻辑仍然有效。
让我们假设它是正确的；
* Read Block 322 which is 266 TAGID_EXTFENTRY
libdvdread: reading AD chain 0
UDFMapICB TagID 266 ExtFile with filetype 4
Part.Start 288 FSD loc 320 RootICB 2 (len 2048) File has loc 3
因此，322 处的块确实是一个 ExtFileInfo，文件类型 ==4（目录）并且位于位置 = +3。同样，这似乎是“fsd_location + 3”= 323。
Found '/' at 323 (size 152).
* Read Block 323 which is 257 TAGID_FID
DVDReadDir(.)
DVDReadDir(BDMV)
etc
成功。它列出了所有内容。
这是我感到困惑的地方。我使用 OSX“newfs_udf”为自己创建一个 UDF 测试图像；
# mkfile 1G roger.iso
# newfs_udf -eu -r 2.60 -v HIGHLANDER roger.iso
# hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount roger.iso
# hdiutil mount -nobrowse roger.iso
# mkdir /Volumes/HIGHLANDER/A.DIRECTORY.ENTRY
这些块是：
Block 20 TagID: 1 TAGID_PRI_VOL
Block 21 TagID: 4 TAGID_IMP_VOL
Block 22 TagID: 5 TAGID_PARTITION
Block 23 TagID: 6 TAGID_LOGVOL
Block 24 TagID: 7 TAGID_UNALLOC_SPACE
Block 25 TagID: 8 TAGID_TERM
Block 36 TagID: 9 TAGID_LOGVOL_INTEGRITY
Block 37 TagID: 8 TAGID_TERM
Block 256 TagID: 2 TAGID_ANCHOR
Block 257 TagID: 264 TAGID_SPACE_BITMAP
Block 289 TagID: 266 TAGID_EXTFENTRY
Block 290 TagID: 266 TAGID_EXTFENTRY
Block 291 TagID: 256 TAGID_FSD
Block 292 TagID: 266 TAGID_EXTFENTRY
Block 293 TagID: 266 TAGID_EXTFENTRY
Block 294 TagID: 266 TAGID_EXTFENTRY
Block 295 TagID: 266 TAGID_EXTFENTRY
Block 296 TagID: 266 TAGID_EXTFENTRY
Block 323 TagID: 264 TAGID_SPACE_BITMAP
Block 449 TagID: 259 TAGID_INDIRECTENTRY
阅读这个 ISO 也很有效，至少在最初是这样。
* Read Block 256 which is 2 TAGID_ANCHOR
* Read Block 20 which is 1 TAGID_PRI_VOL
* Read Block 21 which is 4 TAGID_IMP_VOL
* Read Block 22 which is 5 TAGID_PARTITION
Partiton: number 0, start 257, length 523774, AccessType 4
* Read Block 23 which is 6 TAGID_LOGVOL
LogVolume 2048:70:2
Volume 0 type 01 (len 6) Seq 0001 Part 0000
Volume 1 type 02:
Partition identifier: '*UDF Metadata Partition'
Metadata Partition MainLoc 00000020, MirrorLoc 0007FDFD, BitmapLoc 00000021, AllocSize 00000020, AlignSize 0001, Flags 0.
returning Start 257
Found partition at 257 length 523774
Starting scan from 289 (metadata adjusted)
* Read Block 289 which is 266 TAGID_EXTFENTRY
TagID 266 with filetype 250
Metadata Main at location 34 (+partition.start 291)
* Read Block 291 which is 256 TAGID_FSD
RootICB at 1 length 2048
* Read Block 292 which is 266 TAGID_EXTFENTRY
UDFMapICB TagID 266 ExtFile with filetype 4
Part.Start 257 FSD loc 291 RootICB 1 (len 2048) File has loc 34
注意这里的元数据分区是+32，加上我们正确地找到了ExtFileInfo+Filetype=250。然后是 +34，这正确地让我们获得了 FSD！
FSD 的 RootICB 为 +34，同样来自 FSD，即 291+34 = 325。
它丢失了。我猜应该是 292，但是；
...在阻止列表中，您可以看到根本没有 FID。查看此 ISO 映像的 hexdump，可以在块 292 中找到“A.DIRECTORY.ENTRY”。这是一个 ExtFileEntry。正是那个让我们去寻找元数据主文件位置的那个。
我认为 ExtFileInfo 仅包含一 (1) 个文件描述符，其中 ICB 指向其数据。然而，在偏移量 +380 左右的这个块内，我们有 root (null)、“A.DIRECTORY.ENTRY”和“.Trashes”。
我想我的问题是，OSX 是否以某种方式将 FID 压缩到 ExtFileEntry 中？并且没有 FID 块。这是“有效的”吗？如何检测这种情况？这个 ExtFileInfo 中是否有一些内容表明我应该“不按照位置查找 FID”和“继续解析这个块以获取更多条目”。
在计算 ICB 时，我必须对目录使用“fsd_location + icb.location”，但对于文件（读取实际文件数据），我必须使用“partition.Start + icb.location”。这按预期工作（目录列表和文件没有区别），但它似乎不正确。
如果你读了所有这些，你太棒了:) 现在，如果你能给我一些线索......