OberonCore :: - Поддержка юникода в BlackBox1.6rc5

ББ не поддерживает UTF!
С двухбайтовым CHAR имеется фактически безальтернативный UCS2...

Мы потихоньку отсылаем Оминк отчеты о тестировании.
В частности, сейчас пытаемся решить проблему с нац. идентификаторами, на которые завязались школы...

UCS-2 можно считать подмножеством UTF-16 (UTF-16 без суррогатных пар).

Просто в порядке уточнения. ucs2 - набор символов, а utf-8,16,etc. - кодировки. Так что одно никак не может быть подмножеством другого.

Есть предложение переходить на UTF16, не дожидаясь OM Inc.

GUEST писал(а):

Есть предложение переходить на UTF16, не дожидаясь OM Inc.

Каким образом? utf-16 - кодировка с переменной длиной символов, в отличие от ucs-2. Только если библиотеку писать, но ни в коем случае не на уровне компилятора!

GUEST, а вы символы за пределами первых 64K не пробовали?

Вы имеете в виду какой-то конкретно? А Вы пробовали?

Да это в стандарте прописано!

utf-16 ничем не отличается от utf-8 по своей сути. Просто "как есть" он передаёт первые 64k символов, вместо первых 256и.

Кроме того, CHAR фиксирован в стандарте языка, как Unicode. Из такого определения предположить что-то кроме ucs2 достаточно сложно.

Автор:	Кривохатько С.А. [ Вторник, 08 Май, 2007 12:22 ]
Заголовок сообщения:	Поддержка юникода в BlackBox1.6rc5
Несмотря на "BlackBox 1.6 is full Unicode support" столкнулся с рядом глюков. Например, при двойном щелчке на русскоязычном слове оно не выделяется целиком; диалог Find/Replace не ищет русскоязычные слова без учета регистра; поиск без учета регистра в файлах помощи работает странно - например не обрабатывает букву 'Т'; и т.п. Кроме того в каждом модуле поддержка юникода реализуется по своему, повторяя разными способами одну и ту же функциональность. Под юникодом подразумевается представление то в UTF8, то в UTF16. Нет единого механизма. Из более абстрактных проблем - например, не соблюдаются рекомендации стандарта юникода на коды символов разрыва линии и параграфа. Очевидно, что поддержка юникода даже в 1.6 требует серьезной доработки, в связи с чем предлагаю обсудить следующие впоросы: 1) Определится с внутренним способом представления юникодных символов: UTF8, UTF-16LE, UTF-16BE, UTF-32BE, UTF-32LE. 2) Для поддержки юникода необходимо будет либо изменять существующие процедуры/функции(например CAP, Strings.Lower) нарушая спецификации, либо вводить дополнительные с другими именами. 3) Способ реализации единого, сквозного механизма работы с юникодом. Что скажете, господа?

Автор:	Кривохатько С.А. [ Вторник, 08 Май, 2007 13:40 ]
Заголовок сообщения:
По отдельности эти вопросы уже обсуждались. Но в 1.6rc5 изменили формат объектного файла и убрали некоторые подсистемы, и в результате требуется переделка/перекомпиляция существующего кода. Народ отнесся вполне терпимо к этому. Т.е. имеем удобный момент для внесения изменений/дополнений. Иначе придется отложить реализацию юникода до какого-нибудь BlackBox 2.0

Автор:	Info21 [ Вторник, 08 Май, 2007 16:01 ]
Заголовок сообщения:	1.6
нужно сообщать Оминк обо всем этом.

Автор:	Илья Ермаков [ Вторник, 08 Май, 2007 22:38 ]
Заголовок сообщения:
ББ не поддерживает UTF! С двухбайтовым CHAR имеется фактически безальтернативный UCS2... А изменения действительно надо "добивать" сразу. Мы потихоньку отсылаем Оминк отчеты о тестировании. В частности, сейчас пытаемся решить проблему с нац. идентификаторами, на которые завязались школы...

Автор:	Кривохатько С.А. [ Вторник, 08 Май, 2007 23:18 ]
Заголовок сообщения:
Илья Ермаков писал(а): ББ не поддерживает UTF! С двухбайтовым CHAR имеется фактически безальтернативный UCS2... Да, согласен, его реализовать будет проще, хоть он и считается устаревшим. Хотя к размерности CHAR это отношения не имеет. Просто в UTF-16 допускаются комбинации из двух CHAR, а в UCS2 - нет. UCS-2 можно считать подмножеством UTF-16 (UTF-16 без суррогатных пар).

OberonCore https://forum.oberoncore.ru/

Поддержка юникода в BlackBox1.6rc5 https://forum.oberoncore.ru/viewtopic.php?f=3&t=453	Страница 1 из 3

Автор:	Иван Горячев [ Среда, 09 Май, 2007 02:09 ]
Заголовок сообщения:
Кривохатько С.А. писал(а): UCS-2 можно считать подмножеством UTF-16 (UTF-16 без суррогатных пар). Просто в порядке уточнения. ucs2 - набор символов, а utf-8,16,etc. - кодировки. Так что одно никак не может быть подмножеством другого.

Автор:	Trurl [ Среда, 09 Май, 2007 10:06 ]
Заголовок сообщения:
Ivor писал(а): Просто в порядке уточнения. ucs2 - набор символов, а utf-8,16,etc. - кодировки. Так что одно никак не может быть подмножеством другого. Не ucs2 - тоже кодировка.

Автор:	Сергей Оборотов [ Среда, 09 Май, 2007 11:18 ]
Заголовок сообщения:
Есть предложение переходить на UTF16, не дожидаясь OM Inc.

Автор:	Иван Горячев [ Среда, 09 Май, 2007 14:23 ]
Заголовок сообщения:
GUEST писал(а): Есть предложение переходить на UTF16, не дожидаясь OM Inc. Каким образом? utf-16 - кодировка с переменной длиной символов, в отличие от ucs-2. Только если библиотеку писать, но ни в коем случае не на уровне компилятора!

Автор:	batyrmastyr [ Среда, 09 Май, 2007 23:02 ]
Заголовок сообщения:
GUEST писал(а): Есть предложение переходить на UTF16, не дожидаясь OM Inc. Тут есть проблема - шрифтов которые поддреживают даже 2 байт юникод не так уж много, а 4 байт должно быть еще меньше. для хранения в оперативке подходят ucs2 ucs4 utf32 и, возможно, ucs32(если кто знает, что это за зверь такой). поддержка юникода сейчас, насколько понял, сводится к ucs2 и utf8. А utf16- ни рыба, ни мясо.

Автор:	Иван Горячев [ Четверг, 10 Май, 2007 00:16 ]
Заголовок сообщения:
GUEST, а вы символы за пределами первых 64K не пробовали? И ччто значит "единый формат символов"? А сейчас CHAR не единый?

Автор:	Сергей Оборотов [ Четверг, 10 Май, 2007 01:20 ]
Заголовок сообщения:
Как Вы полагаете войдут символы за пределом первых 64К в диапозон типа CHAR? С большой степенью вероятности могу предсказать, что нет. Поэтому предлагаю перенести диапозон в которым коды символов не укладываются в фиксированные 16 разрядные значения UTF16-кодов в область, которую ей соответствует в диапазоне 32 разрядных значений UTF32-кодов. После чего можно будет сказать, что собственно у самого UTF16 все значения лежат в диапозоне типа CHAR, а для остальных существует UTF32 и тип LONGCHAR. Если понадобится последний, в чем я очень сомневаюсь пока. На таких условиях единый тип сейчас - CHAR. PS. Ivor писал(а): GUEST, а вы символы за пределами первых 64K не пробовали? Вы имеете в виду какой-то конкретно? А Вы пробовали?

Автор:	Борис Рюмшин [ Четверг, 10 Май, 2007 15:12 ]
Заголовок сообщения:
ucs2... собственно, это то, что применяется в винде и Яве. Utf-8 поддерживать, конечно можно попробовать, однако не на внутренных структурах, а только на экспорт. Иначе слишком много придется переделывать для поддержки многобайтовых кодировок. Кроме того, CHAR фиксирован в стандарте языка, как Unicode. Из такого определения предположить что-то кроме ucs2 достаточно сложно. Да, и не следует забывать, что CHAR делался именно для совместимости с Явой. Кстати, Бутылка работает на UTF-8, никото не смотрел внутрь, на реализацию?

Страница 1 из 3	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Автор:	Иван Горячев [ Четверг, 10 Май, 2007 00:23 ]
Заголовок сообщения:
batyrmastyr, шрифты - не самая большая проблема. Для большинства языков хватит и двубайтовых символов. К тому же LONGCHAR - явный перерасход памяти, более чем в два раза. Да, ещё есть вопрос совместимости с дрругими оберонами. Двухбайтовый CHAR есть в gpcp и active oberon, а четырёхбайтовый?

Автор:	Борис Рюмшин [ Четверг, 10 Май, 2007 15:17 ]
Заголовок сообщения:
Да и de facto, сейчас достаточное распространие имеют (во всяком случае для обычных языков) ucs2, на уровне ОС - в винде и UTF-8 в интеренете (стандарт XML, и, как следствие, XHTML, остальное в нём допускается только для обратной совместимости, на сколько я помню). Также в последнее время UTF-8 настоятельно рекомендуется для использования в качестве локали Linux.