[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

X'ы, "ескейп-секвесы" и ISO-IR-111

    Привет!

  Во время моих разбирательств с кодировками и "чарсетами" в X-Window,
я наконец-то обратил внимание на "чарсет", который называется
ISO-IR-111 или ECMA-Cyrillic.

  Вообще-то, я и раньше встречал упоминание о нем (например в
"The Cyrillic Charsets Soup", ссылка на который есть у Александра).
Но как-то не обращал внимание, как на очередной полумертвый стандарт.

  Так вот. На самом деле это - "KOI8 де-юре". Напомню, что распространенный
koi8-r (Relcom's koi8-r) стандартом не является. Тот RFC1489, на который
обычно ссылаются не более чем "мемо", а вовсе не стандарт.

  Отличия между IR-111 и koi8-r конечно есть.
В кои8 добавлена "псевдографика", зато IR-111 имеет недостающие буквы
других кирилличских алфавитов (Украинского, Белорусского, Болгарского и т.п.).
  К сожалению, в нем отсутствует "GHE WITH UPTURN", но она и так выпадает
из всех стандартов.

  С другой стороны, то, что мы сейчас имеем в "иксах" под названием koi8-r,
не является ни Relcom's KOI8-R (поскольку в нем отсутствут псевдографика,
как в "фонтах", так и в раскладке клавитатуры), ни IR-111 (поскольку
содержит только буквы русского алфавита).
  Таким образом, "иксовый" koi8-r ("r" очевидно означает - restricted :-)
с одинаковым успехом можно считать как подмножеством Relcom's koi8-r,
так и IR-111.

  Как я уже заметил, ISO-IR-111 является действительно неким стандартом
и ему уже выделена законная escape sequence - 033-@.

  Спрашивается - какая "добрая душа" воткнула в "иксы" esc-sequence
\033%/1\200\210koi8-r\002 ?
(к тому же неправильную, должно быть ...\200\211...)

   Надо заметить, что разница в esc-seq - вопрос очень важный.
Дело в том, что "иксовый" стандарт на COMPAUND TEXT (для которого и нужны
эти sequences) весьма "дубовый".
  И если строки, начинающиеся на последовательности типа \033-<буква>
он трактует как "символы из GR-набора размером до 96 символов",
(каким и является наша кириллица), то последовательности, начинающиеся
с \033% он понимает очень плохо.

  -  Во-первых, знак "%" означает в нем "Other encoding" (что, в общем-то
соответствует более широкому стандарту ISO-2022/ECMA-35), но...
  - после этого он допускает только "/<цифра>" - "Non standart, с явным
указанием размера таблица" (Кстати, из-за этого "CT-парсер" напрочь
не понимет последовательности \033%B - UTF1 и \033%G - UTF8, хотя
в ISO-2022 они стандаризированы)
  - в результате "\033%/1\200\210koi8-r\002" означает - "какой-то левый
чарсет типа GLGR (то есть, коды могут быть и в диапазоне 0x0 - 0x7f, и
в дапазоне 0x80 - 0xff) длиной 1 байт на символ"
(как я уже сказал, \033-@ будет означать - "стандартный чарсет, в котором
коды занимают диапазон 0x80 - 0xff")

  - Во-вторых, из-за ошибок в Xlib (правда одну из них "пофиксили" в каком-то
из последних "фиксов") некоторые процедуры, используемые X[mb|wc]LookupString,
вообще не знают - что делать с "чарсетами" типа GLGR.
   Если мы этого не ощущаем, так только потому, что в XLC_LOCALE для koi8
все чарсеты KOI8-R "продублированы" чарсетами ISO8859-1. То есть, как раз
строчки типа KOI8-R:GL/KOI8-R:GR никем не используются, а все преобразования
проходят так, как для символов из ISO8859-1.

  - В-третьих. Даже если "пофиксить" все процедуры Xlib на понимание GLGR,
все равно получается не очень хорошо. Поскольку koi8-r все таки
"классический GR", отнесение его к GLGR только усложняет обработку кодов
из этого набора (я "с ходу" не могу назвать - где и как, но понятно,
что простоты это не добавляет).

 - Ну и наконец - посдедовательность для ISO-IR-111 гораздо короче
(во всяком случае strcmp() будет работать быстрее :-)

  Итак. Надо выкидывать нестандартную последовательность для koi8-r из X'ов
и заменять на стандартную (пожалуй, попробую это сделать после отпуска).

  Кстати, разглядывание этого IR-111 навело меня на мысль, что и "укрианизация"
в XFree86 сделана "не лучшим образом".
  Сейчас в Xlib добывили еще одну таблицу перекодировки, которая просто
"перекрывает" koi8-r. То есть koi8-r является подмножеством koi8-u.
К тому же, обе они являются подмножествами IR-111. (Ну, за исключением
несчастной GHE-WITH-UPTURN. Эх. Где вы хлопци были, когда стандарты
"узаконивались"? :-)

  Поэтому надо убирать вообще из Xlib KOI8-R и оставлять IR-111.
Пусть он даже называется KOI8-U ("universal" вместо "restricted" :-).
  А проблему совместимости с "грузом прошдого" можно решить с помошью
"алиасов". Как для "локалей", так и для "фонтов".

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