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

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

  Привет!

  Я все-таки решил написать сюда о содержимом XLC_LOCALE.
Дело в том, что я в свое время так и не нашел в Интернете
какого-либо подробного описания. Так что, думаю - это
будет многим интересно.

  Прежде чем писать о конкретных "словах", придется сделать несколько общих
замечаний.

1. Эту часть Xlib (относящуюся к разбору XLC_LOCALE и использованию его
директив) писали японцы. И написали _плохо_.
  Дело даже не в том, что она написана очень неэфективно и с немалым
количеством "багов". Сомнения вызывают и некоторые исходные идеи.
  Поэтому, если что-то покажется слишком сложным или неэффективным, то ...
так оно и есть.
  К тому же баги в реализации приводят к тому, что для их "обхода" в
некоторых XLC_LOCALE приходится писать некоторые "лишние" вещи (чтобы
Xlib отрабытывала правильно).

2. Поскольку эту часть писали японцы, они прежде всего ориентировались
на сложные системы кодирования (алфавиты), которым не хватает одного байта
для представления всех символов.
  Кстати, собирательное название таких кодировок (JIS, EUC и т.п.) - CJK
(Chine, Japan, Korea).
  Остальные кодировки типа iso8859. Сюда же можно отнести и koi8-*, поскольку
они отличаются только порядком символов в своих таблицах.

3. Поскольку CJK-кодировки используют коды размером больше байта, существует
несколько способов их представления. Все они используются в Xlib.

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

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

compaund text (ctext или просто ct). Этот способ описан в отдельном документе
из дерева исходников "иксов" - CTEXT. И "восходит корнями" к стандарту
iso2022 (или ecma-35).
  Вообще-то, iso2022 сильно ориентирован на семибитное кодирование.
Любой charset должен занимать 94 или 96 "кодовых позиций". Если ему этого
мало, то он представляется двумя (или больше) байтами, каждый из которых,
опять же должен находится в диапазоне 96. Такие чарсеты называются 96^N.
  В программе (аппаратуре) можно одновременно задать до четырех разных
чарсетов и переключаться между ними специальными "контроловыми" кодами
G0-G3 (какие это цифровые коды - не помню, но это не важно).
  Для задания - какой чарсет по какому G* должен включаться, используются
специальные esc-sequence - "назначатели" (designator). Формат этих "секвенсов"
также описан в iso2022.

  Если система поддерживает восьмибитные коды, то в качестве переключателя
может служить восьмой бит. То есть, можно с помощью "назначателей" задать
два чарсета - для кодов 0-127 и для 128-255. В зависимости от того - в какой
диапазон попадает конкретный байт, система определяет - к какому чарсету
он относится.
  Вся кодовая таблица (0-255) делится на две части - GL (graphic symbols left)
и GR (... right). Точнее - частей четыре. В начале каждой половины первые
коды соответствуют не графическим символам а "управляющим".
  Итак - C0 (0x0 - 0x1f), GL (0x20 - 0x7f), C1 (0x80 - 0x9f) и GR (0xa0 - 0xff).
  Но как правило, подпрограммы Xlib в такие тонкости не вдаются и считают, что
частей всего две (GL, GR).

  Надо также заметить, что как правило в GL назначаются ascii (это и по
умолчанию, если не было никаких "назначателей"), а все национальные чарсеты
располагаются в GR. А GL части этих кодировок совпалдают с ascii.
(Вот поэтому, в Xlib и нет KOI8-R:GL. Оно ничем не отличается от ISO8859-1:GL)

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

  Итак, ctext это - восьмибитное iso2022 кодирование, с некоторыми
ограничениями на вид "назначателей".
  Обычно в начале текста в кодировке ct идет esc-sequence "назначатель", которая
говорит о том - как интерпретировать дальнейшие байты (как элементы какого
чарсета). Причем, как правило, назначается только GR часть. А коды из GL
интерпретируются как ascii (или iso8859-1:GL). хотя теоретически можно и их
переназначить.

4. Последнее замечание. Для кодировок типа iso8859 (как я сказал к этому типу
относятся и все разновидности koi8) все намного проще.
  Мультибайт состоит из одного байта. WC отличатся от него только размером.
А ctext - та же последовательность отдельных байтов, только перед ней
может быть "назначатель", который указывет - какой чарсет имеется ввиду.

  Продолжение следует...
-- 
 Ivan U. Pascal         |   e-mail: pascal@tsu.ru
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia