?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Next Entry
(no subject)
nyaload
_winnie
fool-proof file opener would need to try the four different normalization forms (NFD, NFC, NFKD, NFKC) to be sure to open a file with non-ASCII characters ( отсюда )

Коротко говоря, в файле "named lé.txt" OS может представлять é как "e+accent", а может и как é, и Ubuntu с MacOS тут расходятся.


  • 1
При чём тут Ubuntu? При чём тут Mac OS? В ext (вне зависимости от платформы) имена хранятся как byte string, в NTFS/HFS+ — в UCS-2 (вопрос, кстати, только ли в base plane или нет; надо обращаться к первоисточникам); в WinAPI есть специальные вызовы для имён файлов в UTF-8, UCS-2 и ASCII, в POSIX, опять же, bytestring; вот и вся разница.

И какие байты должны появляться, когда при сохранении файла (копипастом или во французской раскладке) вводится буква é ?

Edited at 2011-06-20 08:44 pm (UTC)

Как скопипасчена (то есть, два кодепоинта или один), так и будет сохранена посредством API, работающих с байтстрингами в ФС, хранящей имена в байтстрингах. Если же API/ФС считает, что имена хранятся в Юникоде, то это должно быть прозрачно. Тут есть ряд вопросов, касающихся поведения в случае Unicode API и Bytestring-FS, но это несколько ортогональная вещь, хоть и со своими граблями (например, что делать, если в FS есть файлы с разными представлениями одной юникодной строки). Если что, Python API — фактически POSIX, и работает с байтстрингами.

Не тут другое - UTF-8 и UTF-16 и UTF-32 принципиально друг от друга не отличаются, хотя какой нить символ под номером 168365 будет иметь разную длину. Но как пример букву "ё" можно представить как один символ "ё", и как два "е+две точки сверху". Windows представляет первым способом, а MacOs вторым. Это неудобно.

Это вопрос сопоставления кодепоинтов и символов. На уровне Unicode API он должен быть прозрачен. То есть, мне всё равно, какие там получаются байтстринги, я работаю с юникодными строками со своим определением отношения эквивалентности, и так далее. И, что важно, имена файлов в HFS+/NTFS — юникодные строки, с точно таким же отношением эквивалентности. Как следствие, всё хорошо и думать о том, как что представляется, не надо. Ну, не должно быть надо, у меня не большой опыт в расковыривании что их API, что FS, чтобы утверждать, что это так.

А в POSIX/ext имена файлов — байтовые строки и API работают с байтовыми строками, поэтому включать мозг при конвертировании из/в Юникод необходимо.

Похоже ты не понял в чём проблема, ниже в комментариях про вьетнамский язык довольно доходчиво объяснили.

Вполне себе понял. И там правильно написано про нормализацию. В случае Unicode-имён в FS она должна быть прозрачна, в случае байтстрингов — делаться явно (если нужна, конечно). Вот и всё.

юникод, блин, такой юникод :-((((( а мы и так можем, и так, а кто это чудо будет поддерживать?

Edited at 2011-06-20 09:30 pm (UTC)

Ещё бы «а/a» и «с/с» etc приводить догадались, вот смеху-то было бы! :)

А я всегда говорил, что не-ascii имена файлов - зло.

"fool-proof file opener" при открытии должен просто произвести одну необходимую ему нормализацию utf-8 текста, например, в NFKC (каноническая декомпозиция + композиция).

Это умеет делать ICU (смотреть в сторону нормализатора, например, "unorm2_normalize" из сишного АПИ).

Кстати, помимо различных представлений диакритик (слитно, раздельно -- как в случае с "ё" и даже "й") он еще умеет приводить к единообразному виду цепочки тонов при декомпозиции.

Например, берем такой символ из вьетнамского: "ắ" : #\LATIN_SMALL_LETTER_A_WITH_BREVE_AND_ACUTE. Декомпозиция его выглядит как "a" : #\LATIN_SMALL_LETTER_A + " ̆ " : #\COMBINING_BREVE + " ́" : #\COMBINING_ACUTE_ACCENT. Вот эти #\COMBINING_BREVE и #\COMBINING_ACUTE_ACCENT в декомпозированном виде должны иметь определенный порядок, а на деле в "диком" тексте может встретиться что угодно :) Такие вещи тоже нужно нормализовывать, иначе одинаковые слова будут давать различные utf-последовательности, а это значит, что разъедутся хэш-фукнции и так далее.

И это, кстати, не только в именах файлов надо делать, нормализацию надо бы производить во всех местах, где из бинарной последовательности октетов мы берем utf-8 строку.

(Deleted comment)
Спасибо. Если забыть http:// в начале, то браузер считает что это ссылка от текущей страницы, а не на другой сайт.

Ужос, чё в мире твориться!

  • 1