在macOS上测试文件名是否相等，特别是在HFS+；和APF

苹果新的文件系统APFS带来了测试文件名平等性的新规则，它们不同于HFS。我正在寻找比较两个名称是否相等的正确方法，特别是对于APF，但对于完整性，为HFS+检查添加一个名称并没有什么坏处

为什么?？因为我需要能够判断我在目录中找到的文件名是否匹配某个模式，例如，包含某个子字符串。为此，我需要匹配文件系统和Finder用于比较名称的确切规则

对于这些文件系统的区分大小写的变体，这很容易，因为我相信字节比较就足够了（前提是两个字符串使用相同的编码）

对于不区分大小写的HFS+，我甚至认为有一个特殊的比较选项，但我在NSStringCompareOptions中找不到这样的选项。我认为这是必要的，因为HFS+使用了旧版本的Unicode标准。我引用了TN1150（很遗憾，它似乎不再出现在苹果的网站上）：

Unicode的微妙之处

HFS Plus大量使用Unicode字符串来存储文件和文件夹名称但是，Unicode仍在发展中，在文件系统中使用它带来了许多挑战。本节介绍了一些挑战，以及HFS Plus使用的解决方案

重要： 实现不得使用其本机平台实现的Unicode实用程序（用于分解和比较），除非这些算法等同于此处定义的HFS Plus算法，并且保证永远如此。这种情况很少发生平台算法倾向于随着Unicode标准的发展而发展。HFS Plus算法无法进化，因为这种进化将使现有HFS Plus卷无效

啊，还有一部分我想得到HFS+版本的所用编码：

注: Mac OS文本编码转换器提供了几个常量，允许您在HFS Plus卷上存储的规范分解形式之间进行转换。使用CreateTextEncoding创建文本编码时，应将TextEncodingBase设置为KTExtentCodingNicodev2_0，将TextEncodingVariant设置为KunicodeCanonicaleCompVariant，并将TextEncodingFormat设置为kUnicode16BitFormat。使用这些值可以确保Unicode的格式与HFS Plus卷上的格式相同，即使Unicode标准不断发展

---

那么，正确比较HFS+和APFS名称的现代方法是什么呢？

我通过读取原始数据来比较这两个文件系统。在HFS plus目录文件和文件属性中，文件名Test.jpg存储为0x0054006500730074002E006A00700067

在Apple文件系统中，我们有4kb的块。块类型0x0300块ID 0x07040000 00000000与目录文件相当。Blocktype 0x0300 BlockID 0x110400000000000是apple finder信息，包括文件大小、磁盘大小和指向文件所在块的小endian指针。 文件名Test.jpg存储为0x546573742E6A7067。我从来没有在iMac上使用过Ascii 0-127以外的字符的文件名，在尝试之后，在APFS和HFS plus上的文件名中使用扩展Ascii、unicode和smileys是可能的

APFS是没有文档记录的，我们所知道的都是从逆向工程中学到的

---

有关APFS的其他信息，请参见：）很高兴在这里见到你！那么，@thomas tempelmann有没有弄清楚APFS/HFS+如何比较文件名，以确定它们何时被视为大小写不敏感的相等/较小/较大？遗憾的是，没有。在macOS上运行时，至少可以使用NSString的

fileSystemRepresentation

等函数来规范化名称，然后比较结果。理想情况下，我们需要在NSString中使用一个特殊的比较选项，但我无法识别。