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

["Alexander Voropay" <a.voropay@globalone.ru>]

>  Я все-таки решил написать сюда о содержимом XLC_LOCALE.


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

>1. Эту часть Xlib (относящуюся к разбору XLC_LOCALE и использованию его
>директив) писали японцы. И написали _плохо_.


 Дык а кому же ее еще было писать ? Американцам, с их твердой
уверенностью, что других языков просто не существует ? ;-)
А в России скроме CM-4 с зеленым дисплеем и DEMOS 2.9
других UNIX-ов не было... Не до X-ов... ;-)


>  Кстати, собирательное название таких кодировок (JIS, EUC и т.п.) - CJK
>(Chine, Japan, Korea).


 Кстати, тут есть такой тонкий момент : если мы начинаем говорить о
multibyte,
то в отличии от обычных 8-ми битных Charset-ов мы встречаем ситуацию,
когда название Character Set (набора символов), а вернее CCS отличается
от названия Метода Кодирования : Character Encoding Scheme (CES).
Очень приблизительно и поверхностно (только для 8-ми битных Charset-ов)
про то, в чем разница между CCS и CES написано у меня :
http://www.sensi.org/~alec/locale глава [Языки, символы и кодировки].

 То есть, стандартизированный японский Набор Символов JIS X 0221-1995
(CCS) может кодироваться несколькими разными способами (CES):
- ISO-2022-JP
- Shift-JIS
- EUC-JP
 И еще несколькими другими. То же самое с китайскими и корейскими
CCS и CES

  И вообще у японцев большая проблема с WEB : JIS и EUC прмерно как
у нас WIN/DOS/KOI . Хоть "nihongo apache" делай. :-)

 И насчет CJK. Это довольно хрупкое объединение, которое встречает
множество противников. Например, японский и китайский -- это СОВЕРШЕННО
разные языки. Просто в японском заимствована система письменности :
kan-ji (Ханьские (китайские) знаки). Но заимствована она была очень
давно и для собсвенных нужд японца изобрели еще две слоговые азбуки :
хирагану и катакану. Поэтому все японские Charset-ы обязательно
содержат кану, в то время как ничего подобного китайцам просто не
нужно. А национальные charset-ы (не UNICODE) иногда содержат
уникальные иероглифы, которых нет в UNICODE.

 Более того, объединение в UNICODE всех иерогифов в единую "Han
Unification" кучу вызывает протесты, поскольку чтение и значение
некоторых иероглифов значительно расходится. Вот например есть
"LATIN CAPITAL LETTER A" и "CYRILLIC CAPITAL LETTER A".
По графике они совершенно идентичны. А почему иероглифы свалены
в кучу ?

 Но это я так, отвлекся. :-)
См. ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf

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


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


 Тип wchar_t ДОЛЖЕН быть 32 бит для поддержки ISO_10646. Но не
все это делают, считая что можно обойтись UNICODE (16-бит).

 В принципе, в настоящее время все _полагают_ что в переменных
типа wchar_t сидит UNICODE. Но в BSD и Plan9 системах живет еще
такой древний тип : rune_t . Это пережиток времен, когда UNICODE
еще не было. Сейчас в глубине #define-ов все-таки объявляется
rune_t как wchar_t . НО ! кодировка в rune_t -- это НЕ UNICODE !
(не UCS-2/UTF-16) (если пользоваться стандартными BSD/Plan9
библиотеками). Это какая-то своя собственная 16 (32)-битная кодировка.
См. rune(3) .
Как я понял, в Xlib, внутри wchar_t -- тоже не UNICODE ?

>  Общее представление о том - чем mb отличается от wc можно подсмотреть
>в Unicode. UCS - это типичный wc, а любой UTF - mb. Естественно, в разных
>CJK-кодировках это преобразование может делаться по-разному.


 Во-во. Именно по-разному. Поведение 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) кодировке.


>  Для задания - какой чарсет по какому G* должен включаться, используются
>специальные esc-sequence - "назначатели" (designator). Формат этих
"секвенсов"
>также описан в iso2022.


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


>(Кстати, если сторого следовать стандарту iso2022 и соответственно
"иксовому"
>CTEXT, то под кириллицу отводится только 96 code points. Если к русскому
>алфавиту добавить недостающие украинские/белорусские/сербские буквы, то
>на пунктуацию и псевдографику уже ничего не остается.)


 Ну, если бы все следовали стандартам... Вот например кодировка CP-866
просто кладет болт на iso-2022. И например обычному xterm должно
становится сильно плохо при попытке вывести русский текст в CP-866 :-)

 Короче, все по-видимому склоняется к тому, чтобы весь CTEXT загнать в
UTF-8.
Похоже XFree 4.0 именно таким и будет. Как сделано например в Java (JVM),
где все строки "внутри" JVM хранятся в UTF-8.

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

--
-=AV=-