Тестирование имен файлов в macOS на равенство, особенно в HFS+ и APFS

Question

Новая файловая система Apple APFS содержит новые правила для проверки равенства имен файлов, и они отличаются от HFS. Я ищу правильный способ сравнить два имени на равенство, в частности, для APFS, но для полноты это не помешает добавить одно для проверки HFS+ хорошо.

Зачем? Потому что мне нужно знать, соответствует ли имя файла, которое я нахожу в каталоге, определенному шаблону, например, содержит ли определенную подстроку. Для этого мне нужно соответствовать точным правилам, которые файловая система и Finder будут использовать для сравнения имен.

Для чувствительных к регистру вариантов этих файловых систем это довольно просто, поскольку, как я полагаю, достаточно побайтного сравнения (при условии, что обе строки используют одну и ту же кодировку).

Для HFS+ без учета регистра я думал, что есть даже специальная опция сравнения, но я не могу найти такую ​​в NSStringCompareOptions. Я считаю, что это было необходимо, потому что HFS+ использует более старую версию стандарта Unicode. Я цитирую TN1150 (который, к сожалению, больше не доступен на сайте Apple, похоже):

Тонкости Юникода

HFS Plus активно использует строки Юникода для хранения имен файлов и папок. Тем не менее, 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?

Answer 1

Я сравнил обе файловые системы, прочитав необработанные данные. В свойствах файла каталога и файлов HFS plus имя файла Test.jpg хранится как 0x0054006500730074002E006A00700067.

В файловой системе Apple у нас есть блоки по 4 КБ. Blocktype 0x0300 BlockID 0x07040000 00000000 сопоставим с файлом каталога. Blocktype 0x0300 BlockID 0x11040000 00000000 - это информация о поиске яблок с указанием размера файла, размера на диске и небольшого порядкового указателя на блок, в котором находится файл. Имя файла Test.jpg хранится как 0x546573742E6A7067. Я никогда не использовал имена файлов с символами, отличными от Ascii 0-127, на моем iMac, и после попытки оказалось возможным использовать расширенные ascii, unicode и smileys в именах файлов на APFS и HFS plus.

APFS недокументирована, и все, что мы знаем, извлечено из обратного инжиниринга.

Смотрите блог Cugu для получения дополнительной информации о APFS