Нова файлова система APFS не підтримує нормалізацію символів Unicode на рівні файлової системи, тому файли найбезпечніше іменувати в рамках кодування ASCII, повідомляє Cnews. Це фактично зводить вибір імені до англійської мови, не вимагає нормалізації. Інакше ряд інструментів і командних оболонок не зможе працювати з файлом.
нормалізація 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% впевнений, який символ він зараз ввів. Щоб виправити ситуацію, доведеться впроваджувати механізм нормалізації в самі інструменти, але це буде непросто.
Приєднуйтесь до нас в Twitter. ВКонтакте. Facebook. Google+ або через RSS. щоб бути в курсі останніх новин зі світу Apple, Microsoft і Google.