Файловая система APFS разрешает называть файлы только по-английски

Новая файловая система APFS не поддерживает нормализацию символов Unicode на уровне файловой системы, поэтому файлы безопаснее всего именовать в рамках кодировки ASCII, сообщает Cnews. Это фактически сводит выбор имени к английскому языку, не требующему нормализации. Иначе ряд инструментов и командных оболочек не сможет работать с файлом.

Файловая система APFS, представленная Apple в июне 2016 года, не дает пользователю возможность именовать файлы на каком-либо языке, кроме английского. Имя файла или папки лучше составлять только из символов кодировки ASCII, в противном случае с этим объектом возникнут проблемы. Дело в том, что APFS не поддерживает нормализацию символов универсальной системы кодирования Unicode. От этого страдают в первую очередь письменные символы различных языков, которые отличаются от букв английского алфавита.

APFS была разработана компанией с нуля и ориентирована в первую очередь на работу с флэш-накопителями и более совершенное шифрование данных. В настоящий момент APFS работает на всех устройствах, где установлена версия iOS 10.3 или выше. Таким образом, указанная проблема наблюдается только на iPhone и iPad, на которых у пользователя нет прямого доступа к файлам. Однако, поскольку до конца 2017 года APFS будет развернута в macOS High Sierra, эксперты уже сейчас имеют возможность зафиксировать проблему имен файлов и для этого случая.

Нормализация Unicode

В систему кодирования Unicode включены алфавиты практически всех языков мира, имеющих письменность, а также цифры, математические знаки и т. д. За каждым таким символом закреплен уникальный код, который делает его частью общей системы. Некоторые символы обозначаются сразу несколькими кодовыми комбинациями. Например, буква «é» может быть представлена в кодировке UTF-8 как два шестнадцатеричных байта c3 a9, а может выглядеть как три шестнадцатеричных байта 65 cc 81. Тем не менее, визуально это одна и та же буква, и компьютер должен прочитывать ее единообразно, для чего и требуется нормализация.

Файлы, поименованные символами неанглийских алфавитов, APFS считает пустыми

В стандарте Unicode предусмотрено четыре системы нормализации. Предыдущая файловая система Apple, которая называется HFS+, использует форму нормализации D. То есть, две разные «é» автоматически приводятся к одному виду и предстают в виде трех байтов 65 cc 81. В HFS+ это делается на уровне файловой системы. Таким образом, все, что выполняется на Mac, будь то приложения, команды или сама macOS, работает с нормализованными именами файлов и папок. HFS+ не позволяет создавать какие-либо «ненормальные» имена.

Как работает APFS

В APFS нормализация символов не выполняется на уровне файловой системы. APFS не меняет поступившие к ней кодовые комбинации Unicode независимо от того, были они нормализованы или нет. Нормализация встроена в системные команды более высокого уровня, которые работают с файлами и папками.

Чтобы избежать проблем, Apple рекомендует разработчикам использовать для работы с файловой системой высокоуровневые Foundation API, такие как NSFileManager или NSURL. Или же прибегать к функции fileSystemRepresentation объектов NSURL при создании и открытии файлов с помощью API более низкого уровня, таких как POSIX, а также при сохранении файлов APFS за ее пределами.

Проблема и ее последствия

В ответ разработчики поясняют, что не всякое ПО может работать по такой схеме, и что некоторые высокоуровневые API еще не поддерживают запросы, необходимые для выполнения этой процедуры. Ситуация благоприятствует возникновению в APFS ошибок, и этот риск возрастает, когда для именования файлов используется любой язык кроме английского, поскольку английский алфавит наименее нуждается в нормализации Unicode. Переход с одной файловой системы на другую влечет за собой смешанную нормализацию.

Поскольку в HFS+ символы нормализуются на уровне файловой системы, командные оболочки этим не занимаются. Например, инструмент Terminal сам по себе прописывает в названии файла café.txt двухбитный, ненормализованный «é». А инструмент Finder, как и обещает Apple, приводит букву к трехбитному виду. Некоторые оболочки могут получить доступ только к файлам и папкам с нормализованными именами, то есть они не видят ненормализованный café.txt, как, например, Icon view. Terminal видит, но испытывает проблемы при выполнении операций с этим файлом. Apfelstrudel считает, что два файла café.txt с нормализованным и ненормализованным «é» названы одинаково, а Finder – что по-разному.

Проблема может привести к сбою в работе многих инструментов, тем более, что ввод команд напрямую или через оболочки часто используется в macOS. Теперь пользователь не может быть на 100% уверен, какой символ он сейчас ввел. Чтобы исправить ситуацию, придется внедрять механизм нормализации в сами инструменты, но это будет непросто.

Источник: MacDigger.ru


28 комментариев

  • В этой статье раза три про одно и тоже. Хватит платить за колличество символов!!
  • что-то вспомнились дистрибутивы linux начала нулевых и танцы с бубнами, чтобы воткнуть поддержку unicode, надеюсь, что эппл знает, что делает)
  • все как обычно, новая макос новые баги, новая айос новые баги и так каждый год, мля надоело уже
  • ох и дебилы ох и дебилы, походу им не страшны не только головняки и костыли разрабов, но и новые баги и уязвимости которые это может вызвать, ведь для хакеров это новое непаханое поле :)
  • включи хендоф и подключи к маку блютус колонку потом в сон уйди, потм включи все получишь прерывистый звук из колокни про тормозящую камеру в 9.3.5 не забыл баран про быстрый разряд в 10.3.2 не забыл баран и т.д. много чего еще могу написать тебе...
  • в MS DOS тоже нельзя было. И количество символов 8.3
  • A нефиг писать не по-английски. В интернете надо писать только по-английски, чтоб всем понятно было. Зачем разводить неразбериху? Языком интернета изначально был именно английский. Надо стремиться к универсализации, чтобы все люди на земле понимали друг друга.
    • Ира, так чего же ты здесь кириллицей распинаешся? А вообще, Ира, ты доставляешь! :)
  • > Например, буква «é» может быть представлена в кодировке UTF-8 как два шестнадцатеричных байта c3 a9, а может выглядеть как три шестнадцатеричных байта 65 cc 81. "два шестнадцатеричных байта", Карл!
  • У меня стоит бета HIGH Siera......Никаких багов нету...И папки кириллицей называю... Все нормально...И можно раздел с ней сделать загрузочным..Но параллельно стоит Mavericks, так когда работаю на нем, не видно HIGH Sierra / раздела диска.. Дисковая утилита определяет как не подключенный раздел...Возможно 9.5 не видит 13.0....