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

[Ivan Pascal <pascal@info.tsu.ru>]

  Привет!

  У меня вопрос скорее теоретический.

  Ну вот есть теперь в 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 (например).
  Ну и фонты ей нужны "уникодные".
(Желательно, чтобы программка была не слишком интеллектуальная. Чтобы не
пыталась сама разбираться в чарсетах).

  А вот как писать программу или тулкит, если хочется обязательно иметь
внутреннее представление строк в 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, которая
и должна обеспечить "консистентность" ввода с клавиатуры , вывода нужным
фонтом и преобразование в мультибайт для сохранения в файле.
-- 
 Ivan U. Pascal         |   e-mail: pascal@tsu.ru
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia