[Comm] UTF-8 а Master 2.2 [JT]

[Anton Kovalenko]

>>>>> Aleksey Novodvorsky writes:

    >>  2.  поддержка bash  (readline),  textutils, fileutils  с
    >> точки зрения UTF8

    > Поддержка  UTF-8   базовыми  утилитами  Unix  --  большая
    > проблема, так как  требует их  серьезного концептуального
    > пересмотра  и тщательного  аудита. Мое _личное_  мнение --
    > сквозной  переход   Unix  на  UTF-8  locales  практически
    > невозможен,  так  как  приведет  к  большим  проблемам  с
    > security.

Это очень странно слышать.  Сквозной переход на UTF-8 locales --
попросту  бессмысленен.  А  вот корректная  поддержка  multibyte
characters,  _частным  случаем_ которой  является  UTF-8 --  уже
становится традицией.

Что же  касается security, --  в системе, где имена  файлов case
sensitive, да  ещё с такой приличной кодировкой,  как UTF-8 (где
невозможен  \000  в  середине  строки, где  любой  встретившийся
символ  из  диапазона ascii  всегда  означает  самого себя,  где
никакой ascii-символ не  имеет альтернативного представления) --
непонятно, откуда возьмутся проблемы.

    >  Ввод/вывод  UTF-8  поддерживается  в  KDE,  Gnome2,  OOo,
    > Mozilla, большинстве программ с GUI.

Это   они  зря.   Ломают  устоявшиеся   и   _вполне  работающие_
классические иксовые  решения для  i18n, только для  того, чтобы
работать с символами "вне локального charset". Впрочем, некоторым из них
простительно -- портабельность под Windows требует жертв. 
Вот и Tk можно за это простить.

    >> 3. поддержка UTF-8 в ncurses
    >> 
    > Нет

Это при том, что upstream всё давно оттестировано и работает.

    > Что касается перехода  к единой (и единственной) кодировке
    > всей системы,

А эту реплику,  товарищи, мы с негодованием отметаем.  От неё за
версту  разит .... экзистенциоа...  ао... нализьмом  и неверием,
товарищи, в прогрессивную мощь  человечества. В общем, не на тот
идеал смотрите.

Единая   кодировка  для   обмена   информацией  между   иксовыми
приложениями  -  COMPOUND_TEXT.  Единая кодировка  для  удобного
хранения  строк  _внутри одного_  приложения  - wchars  (кстати,
постулировать,  что  "на  самом  деле wchars  --  это  unicode",
нельзя).

А для  utf-8 роль Единой  и Единственной вовсе не  подходит. Она
просто частный случай в зоопарке многобайтовых кодировок. Причём
один из самых простых частных случаев.

P.S.

Между   прочим,  довольно  интересно   наблюдать  за   тем,  как
развивается почти любой open-source проект, где одним из авторов
(или контрибуторов) становится японец. У такого проекта два пути
-- либо  там   появляется  нормальная  (с   моей  точки  зрения)
поддержка   i18n,   либо   рождается   "японизированный"   fork,
бесполезный всем остальным. Но первое бывает чаще, что не может
не радовать.

-- 
With Best /usr/bin/wishes, 
Anton Kovalenko /* http://kovalenko.webzone.ru */