Re: Кодировки за и против

В сообщении от 1125747555 секунд после начала Эпохи Alexander
написал(а):

У меня KOI8-U, тексты, написанные в вин. читаются без проблем. :)

$ man utf-8
$ man charsets

:)

Доброе утро.

В Сбт, 03.09.2005, в 14:39, Alexander пишет:

Не совсем маразм, текст KOI-8 за счет этого довольно успешно читается,
если обнулить старший бит. Учитывая года появления этого стандарта, это
весьма было актуально. Тем более, что это реально ничему не мешает.
Другое дело, что наборы дополнительных символов (не относящихся к
кириллице), у них разные и иногда это может играть свою роль.

Вообще же, выбор между cp1251 и koi8-r, ИМХО, стоит вести отталкиваясь
от того, что больше ценно конкретно для вас - лучшая поддержка Windows
или лучшая поддержка российского сообщества пользователей GNU/Linux (и
других свободных систем), где KOI8-R давно является стандартом.

Другое дело, что я считаю, что российское сообщество отдельными местами
слишком уж цепляется за уходящий поезд KOI8-R. Периодически
встречающиеся рекомендации по переводу свежих Fedora Core и SuSE на
использование KOI8-R давно уже пора объявить вредительскими.

К сожалению, нет ссылок на толковые документы на русском по вопросам
Unicode. Если вкратце, то у UTF-8 перед другими юникодами есть одно
большое преимущество - полная совместимость с ASCII. Отличительная
особенность UTF-8 - символы кодируются _переменным_ количеством байт, от
1 до 4 (в ранних версиях стандарта было до 6). Русский алфавит находится
в пространстве двухбайтовых, а вот различные восточные иероглифы уже
кодируются как трех- и четырехбайтовые.

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

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

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

Это лучшее решение языковых проблем в GNU/Linux. Поддерживается как
разработчиками Linux, так и разработчиками GNU.

--
Roman
,---------------------------. ,--------------------------.
/ http://www.3os.ru/ V http://www.osrc.info/ \ .o.
\ mailto: rik@3*****.ru ^ mailto: rik@o*****.info / ..o
`---------------------------' `--------------------------' ooo
gpg --recv-keys 0xE5E055C3 --keyserver hkp://subkeys.pgp.net

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 21279; Возраст листа: 771; Участников: 1403
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/430004

Roman I Khimov wrote:

Столкнулся не с экзотической весчью. С СД-дисками. Если в крации, то
если пишу диск на машине с UTF кодировкой, и встречаются кирилистические
названия файлов, то прочитать их можно только с локалью утф. На других
крякозяблы. Причём выставить принудительно (в к3в) кодировку utf8 нельзя
(нету её там, любая другая пожалуйста кроме utf). И наоборот, диски
записанные и читабельные на других локалях и оффтопе, отображаются
крякозяблами в utf. Это у меня одного так или с этим проблема?

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 21346; Возраст листа: 774; Участников: 1405
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/431456

Доброе утро.

В Втр, 06.09.2005, в 00:29, Ignatiy Goloviznin пишет:

Все зависит от того, как пишете и как читаете. С учетом принципиального
уродства файловой системы ISO-9660 приходится пользоваться ее
расширениями - Rockridge и Joilet.

Rockridge стандартизирован и прекрасно совместим с файловой моделью UNIX
(собственно, чего ради и создавался), в том числе и с тем положением,
что кодировка символов - не его дело и писать туда можно как угодно. Что
является уродством, так как потом нормально прочитать имена зачастую
невозможно, сам столкнулся с этим на диске, записанном в Windows с
помощью порта cdrecord - там была cp866 (мега-локаль!).

"Языкатых" опций монтирования, которые преобразовывали бы кодировки (аки
с FAT-ом) нет, поэтому имена как были потоком байт - так и вывалятся
потоком байт, а будут ли они нормально смотреться с вашей текущей
локалью - неизвестно, причем конкретно от UTF-8 это уже не зависит.

Есть другое расширение - Joliet, созданное малоизвестной корпорацией
Microsoft специально для своей Windows. Расширение де-юре нестандартное,
но де-факто, по понятным причинам, тем самым стандартом все же давно
ставшее. Причем, если чего-нибудь вроде символических ссылок на диске
нет, то, по большому счету все равно, какое там расширение.

Так вот у Joliet, при всем уже его уродстве, есть один мега-плюс - четко
определенная кодировка в виде UTF16, что с кодировочным бардаком
решительно все прекращает, UTF16 будет преобразован в текущую локаль
(опции "iocharset=..." или "utf8") и все имена *однозначно* будут
правильными.

ИМХО, "просто диски" имеет смысл создавать с Joliet и проверить, не
выключена ли его поддержка в параметрах монтирования (nojoliet),
поскольку реальные преимущества RockRidge будут видны только в полной
UNIX-овости. После чего, приняв рюмку за упокой стандарта, включить в
опции монтирования "norock" (иначе, даже при наличии обоих расширений на
диске, один черт имена будут браться из RockRidge).

Впрочем, есть одно маленькое обстоятельство - на дисках с дистрибутивами
GNU/Linux и *BSD те самые символические ссылки в реализации RockRidge
периодически используются, посему с отключенным RockRidge, чисто
теоретически, могут быть проблемы в стиле "я вас не вижу" со стороны
менеджеров пакетов или чего-либо еще дистрибутиво-специфичного.

Спасибо. Отличное разъяснение ситуации. Я то давно опытным путём установил, что
писать лучше используя расширение одной малоизвесной фирмы с символическим названием
"Microsoft" (вроде так пишется), но вот с теоретической чатью, т.е. почему так,
были недопонимания. Теперь в голове гораздо больше ясности.

С уважением,
Андрей.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 21353; Возраст листа: 774; Участников: 1402
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/431571

On Tue, 2005-09-06 at 09:31 +0400, Андрей Клаус wrote:

А как быть с ограничениями на длину имени файла?!
K3b "говорит", что больше 64 символов нельзя... хоть у меня таковых и
так нет.

Доброе утро.

Вторник 11 октября 2005 09:53 | Strong:

Есть опция -joliet-long к mkisofs и соответствующая галка в K3B, это дает
до 103 символов. Все, дальше уже никак - с этим придется жить.

В сообщении от 1125961129 секунд после начала Эпохи Roman I Khimov
написал(а):

Хочу воспользоваться случаем, и рассказать немного о LUFS и моем патче
`lufs-0.9.7-charset.patch'.

LUFS (Linux Userland File System) - это модуль файловой системы для
ядра Linux и демон, работающий в userspace. LUFS позволяет
подключать (монтировать) различные файловые системы: sshfs, ftpfs,
localfs, locasefs, gvfs, cardfs, cefs. `lufs-0.9.7-charset.patch' -
патч, добавляющий поддержку перекодировки имен файлов "на лету".

Например, в случаи с CD с расширением Rockridge и кодировкой cp866
можно поступить так:

$ mount /mnt/cdrom
$ mkdir ~/cdrom
$ lufsmount localfs:///mnt/cdrom ~/cdrom -o fscharset=cp866
$ ls -R ~/cdrom

Это с учетом того что в `/etc/lufsd.conf' указана кодировка вашей
локали.

Естественно перекодировка работает со всеми поддерживаемыми ФС. Решает
проблемы при использовании виндовых (заточенных под виндовых клиентов)
FTP-серверов. Может также пригодится для собственного FTP-сервера.
Например, на одном IP-адресе FTP-сервер выдает имена файлов в KOI8-R, а
на другом - те же файлы, но с именами в CP1251.

Однако, лично я реально `lufs-0.9.7-charset.patch' не использую, нет
нужды. А написал я это просто ради удовольствия. :)

Ссылки:
http://lufs.sourceforge.net/
http://sourceforge.net/tracker/index.php?func=detail&aid=1095310&group_id=57332&atid=483773

Доброе утро.

В Втр, 06.09.2005, в 14:33, Konstantin Korikov пишет:

Когда писал, как раз думал, а почему бы, собственно не... :) Эту штуку
портировать бы под FUSE (http://fuse.sf.net/) - было бы вообще отлично.
FUSE, кажется, сможет пробраться в 2.6.14, так что наличие кодировочной
ФС для него здорово облегчило бы жизнь российским пользователям - благо,
решение универсальное.

Ну, если делать нечего будет на досуге (правда, это явно не в ближайшее
время), то сделаем. :)

В сообщении от 1126015802 секунд после начала Эпохи Roman I Khimov
написал(а):

Мне FUSE не нравится тем что в отличие от LUFS не позволяет разделять
код файловых систем между другими приложениями. Т.е. в LUFS файловые
системы реализованы в виде разделяемых библиотек, а в FUSE в виде
выполняемых файлов. Мне кажется что FUSE неоправданно жадничает. Вить
разделяемые библиотеки можно и в домашней директории хранить, если
нужно предоставить обычным пользователям возможность создания/установки
своих ФС.

На данный момент я положил глаз на GnomeVFS, как на универсальную
библиотеку файловых систем, которую можно использовать из тех же FUSE и
LUFS. Пусть FUSE и LUFS выполняют свою работу - связь между
ядром и кодом ФС в userspace, а GnomeVFS будет этим самым кодом ФС.
GnomeVFS - довольно гибкая система, и если сделать поддержу
перекодировки имен файлов в виде модуля к GnomeVFS, то, мне кажется,
мы получим больше выгоды.

На мой взгляд, GnomeVFS - довольно перспективное решение. Кроме
прочего, можно реализовать ФС ISO9660 для доступа к образам CDROM
непривилегированным пользователям (думаю, это тоже наболевшая
проблема). Созданный код ФС можно без изменений использовать в любых
C-приложений. Также имеются привязки к C++ и Python.

Добрый день Konstantin,

В день 6 сентября 2005 г., 13:32:45, вы писали:

Тогда можно и мне поинтересоваться своим "горем"?
- сервер ftp отдает имена файлов в виндовой кодировке cp1251
- локаль у меня ru_RU.KOI8-R (ALTMaster 2.4)
- как подмонтировать ftpfs для того чтобЫ бЫло все в норме с
кодировкой?
- как должна вЫглядеть строка для /etc/lufsd.conf с указанием
локальной кодировки?

Пробовал
lufsmount ftpfs://user:pa***@s*****.com/ /mnt/rd -o fscharset=cp1251
но ничего не дало - крякозябрЫ остались.

Подскажите пожайлуста способ правильного использования, а то уж очень
надо именно монтирование, но альтернативЫ не знаю...

В сообщении от 1126017099 секунд после начала Эпохи Esmont Alexander
написал(а):

Можно указать две кодировки в командной строке:

$ lufsmount ftpfs://user:pa***@s*****.com/ /mnt/rd \
-o fscharset=cp1251,iocharset=koi8-r

Но чтобы каждый раз не вводить `iocharset=koi8-r', кодировку локали
можно задать в `/etc/lufsd.conf' добавив такую строку:

MOUNT::iocharset = koi8-r

Добрый день Konstantin,

В день 6 сентября 2005 г., 21:19:01, вы писали:

попробЫвал - ничего не получилось. Что с указанием кодировок, что без
- в именах файлов неправильное отображение(характерная первая
маленькая буква, остальнЫе большие)
Может где-то, что-то надо дополнительно указать?

Добавлял - неработает.

Может я чего и напутал, а может просто кто-то мешает проге работать...

В сообщении от 1126100376 секунд после начала Эпохи Esmont Alexander
написал(а):

Что-то сделано неправильно. Варианты:

1. Не наложился патчь.
2. Указаны неправильные кодировки.
3. Какой-то баг, о котором я даже не догадываюсь.

При указании опций `fscharset=cp1251' и `iocharset=koi8-r' имена фалов
как-то меняются? Если нет, то патчч не работает, как будто его вообще
нет. Если да, то возможно указаны не правильные кодировки.

В сообщении от 1125961129 секунд после начала Эпохи Roman I Khimov
написал(а):

Хочу воспользоваться случаем, и рассказать немного о LUFS и моем патче
`lufs-0.9.7-charset.patch'.

LUFS (Linux Userland File System) - это модуль файловой системы для
ядра Linux и демон, работающий в userspace. LUFS позволяет
подключать (монтировать) различные файловые системы: sshfs, ftpfs,
localfs, locasefs, gvfs, cardfs, cefs. `lufs-0.9.7-charset.patch' -
патч, добавляющий поддержку перекодировки имен файлов "на лету".

Например, в случаи с CD с расширением Rockridge и кодировкой cp866
можно поступить так:

$ mount /mnt/cdrom
$ mkdir ~/cdrom
$ lufsmount localfs:///mnt/cdrom ~/cdrom -o fscharset=cp866
$ ls -R ~/cdrom

Это с учетом того что в `/etc/lufsd.conf' указана кодировка вашей
локали.

Естественно перекодировка работает со всеми поддерживаемыми ФС. Решает
проблемы при использовании виндовых (заточенных под виндовых клиентов)
FTP-серверов. Может также пригодится для собственного FTP-сервера.
Например, на одном IP-адресе FTP-сервер выдает имена файлов в KOI8-R, а
на другом - те же файлы, но с именами в CP1251.

Однако, лично я реально `lufs-0.9.7-charset.patch' не использую, нет
нужды. А написал я это просто ради удовольствия. :)

Ссылки:
http://lufs.sourceforge.net/
http://sourceforge.net/tracker/index.php?func=detail&aid=1095310&group_id=57332&atid=483773

У меня на сюсе 9.1 была локаль ютф8, писал в к3б с расширением joilet(вроде так
пишется). Читалось в офтопе нормально, на других линуксах не проовал.

С уважением,
Андрей.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 21352; Возраст листа: 774; Участников: 1402
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/431566