OberonCore

о проблемах Юникода в статье " 'Проблема кодировок': стечение обстоятельств или стратегический замысел?" http://consumer.nm.ru/kod.htm

На http://sage.h15.ru/?e0l0 утверждается, что в BlueBottle 4 байт UCS32.

Так что вопрос какую кодировку- Unicode (utf-7, utf-8, UTF16, UTF16LE, UTF16BE, UTF32, UTF32LE, UTF32BE), UCS32 (это-юникод или нет?) или японский JIS X 0208-1990 использовать в качестве основной открыт.

UTF-8 хорошо бы было. В Bluebottle именно он (если склероз мне не изменяет).

Двухбайтовый CHAR и сложившаяся традиция нам выбора не оставляет. В BlackBox вариант юникода UCS2.

Насколько я понял кроме несколькольких стандартов таблиц символов, существует несколько стандартов их хранения-передачи. По моим впечатлениям символы utf8 хранятся с переменной длинной- разница в длине между абзацем ascii и utf8 английского текста-3 байта (537 и 540 символов), русского ~2раза (270 и 510).

С BlueBottle вообще странное что-то- вот выдержка из FAQ

И из Support List

как это понимать?

UTF-8 - это кодирование переменной длинны. Стандартные ASCII занимают 1 байт. Русский язык в частности - 2 байта. UCS2 - фиксированный, 2 байт, применяется в Windows.

В BlueBottle русский язык поддерживается (даже китайский поддерживается ). Правда криво - шрифт никуда не годится. Способ ввода... хм... какой-то комбинацией клавиш. Я сейчас не помню. Но не стандартной. Там где-то написано, как бы не в Tutorial...

Никто не хочет купить книжечку со стандартом Unicode 5.0?

http://www.unicode.org/

А зачем покупать? Вся нужная информация уже на винте

Не знаю что в книге, но таблицы символов раздаются по цене 30мег трафика http://www.unicode.org/Public/5.0.0/cha ... Charts.pdf

Цитата:

This directory contains a single PDF file containing a complete set of
character code tables and list of character names for The Unicode
Standard, Version 5.0.

Однакож приводить BlackBox к единой кодировке кажись надо. ..будет, может сразу к 3 или 4 байтам? цитата из данной ранее статьи

Собственно такой процесс сейчас и идет. Как я уже выше сказал, юникод введен в язык в виде двубайтового CHAR. Это означает, что близлежащий вариант только один - UCS2.

Уникод как решение проблемы имеет недостатки. Например
двукратный рост обьема текстов прямо приводит к замедлению его
обработки. Экономные варианты уникода? Там другой неочевидный
источник замедления за счет усложнения алгоритмов обработки
и утраты вследствие этого возможности прямой аппаратной их
поддержки. Ветвлений современные процессоры не любят.
Ну а кому выгодно это замедление отличных от английского языков
- ясно всем... Так же как гигабайты требований Висты выгодны
небезызвестным акционерам фирм-производителей памяти и
жестких дисков))

Как альтернативную попытку посмотрите например проект
кодировки Розетта. Они вроде заявляли сохранение восьмибитных
алгоритмов обработки. Просто у них кодировку имеют слова а не символы.
Так что если будет надо, символы разных языков отображу, способ знаю))

Далее. Мне хватит одного русского. И я для себя лично
проблему кодировки и лицензионности решил разом - ушел с Виндовс
на Линукс/НетБСД и просто постулировал везде использовать КОИ8Р.

Уникод для меня, как и ХМЛ, всего лишь формат ОБМЕНА данными а
НЕ ХРАНЕНИЯ ИЛИ ОБРАБОТКИ. И я по мере сил буду сопротивляться
введению ОЧЕРЕДНЫХ всеобщих)) и единых)) кодировок, лишь
увеличивающих в итоге общий бардак. Пусть внутри ВСЕ будет в
КОИ8, SHORTCHAR. А для общения со внешним миром у меня будут
конверторы из нужного варианта уникода, из CHAR.

...ББ давно на паузе у меня, слишком виндовый.
Долго копался в mocka(modula2) над статическими уцЛибс.
Довел ее до более-менее удобного состояния, внес несколько
мелких модификаций. Для написания мелких утилит пойдет. Сейчас
копаюсь в linz oberon v4, возможно посмотрю углубленно system3 если
простого v4 не хватит как универсальной платформы для расширяемого
приложения, сетевого сервера. Веб-сервера в частности.
А все эти Оберон-системы давно работают под Линуксом и это хорошо))

?? Если брать обработку больших массивов текста на внешних носителях - то да.
А если обработку строк в программе, то эффект обратный - хотя бы из-за того, что работа с двухбайтными словами происходит быстрее, чем с отдельными байтами.

Спокойно, товарищи. Юникод это уже не "как решение проблемы", а свершившийся факт.

Да ну, чушь.

И относится к нему надо как к осознанной необходимости.

Может, и чушь. Интуитивно кажется, что так

UTF-8 только в файлах на диске... (С моими кодерами и декодерами теперь можно хоть в CP866 сохранять )
Когда файл открывается редактором, "на лету" перекодируется в UCS32 (4 байта)
Поддержка любых мыслимых кодировок обеспечивается соответствующими кодерами и декодерами.
UTF-8 для cjk (China Japan Korea) кодировок не подходит (суммарное количество иероглифов превышает число 65536)!
Для кириллицы, значащие биты в юникоде похоже совпадают с UCS32
Вроде-ж всё понятно изложил http://sage.com.ua/ru.shtml?e1l2

Так, что что-бы не обидеть cjk -- UCS32 MUST HAVE!

UTF-8 может закодировать 2147483648 символов- гораздо больше, чем есть и будет в юникоде.

Спасибо за инфу!
Но поскольку UTF-8 переменной длины, то очевидно UCS32 удобнее для представления текста в памяти поскольку его длина фиксированна.
В Bluebottle символ текста определяется в AosTexts.Mod как:

а строка таких символов:

Для того что-бы получить текст из какого-либо редактора
служит единственная процедура:

которая возвращает в массив строку UTF-8
Только вот что-бы вставить текст в редактор нужно самим преобразовать UTF-8 (или что там у нас) в UCS32

и добавить процедурой:

объявленной в объекте UnicodeText в модуле AosTexts.Mod
Пока писал свой UDPChat изучил досконально

И чего это Бутылку никто не изучает?

Работала бы под VMWare - я бы изучал.

Запускаться запускается... но, согласен, работой это назвать сложно... тормозит.
Я на отдельный раздел сначала поставил... А потом вообще отдельный системник собрал из б/у комплектующих
Celeron 1 GHz 128 Mb памяти -- на сегодняшний день копейки...

Вобщем UCS32 и есть почти Unicode...
Только правильнее её называть UCS-4
http://www.unicode.org/standard/principles.html