OberonCore

Существует ли реализация кодека UTF-8 для Oberon/CP/AO?

Есть конвертер CpcUtf8Conv, там соотв-но процедуры кодирования/декодирования. Для CHAR, без контроля ошибок.

Уточните, пожалуйста, что Вы понимаете под кодеком.

Ну, собственно, кодер и декодер. Спасибо за подсказку про CPC.

Посмотрел CpcUtf8Conv. Действительно, обработки ошибок нет вообще, контроля диапазонов нет, выброса нелегальных символов нет, контроля чрезмерно длинных кодировок нет. Кроме того, поддерживается кодирование и декодирование только до 3-байтовых последовательностей UTF-8 (легальными являются и 4-байтовые последовательности, а ещё есть 5- и 6-байтовые, их тоже надо корректно обрабатывать). Чтение производится в один-единственный CHAR, т.е. сформировать surrogate pair UCS-2/UTF-16 не получится.

Есть такой замечательный стресс-тест для декодеров UTF-8, упоминается в UTF-8 and Unicode FAQ. Много интересного можно разглядеть.

Погодите, у нас же где-то народ XML делал, в том числе для Jabber. Там-то должен быть нормальный, безопасный (хотя бы декодер) UTF-8?

Скачал Xmlcore из CPC, увидел тот же самый код плюс дополнительная строчка:Спасибо за комментарий, поржал : ))
http://en.wikipedia.org/wiki/Byte_order_mark

В А2 есть UTF8Strings.Mod с процедурами кодирования/декодирования.

Во! Это уже гораздо лучше!
Только всё же безопасность хромает, даже процедура Valid не спасает. Например, передать ей любую строку, в которой первые два символа "C0X 80X", и она всю строку будет считать валидной. Разве же это правильно?

Идея с массивом CodeLength понравилась, но нужны доработки. Например, позиции 0FEH и 0FFH в этом массиве не инициализируются процедурой загрузки модуля. Если там окажется одно из возможных значений, будет ошибка, а если там будет 0X, то, например, процедура Length зависнет на этих символах - вопреки заявлению документации "violations of these assumptions may cause run-time exceptions, but not endless loops or memory corruption".

Другие всякие есть позиции, которые должны бы считаться ошибкой, но будут радостно пропущены процедурой Valid. Например, коды из диапазона суррогатных пар UTF-16, значения > 10FFFFH и некоторые другие.

Вердикт: из рассмотренных на сегодня это самая лучшая реализация, но подходит только для использования с well-formed UTF-8.

Вот бы всё про всё знать, чай, не до смеха было бы.

Не обижайтесь, я не над вами смеялся, а над комментарием.

По-моему, лишние символы фильтровать - задача не для декодера, а для сканера/парсера. Или для того, кто знает, где начало файла, а где середина.

Нашёл в системе O3: O3baseStrings.Utf8Decode и Utf8Encode. Тоже безо всякой обработки ошибок, тоже не более трёхбайтовых кодов.

Александр, ещё есть конвертеры: http://zinnamturm.eu/downloadsTZ.htm#UnicodeMappings
Посмотрите?

С удовольствием! Спасибо за ссылку.

Каков будет диагноз?

Ещё такой вопросец. Я хочу экспортировать ODC в текстовый ASCII документ с кодировкой UTF-8 и обратно, импортировать из него. Какую реализацию будет достаточно внедрить? Мне нужно написать процедуры типов Exporter и Importer для ЧЯ.

Неплохо бы иметь такую пару маленьких mapper'ов:
читает голые байты, а выдает (когда его читают) 1, 2-, .. 6-байтные коды.
Политерно и массивами.
И писатель аналогичный.

То есть в почти чистом виде правила кодировки UTF-8.

мы внедрили CpcUtf8Conv, ничего сами не писали, и пока живы

Тогда хорошо. Спасибо. А то Александр насторожил своими замечаниями по некоторым реализациям, что я аж засомневался что выбрать.

Поправка.
Как оказалось, CpcUtf8Conv вполне устраивает меня. Обошёлся малой кровью.

Если устойчивость к некорректным входным данным не нужна, то сгодится. Например, если будет декодировать только то, что сам закодировал.

Когда-то давно писал модуль для работы с различными предсталвениями Unicode под XDS-Oberon.
При написании опирался на стандарты.
Для полного счастья не хватает нормализации.

После этого еще делал utf8 -> utf16 и utf16 -> utf8 через конечный автомат, но на паскале. Если интересно могу поискать.