Ядро Linux 2.6: монтирование с опцией utf

2005-08-30

Прежде всего, нужно сказать, что предлагаемый к обсуждению вопрос отнюдь не "подтема" обсуждения ядра 2.6. В рамках последнего можно бы ограничиться перечнем опций монтирования для различных файловых систем "на уровне" 2.6, отметив только разницу с ядром 2.4. Интерес, однако, представляет другое: зачем это нужно и нужно ли вообще? Причём, как в отношении монтирования "чужих" файловых систем, так применения utf вообще.

Моё собственное отношение к этому сформировалось, прежде всего, в ходе дискуссии разработчиков movix-продуктов (Movix, eMovix и MoviX2). Из чего следует, что обсуждение касалось:

прежде всего video- и mp3-CD;
как воспроизведения, так и записи m/m дисков (eMovix);
как консольных, так и gui-приложений (MoviX2).

Сразу скажу, что никогда не являлся сторонником использования native language (в нашем случае - кириллицы) в именах томов, каталогов и файлов. Считаю это дурью сродни требованию именовать лекарства исключительно по-русски: тёте Клаве - удобнее, продавцу - и вовсе "лафа" (знай, только новые названия аспирину выдумывай), а к медицине и фармацевтике отношения не имеет: врач всё равно должен использовать стандартное (латинское), а не коммерческое название препарата. Если он врач, конечно, а не та же тётя Клава, но уже с дипломом. (Перефразируя слова академика Крылова, я бы сказал: юзер, дающий файлам русские имена, заслуживает четвертования на Дворцовой площади - А.Ф.).

Это, однако, - эмоции. Реальность же состоит в том, что:

мультимедийные CD - товар широкого спроса и native language на них присутствует с такой же неизбежностью, как и в названиях лекарств;
усилиями M$ к числу пользователей IBM PC отнесено столько всякого рода граждан, что, по крайней мере, части из них никакой другой язык, кроме native попросту недоступен. Справедливости ради, нужно сказать, что у этой части населения и с родным языком "не слава Богу", но это уже не наше дело.

Добавим к этому интеграционные процессы в мире и Европе... Вывод очевиден всем и уже достаточно давно. Стандарт ISO 10646 и Unicode разрабатываются с конца 80-х и, к счастью для компьютерной общественности, с 1991-го - согласованно. Это значит, что и принципы, и таблицы кодирования их совместимы. Скажем так: настолько, что даже M$, традиционно ищущая "своих" путей (не столько из оригинальности, сколько в поиске возможности получить на них патент) хранит длинные (длиннее 8+3) имена файлов и каталогов в Unicode. Причём на всех современных файловых системах - fat, ntfs и CD(Joliet).

Короткие (<8+3 - MS DOS format) имена в файловых системах от M$ по-прежнему используют 8-битные кодировки (cp1250, cp1251, etc.), но нас это уже не волнует: всякое такое имя имеет свой Unicode-двойник.

Таким образом, до сих пор, для вышеупомянутых файловых систем опция монтирования iocharset=name означала: при чтении декодировать имена монтируемой файловой системы из Unicode в кодировку name, при записи - кодировать из name в Unicode. Кодировка name может быть любой из списка возможных в качестве значения iocharset (см. man mount и содержимое каталога Documentation/filesystems дистрибутива ядра. На последнее, кстати, следует обратить внимание особенно: возможности монтирования определяются ядром, поэтому-то документация на mount традиционно "запаздывает").

Список этот довольно обширен, но только одна из кодировок "многоязычна" и это utf8. Однако, UTF-8 - это реализация ISO 10646-1:2000, что, в свою очередь, соответствует Unicode 4.0. То есть, перекодировка, вроде бы и не нужна. При чём здесь iocharset? Правильно: ни при чём. Что для нового ядра и "вылилось" в появление новой опции монтирования utf8 (для ntfs: nls=utf8).

Отныне разделы vfat и ntfs, а также CD в формате ISO 9660 (ext.Joliet) и udf могут монтироваться одинаково для систем с различными native language.

И всё бы хорошо, если приложение, которому предстоит визуализировать эти самые имена каталогов/файлов в кодировке utf, хорошо с этим справляется. В среде X Window таких, надо сказать, большинство. Хотя, к сожалению, и не все. Файл-менеджеры Gnome и KDE, а также мой любимый ROX - легко, а столь же любимый window-менеджер Oroborus - нет (в том случае, когда от него требуется визуализировать имя каталога в качестве заголовка окна).

Достаточно запустить xfontsel и выбрать в нём rgstry=iso10646, чтобы убедиться, что большая часть семейств фонтов большей части производителей может в настоящее время использовать utf8. Создавать для проверки, в порядке эксперимента, файлы или каталоги в Japanese или Hebrew, быть может, и не стоит. А вот воспользоваться тестовым файлом с незатейливым названием quickbrown.txt из пакета Маркуса Куна (Markus Kuhn) ucs-fonts небезынтересно: файл содержит фрагменты текстов во всех мыслимых кодировках. Впечатляет. Я при этом пользовался Edit из состава ROX-Desktop и хочется верить, что аналогичные средства просмотра и редактирования от Gnome или KDE окажутся не хуже.

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

Ситуация в консоли, в принципе, аналогична. Только фонт один для всех приложений. Основная же трудность состоит в том, что консольные фонты "по определению" не могут включать в себя более 256 (512) символов. Имеем парадокс: кодировку используем utf, то есть: одну для множества языков, а реально располагаем при этом набором только из 256 (512) символов, что явно недостаточно для "покрытия" всемирного разнообразия. Грубо говоря: то, что вывести нужно символ из японской кодировки - очевидно, только это не значит, что в загруженном фонте он есть.

Вот и получается, что вполне очевидные преимущества при переходе в консоль становятся до некоторой степени условными. Примерно таким же выводом закончилось и обсуждение применения utf для консольной ветки movix (MoviX).

А вот ещё несколько замечаний, имеющих отношение к обсуждаемым вопросам:

опция монтирования codepage=name необходима, в сущности, только для правильного отображения имён в формате 8+3. Требуется также часто, как часто встречаются разделы, созданные исключительно под MS DOS;
досадным обстоятельством для CD является ограничение длины имён файлов 64-мя символами, известное как Microsoft Joliet specification. mkisofs, кстати, имеет опцию -joliet-long, "поднимающую планку" до 103 символов. Однако, это, к сожалению, остаётся "внутренним делом" mkisofs;
занятно, что отмеченное выше ограничение легко преодолевается при использовании ISO 9660 RockRidge extention. Жаль только, что превалирующие в мире Windows-компьютеры не умеют читать таблицу файлов RockRidge.

В заключение осталось отметить ещё пару опций монтирования vfat и ntfs, появившихся после 2.4. Это опции dmask и fmask. Нетрудно догадаться, что с их помощью можно раздельно задавать маски флагов для директорий и файлов.

Раньше маскировать бит executable можно было только для файлов и директорий одновременно. Для файлов это было уместно: наличие бита исполняемости у всех файлов тома vfat или ntfs заметно раздражало, а попытка какого-нибудь файл-менеджера запустить файл на исполнение вместо действия "по расширению", как это принято у M$, выглядела неприлично глупо. В то же время каталоги становились "нечитаемы". Теперь же, задав dmask=000 fmask=0111, можно и директории оставить доступными и файлы - неисполняемыми.