Apple的新文件系统APFS带来了测试文件名相等的新规则，它们与HFS不同。我正在寻找正确的方法来比较两个名称的相等性，特别是对于APFS，但为了完整性，为HFS +检查添加一个名称会很麻烦。
为什么呢？因为我需要能够判断我在目录中找到的文件名是否与某个模式匹配，例如包含某个子字符串。为此，我需要匹配文件系统和Finder用于比较名称的确切规则。
对于这些文件系统的区分大小写的变体，它非常简单，因为字节方式的比较就足够了，我相信（假设两个字符串都使用相同的编码）。
对于不区分大小写的HFS +，我认为甚至有一个特殊的比较选项，但我在NSStringCompareOptions中找不到这样的选项。我认为这是必要的，因为HFS +使用旧版本的Unicode标准。我引用了TN1150（遗憾的是，Apple网站上已经不再提供了它）：
Unicode细微之处
HFS Plus大量使用Unicode字符串来存储文件和文件夹名称。 然而，Unicode仍在不断发展，它在文件系统中的使用带来了许多挑战。本节介绍了一些挑战，以及HFS Plus使用的解决方案。
重要： 实现不得使用由其本机平台实现的Unicode实用程序（用于分解和比较），除非这些算法等同于此处定义的HFS Plus算法，并且保证永远如此。这种情况很少发生。 平台算法倾向于使用Unicode标准发展。 HFS Plus算法无法发展，因为这种演变会使现有的HFS Plus卷无效。
啊，关于获得所用编码的HFS +版本，我想到的部分是：
注意： Mac OS文本编码转换器提供了几个常量，使您可以转换为存储在HFS Plus卷上的规范分解形式。使用CreateTextEncoding创建文本编码时，应将TextEncodingBase设置为kTextEncodingUnicodeV2_0，将TextEncodingVariant设置为kUnicodeCanonicalDecompVariant，并将TextEncodingFormat设置为kUnicode16BitFormat。使用这些值可确保Unicode与HFS Plus卷上的格式相同，即使Unicode标准发展也是如此。
那么，正确比较HFS +和APFS名称的现代方法是什么？
答案 0 :(得分：0)
我通过读取原始数据来比较两个文件系统。在HFS plus目录文件和文件属性中，文件名Test.jpg存储为0x0054006500730074002E006A00700067
在Apple文件系统中，我们有4kb块。块类型0x0300 BlockID 0x07040000 00000000与目录文件相当。 Blocktype 0x0300 BlockID 0x11040000 00000000是apple finder信息，包含filesize，磁盘大小和指向文件所在块的小端指针。 文件名Test.jpg存储为0x546573742E6A7067。我从来没有在我的iMac上使用过Ascii 0-127以外的字符的文件名，经过尝试后，可以在APFS和HFS plus上的文件名中使用扩展的ascii，unicode和smileys。
APFS没有记录，我们所知道的都是从逆向工程中学到的。
有关APFS的其他信息，请参阅Cugu's blog