The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Монтирование с опцией "utf" в Linux ядре 2.6 (linux mount utf charset kernel)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: 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 можно и директории оставить доступными и файлы - неисполняемыми.

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

Обсуждение [ RSS ]
  • 1, Mark (??), 11:35, 05/12/2006 [ответить]  
  • +/
    Имеется свежепроинсталлированная 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). Получить отображения названий файлов в читаемом виде не могу.
    Что можно еще сделать?
     
  • 2, Павел (??), 12:49, 25/11/2007 [ответить]  
  • +/
    Статья, в принципе, занимательная. Огорчает только испоьлование непонятных слов вроде: локаль, фонты. я считаю что в русском языке таких слов нет.
     
  • 3, артем (?), 01:01, 10/06/2008 [ответить]  
  • +/
    простых и понятных аналогов слова локаль в русском языке нет.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру