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

[Mikhail Zabaluev]

Hello Anton,

On Thu, Mar 06, 2003 at 06:20:44PM +0300, Anton Kovalenko wrote:
>
>     >>  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.

Ну да, ужас пострашнее MIME, придуманный, наверное, в минуту
отчаяния от заскорузлости стандарта X.

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

Насчёт неидентичности wchar_t и Unicode -- верно подмечено.
И многие среды разработки (не включающие в настоящий момент
GNU) даже с Unicode попали в ловушку 16-битных символов.
Всё это ставит под сомнение портируемость кода с wchar_t,
ведь даже принцип "один wchar -- один символ" не соблюдается.
Более того, наличие в Unicode комбинирующих символов
делает понятия "символ как номер в машинном представлении"
и "символ как единица текста" неэквивалентными, заставляя
прибегать к сложным схемам канонизации.
Насчёт удобства хранения не всё так однозначно:
строки из правильных (32-битных) wchar_t сжирают уж
слишком много места при преимущественном пользовании
ASCII.

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

Замечательные свойства, подмеченные Вами, делают UTF-8
лучшим из возможных кандидатов на универсальную кодировку.

-- 
Stay tuned,
  MhZ                                     JID: mhz на altlinux.org
___________
I'm still waiting for the advent of the computer science groupie.