[devel] О кодировке названий файлов при монтировании

[Alexey Morozov]

On Mon, Feb 21, 2005 at 11:30:51PM +0300, Vitaly Lipatov wrote:
> On Monday 21 February 2005 20:29, Alexey Morozov wrote:
> > Народ, по-моему, вы маетесь ......
> Вы это скажите тем, кто пытается iocharset в fstab запихивать.
Те, кто пытаются, по крайней мере, представляют себе _алгоритм_
действий и степень его применимости. Возможно, я слишком невнимательно
посмотрел на Ваше решение, но, извините, _system-wide_ алгоритма я там
НЕ заметил.

> > Задача в большинстве случаев не определить "кодировку файловой
> > системы", так как в тех файловых систем, для которых этот
> Речь идёт о кодировке названий файлов в системе
О _какой_ кодировке? Что, если на машине три разноязыких пользователя,
использующих, к тому же, 5-6 кодировок в сумме? Какую кодировку Вы будете
использовать в этом случае?

> (не в монтируемых системах, а та, которая принята для именования
> файлов).
Собственно говоря, я знаю только одно семейство кодировок, которое
fits all sizez. Это различные варианты юникода. Поскольку нижний уровень
файловых систем никто из-за этого переделывать не будет, то единственной
кодировкой, которая была бы, с одной стороны, пригодна для такого
использования, а с другой - не была бы полностью маргинальной (а-ля
MULE в emacs), является UTF-8.

> > параметр имеет смысл (в первую очередь - варианты FAT и ISO),
> > уже давно используется (двухбайтный) ЮНИКОД. Задача
> Это думаю всем понятно.
Отлично.

> > СОГЛАСОВАТЬ эту кодировку (ЮНИКОД) с кодировкой
> > _пользователя_. А это, извините, совсем другая задача. В общем
> Мне кажется, в _системе_ все файлы должны именоваться в одной 
> кодировке. Если нужны исключения - объясните и отдельно укажите.
Да. Но такой кодировкой может быть только UTF-8.

> А кодировка пользователя - это что такое? Его локаль?
Нет. В этом-то, вообще говоря, еще одна проблема. Мне не удалось
с наскока провести в общем случае соответствие между локалью и
кодировкой.

> > случае, не решаемая, так как налицо явная нестыковка
> > "системного" и "пользовательского" уровня обработки данных.
> > "Системная" кодировка со всей необходимостью одна (постольку
> > поскольку у нас разделяемый fstab). А вот "пользовательских"
> Вот о ней и речь.
То есть, речь о UTF-8? Так и запишем.


> Проблемы пользователей, имеющие отличную от системной локаль,
> давайте обсудим отдельно:
>  - примеры, зачем это нужно
Хе-хе... Некоторые из наших друзей сочтут этот вопрос имперским
шовинизмом ;-).

> Это всё замечательно. Сначала я хотел бы решить проблемы 90% 
> пользователей, которых кормят словами, что кодировка файловой 
> системы неопределимое понятие в общем случае, а потому давай-ка 
> ты юзер пиши свои charset'ы, заодно и набирать на клавиатуре 
> лучше научишься. Простая была проблема, которая десятилетиями не 
> решается.
Виталий, знаете, не надо никакой магии. Совсем. Юникс - это про
простые, даже кондовые решения. 
Для тех устройств, монтирование которых не отдано на откуп HAL'у,
настройка проводится в fstab. Причем, скорее всего, прямо таки
инсталлятором, или соответствующей ему "runtime" частью.
Для устройств, чьим монтированием заведует HAL, прописывается
мале^H^H^H^H ну, не очень большой файлик, XML все-таки, понимать надо,
там маленьких файлов не бывает по определению :-), где сказано:
если файловая система fat (и производные) использовать koi8-r.

Хуже того, я публиковал уже решение, которое позволит автоматически
настраивать HAL на ту кодировку, которая реально использовать в системе.

> > Да-да, я уже слышу за спиной шаги тех, кто угрожает порвать
> > меня с такими решениями на четырехцветный флаг. Поэтому и
> Решение хорошее. Как только в системе будет dbus и hal,
> обязательно вернёмся.
Мы уже там :-).


> > /etc/sysconfig/i18n, а на основании этого параметра
> > формировать настройки HAL'у. Будет работать для 90% случаев,
> > по крайней мере.
> Этот параметр там уже есть в принципе (LANG), если нужен другой -
> давайте обоснуем.
Нет. Как я уже говорил, проставить соответствие между кодировкой и
локалью в общем случае вот так вот запросто нельзя. Ну, точнее, я,
глядя в info libc, такого способа не увидал.

> Между прочим, ваше резюме - это то, что я и предлагаю.
> Ввести единое место для хранения кодировки файловой системы.
> И предлагается это делать с помошью get_filename_encoding
> или natspec -f
:-). Будьте проще, люди потянутся.
. /etc/sysconfig/i18n
: ${SYSFONTACM:=koi8-r}
: ${SYSMOUNTCHARSET:=$SYSFONTACM}
echo $SYSMOUNTCHARSET

http://lists.altlinux.ru/pipermail/devel/2005-February/017892.html

Только нужно учитывать, что рецепт, приведенные там не вполне корректен.
Во-первых, нужно проверять на наличие файла
/etc/hal/fdi/95userpolicy/system_charset.fdi перед его перезаписью.
Во-вторых, формируемый .fdi, боюсь, не вполне корректен, требуется
еще некоторый пролог и эпилог.
Ну, и в третьих, Антон до сих пор не перенес соответствующие настройки
из /usr/share/hal в /etc/hal. Нужно только помнить, что "системные"
настройки, которых там большинство лучше по-прежнему оставлять в /usr,
т.к. по размеру они большие, а править их все равно не следует.
А вот подкаталог 95userpolicy - явный кандидат в /etc.

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20050222/e887e51c/attachment-0001.bin>