Ключевые слова:linux, mount, utf, charset, kernel, (найти похожие документы)
From: Владимир Попов <popov@ukrpost.net.>
Date: Wed, 14 Apr 2006 18:21:07 +0000 (UTC)
Subject: Монтирование с опцией "utf" в Linux ядре 2.6
Оригинал: http://www2.ldc.net/~popov/2.6-mount-utf.html
Ядро Linux 2.6. Монтирование с опцией "utf".
Прежде всего, нужно сказать, что предлагаемый к обсуждению вопрос
отнюдь не "подтема" обсуждения ядра 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 можно и директории оставить
доступными и файлы - неисполняемыми.
Имеется свежепроинсталлированная FC6, локаль utf8 (решил попробывать), вставляю флэшку (фат32) с русскими именами файлов, hal все монтирует, все названия файлов видны, все прекрасно. Беру cd диск (писался на FC5 в k3b, на ней у меня локаль koi8-r) с файлами с русскими именами, hal монтирует, но вместо русских названий квадратики. Ладно, меняю локаль на FC6 на koi8-r, вставляю cd диск - есть русские имена файлов, вставляю флешку - вместо русских названий файлов - кракозяблы (думаю это лечится, по крайней мере в FC5 у меня получилось).
Делаю такой же эксперемент на ubuntu 6.06 (c локалью utf8) все точно так же.
Пытаюсь в системе с локалью utf8 смонтировать cd диск вручную
mount /dev/cdrom /mnt/cdrom -o utf8
(повторюсь, диск с русскими именами файлов, писался в системе с локалью koi8-r). Получить отображения названий файлов в читаемом виде не могу.
Что можно еще сделать?
