CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
26.09.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки

Ядро 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, можно и директории оставить доступными и файлы - неисполняемыми.





Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds