Re: "Поподробнее об XLC_LOCALE"

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

>  Отлично ! Мне кажется, что у работ подобной этой, вообще нет
> аналогов в мире :-)

  Спасибо!
  Только я бы изменил "смайлик" на обратный ":-(".
Аналогов в мире (в доступном для поиска Интернете) я действительно не нашел.

>  Кстати, тут есть такой тонкий момент : если мы начинаем говорить о
> multibyte,
> то в отличии от обычных 8-ми битных Charset-ов мы встречаем ситуацию,
> когда название Character Set (набора символов), а вернее CCS отличается
> от названия Метода Кодирования : Character Encoding Scheme (CES).

  Согласен. Действительно, правильнее называть это "метод кодирования".
Кстати, и XLC_LOCALE описывает именно "метод кодирования".

>  И насчет CJK. Это довольно хрупкое объединение, которое встречает
> множество противников.

  Ну, я его так назвал для краткости.
Естественно, подразумевалось просто "кодировки, которым мало одного байта
на символ". По идее, и Unicode - туда же.

>  Собственно, для "большого" Charset-a (CCS) UNICODE, а точнее
> ISO_10646 ситуация та же самая : он может иметь несколько схем
> кодирования (CES) : UTF-8, UTF-7, UTF-16 (бывший UCS-2) и еще
> несколько (например с компрессией, Reuter ).

  Угу. Если составлять на них XLC_LOCALE, то их должно быть несколько
(*.utf8, *.utf16 и т.п.). Все они с одинаковым представлением в wc и
с разным mb.

> >wide char (или wc) - под символ отводится тип большего размера чем байт
> >(w_char). К сожалению, в разных ОС тип w_char имеет разный размер.
> >Хотя обычно для CJK достаточно 16 разрядов, в большинстве систем этот тип
> >имеет размер 32, но в некоторых - 16. (Из за этого могут различаться
> >параметры вида wc_* из XLC_LOCALE).
> 
>  Тип wchar_t ДОЛЖЕН быть 32 бит для поддержки ISO_10646. Но не
> все это делают, считая что можно обойтись UNICODE (16-бит).

  Маленькое уточнение. Если смотреть не сами XLC_LOCALE, а их "сырцы",
то там, практически в каждом встречается директива
#if WCHAR32
от нее зависит вид wc_shift_bits, wc_encoding, wc_encoding_mask.
  Если сходить в X11R6/lib/X11/config и поискать по файлам *.cf
("опции" для разных ОС) словечко HasWChar32 (именно оно превращается
в #define WCHAR32), то можно обнаружить, что ...
 - оно есть для всех видов BSD, linux, hp и т.д.
 - отсутствует в основном в "экзотических" ОС'ах - Amoeba, cray, ibm (AIX),
macII, Win32 :-)))

>  В принципе, в настоящее время все _полагают_ что в переменных
> типа wchar_t сидит UNICODE.

  Э-э-э. Не соглашусь.
  Содержимое wchar может быть разным для разных locale.
  Не знаю - как сейчас с этим в glibc. Но в "фришной" libc, например,
для простых locale в wchar просто тот же байт.

> Как я понял, в Xlib, внутри wchar_t -- тоже не UNICODE ?

  Ну уж это точно. Хуже того - он не совпадает и с libc'ишным wchar.
Хотя, как я уже писал, этого можно было бы добится просто подправкой
самих XLC_LOCALE.

>  Во-во. Именно по-разному. Поведение POSIX (и ANSI C) функций типа
> wctomb и mbtowc ТОЖЕ должно меняться в зависимости от текущей
> locale : ja_JP.Shift-JIS, ja_JP.EUC-JP или ja_JP.UTF-8 .
> А не только поведение функций Xlib.
> И результатом mbtowc _должны_бы_ быть UNICODE (ISO_10646) значения
> при любой mb (CES) кодировке.

  Опять же - не уверен. POSIX'а по рукой нет, но...
JIS явно имеет свое "длинное" представление. Кириллица там (если не ошибаюсь)
имеет коды 07**, греческий - 06**.
  Чем это не wchar? И куда же девать эти коды, если wchar - именно Unicode?

>  Кстати, утверждается что UTF-8 нормально попадает в стандарт iso-2022
> проходя по пункту "прочие кодировки". И даже последовательность для
> переключения в UTF-8 в ISO 2022 зарегистрирована. См. пункт про
> "терминальные эмуляторы" в :
> http://www.cl.cam.ac.uk/~mgk25/unicode.html

  Ну, не совсем так.
В iso2022 определен вид "назначателя" для переключения в "другие системы
кодирования" - DOC (Designate Other Coding system). Он имеет вид Esc%<буква>.
  Но никаких описаний этих "систем кодирования" как и самих "букв" в самом
iso2022 нет. Сами буквы назначает IR (A - Videotext/Teletext, B - UTF1,
C и D - CCITT T.101 и т.д.).
  Так что, говорить о том, что "UTF-8 попадает в стандарт iso2022" - некоторая
натяжка. :-)

>  Короче, все по-видимому склоняется к тому, чтобы весь CTEXT загнать в
> UTF-8.

  Да не надо его "загонять". Пусть CTEXT пока остается "для совместимости".
А UCS/UTF надо просто добавить в Xlib, как еще один универсальный способ
представления.
  (И дополнить Xlib функциями XutfLookupString, XucsLookupString.
А потом ... приучить всех разработчиков applications ими пользоваться :-))))

> Похоже XFree 4.0 именно таким и будет.

  Кстати, откуда такие сведенья, что в 4.0 будет нормальный UTF.
Судя по последним "снапшотам" (3.9.15, 3.9.16) там ничего не меняется.
(Только "баги" плодятся от новых чарсетов, типа "georgian-academy".)
  Да и по "сведениям от конфедициальных источников" никто в Xfree team
этим всерьез не занимается.

>  IMHO, еще одна ошибка была сделана, когда keysym-ы сделали 16-битными,
> но не UNICODE.

  Yes-z-z-z!
  Теперь они накрутили кучу таблиц, чтобы только каждому 16-битному Xkeysym
сопоставить 16-битный UCS-2.
  Сделали бы для начала хоть какую-нибудь "переменную окружения" типа
UNICODE_KEYBOARD и "раскладки" на этот случай.
  Большинство приложений (если это не ted :-) этого даже не заметили бы.

-- 
 Ivan U. Pascal         |   e-mail: pascal@tsu.ru
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia