Re: Использование Unicode.

[Aleksey Novodvorsky <aen@logic.ru>]

Hi!
Ivan Pascal wrote:

>   Привет!
>
>   У меня вопрос скорее теоретический.
>
>   Ну вот есть теперь в XFree ввод уникода. А как им пользоваться?
>
>   Как я уже говорил - UTF-8 там на правах обычного "мультибайтового чарсета".
> То есть, если в XLC_LOCALE сказано, что название клавиатурного чарсета
> (encoding_name) UTF-8 и в названии локали оно же присутствует, то
> - XmbLookupString выдает utf-8
> - XwcLookupString выдает ucs-2 (ucs-4)
> (Кстати, уже не очень хорошо то, что UTF-8 должно быть и в названии и в
> качестве encoding_name).
>
>   Этого уже достаточно, чтобы программки типа простого редактора (если
> они расчитаны на мультибайт) могли читать/редактировать/сохранять
> utf-8. Надо только перед их вызовом установить LANG = en_US.UTF-8 (например).
>   Ну и фонты ей нужны "уникодные".
> (Желательно, чтобы программка была не слишком интеллектуальная. Чтобы не
> пыталась сама разбираться в чарсетах).

К сожалению, единственный пример такой программки -- xterm. Про его код автор
написал в комментарии... Я знаю 3 редактора m17n -- emacs, xemacs и Yudith.
Последний мне не нравится, а первые два со своей задачей, в основном,
справляются, хоть и не поддерживают пока utf8.

>
>
>   А вот как писать программу или тулкит, если хочется обязательно иметь
> внутреннее представление строк в utf-8?
>
>   Использовать setlocale(..., "") - бесполезно. Если юзер выставил LANG не
> на уникодную локаль, то ничего не получится.
>   Принудительно вызвать setlocale с именем локали...
>   А какой? en_US.UTF-8 ?
>   Пакость в том, что для нормальной работы нужно не только наличие этой локали
> среди иксовых (это то можно гарантировать), но и среди "системных".
>   Например в freebsd такой локали нет. Значит "из коробки" тулкит работать
> не будет.

>
>   Казалось бы можно использовать locale.alias, но ...
> А на какую локаль этот алиас ставить?
>
>   Кстати, может еще присутствовать локаль типа ru_RU.UTF-8, при отсутствии
> en_US.UTF-8.
>
>   Получается, что тулкит должен
> - попробовать установить локаль en_US.UTF-8. А если не получилось?
> - подошла бы любая другая с codeset UTF-8. А как узнать - какие есть?
> Стандартного вызова для этого нет. Самому тулкиту "парсить" locale.dir?
>   Плохо.
>   Можно попробовать - взять LANG, вычистить (если есть) codeset и подставить
> UTF-8. Во-первых, опять же плохо - LANG может содержать "укороченое" имя
> локали.
>   А во-вторых, опять же нет гарантии, что эта локаль имеется.
> - если первые два способа не прошли - остается только наплевать на locale
> и включать свой перекодировщик (keysym в Unicode).
>
>   Ну и как теперь уговаривать писателей тулкитов пользоваться новой
> "фичей"?
>   Пока en_US.UTF-8 или какая-нибудь all_UNIVERSE.UTF-8 не станет обязательной
> (как locale "C") во всех OC, вызывание этой новой "фичи" будет шаманством
> с названиями локалей или просто не будет работать.
>
> P.S. Вообще-то, мне кажется ошибкой как раз стремление непременно добится
> Unicode для внутреннего представления внутри тулкита.
>   Строки просто должны быть либо wchar (и загружаться с помощью XwcLookup,
> а из файла - что-то типа XawMBToWC), либо мультибайтовыми (только
> работать с ними надо соответствующими функциями).
>   Тогда и ввод и вывод (нужными фонтами) будет на совести libX11, которая
> и должна обеспечить "консистентность" ввода с клавиатуры , вывода нужным
> фонтом и преобразование в мультибайт для сохранения в файле.

Вот Postsriptum в Вашем письме -- лучше всего. Надо лишь обесчпечить  поддержку
_всех_ символов Unicode, чтобы не получилось как в (x)emacs, где виртуальный
шрифт не может содержать символы, отличные от ISO8859*  и восточных, а потому
украинское GHE_WITH_UPTURN на экран не выведешь (если честно пользоваться mule, а
не хаками).
Rgrds, AEN