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

Re: Re: Re: Re: Re: а ну её на фиг, эту Xkb.



> On Mon, Jul 03, 2000 at 22:43:59 +0100, Vladimir NOVIKOV wrote:
> 
> > Но ведь совместимость со старьем, мать ее, и.т.д.
> > 
> > Почему все так лезут на utf8? Смотри, все коммерческие 
> > юниксы, BeOS, MacOS X, Berlin Windowing System. Значит что-
> > то есть?
> 
> Недаром UTF-8 изначально называлось File System Safe UTF.  Собственно
> ничего, кроме совместимости с ascii-minded программами, UTF-8 не дает.
> Обрабатывать текст *внутри* уникодного приложения в UTF-8 - это как
> хранить строки в азбуке Морзе.
> 
> Само название Unicode *transformation format* говорит за себя.

  Вот нет чтобы послать человека куда-нибудь. :-)
  Только куда?
  На http://www.unicode.org/ слишком много всего, сразу не разберешься.
А посылать к Александру на "Locale AS IS" бесполезно (надеюсь - _пока_
бесполезно :-).
  Ну можно хотя бы к Czyborr'е - http://czyborra.com/

  Хоть кто-нибудь объяснил бы внятно, что
- для Unicode есть два способа кодирования UCS и UTF
- UCS - это просто под символ выделяется переменная размером больше чем байт
  16-битная - UCS-2 или 32-битная UCS-4
- с ними (UCS кодами) можно работать как и с байтами - считать длину,
сравнивать посимвольно, находить i-ый символ в строке (естественно, для этого
используются отдельные подпрограммы, которые знают, что - один символ это
переманная типа int или long)
- но вот эти UCS очень плохо передавать (копировать, пересылать "мылом" и т.п.)
через программы, которые считают, что в текстах могут быть только байты
  Проблема и в том, что при сохранении например 00000041h (буква A) в файле
появятся нулевые байты, и в том, что разные платформы по разному интерпретируют
порядок байтов в длинных переменных ( указанную букву можно записать в файл
как 00 00 00 41 и как 41 00 00 00)
- для решения этих проблем придумали семейство UTF (Unicode Transformation
Format). Самый популярный - UTF8, хотя есть (или были) UTF1, UTF7, UTF7.5,
UTF16.
- В этих форматах каждый UCS код преобразуется в последовательность "легальных"
байтов, но эта последовательность - ПЕРЕМЕННОЙ ДЛИНЫ.
(код 00000041 в UTF8 кодируется как один байт - 41, код 000000A0 - C2 A0,
код 00002000 - E2 80 80  и т.п.)
- естественно, нормально работать с такими строчками в программе НЕВОЗМОЖНО
(можно только НЕ нормально).
  Поэтому, внутри программы Unicode надо держать в виде UCS - кодов большой
длины, но фиксировнного размера, и только сохранять в файле имеет смысл в UTF8

(Кое к чему здесь можно придраться, но в целом - примерно так.)
-- 
 Ivan U. Pascal         |   e-mail: pascal@tsu.ru
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia