Чем можно проверить функцию UTF8->UTF32?

http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt

А есть где то в публичном доступе пруф того как icu эти тесты проходит?

https://gist.github.com/ilammy/24c937533a5bf4e8353f — сойдёт за пруф?

ilammy@serendipity:/tmp/utf8/24c937533a5bf4e8353f$ aptitude show libicu48 | grep Version
Version: 4.8.1.1-12+deb7u1

iconv + md5sum

И где я возьму ошибочные комбинации? Плюс 5-ти и 6-ти символьные комбинации как оно их обрабатывает? По стандарту должно отбрасывать, по факту многие их считывают не отбрасывая. Попробую как напишу по документу чтобы в первом комментарии.

UTF8 - это способ кодирования чисел от 0 до 4294967296 последовательностью байт от 1 до 6ти. Как правило он используется для кодирования символов из Unicode таблицы (где каждому символу из множества алфавитов предоставлен числовой код). Если вы хотите делать проверку на UNICODE валидность то вам нужно закодировать/найти базу доступных UNICODE кодов - но большого смысле это не имеет поскольку данная таблица постоянно меняется от версии к версии (то какойто новый символ древнеегипецкий добавят, то чтото из китайского забытого 4000 лет назад). Есть стандартные наборы символов (латиницы, кирилица, вязь, китайский упрощенный, хариганы и тд ...) + упровляющие коды (LR/LF) и большинство библиотек вроверяют на вхождения именно в эти диопазоны - но это далеко от стандарта (который по сути нафиг никому не нужен).

Я это все к чему - не заморачиваетесь, работайте просто с цыфрами - так будет проще, и ошибок будет меньше. Если есть необходимость могу выслать базу основных последовательностей (версия 5.1.0d5 объемом в 18819 штук), плюс есть файл для перевода верхнего регистра в нижний (907 символов) + есть С функции для работы с UTF8/Unicode - правда все за 2007 год - зато в свое время откатано в продакшене на терабайтах текста ...

чисел от 0 до 4294967296

Начнем с того, что от 0 до 1114109.

Если вы хотите делать проверку на UNICODE валидность то вам нужно закодировать/найти базу доступных UNICODE кодов - но большого смысле это не имеет поскольку данная таблица постоянно меняется от версии к версии (то какойто новый символ древнеегипецкий добавят, то чтото из китайского забытого 4000 лет назад). Есть стандартные наборы символов (латиницы, кирилица, вязь, китайский упрощенный, хариганы и тд ...) + упровляющие коды (LR/LF) и большинство библиотек вроверяют на вхождения именно в эти диопазоны - но это далеко от стандарта (который по сути нафиг никому не нужен).

На самом деле нужна только проверка на совпадение длины закодированного символа в байтах, корректность сдвинутых по << 6 и просуммированных байт на принадлежность четырем диапазонам для 1,2,3 и 4 кодировочных байт соответственно, плюс общее НЕ соответствие 4м условиям: d800-dfff, fdd0-fdef, xfffe-xffff, >10ffff. Все остальные символы считаются валидными, даже если стандарт прямо не прописал их существование. Например 􏿫􏾣􏾐􏽬 (не знаю, как у вас отобразится, вставил символы из области пользователя).

вам нужно закодировать/найти базу доступных UNICODE кодов

А чего её искать-то? Вот она: ftp://ftp.unicode.org/Public/7.0.0/

А кроме того, само перекодирование UTF-8 → UTF-32 не требует базы символов.

Ну вот вам и прекрасный тест кейс, пишите тест поторый проверит все недопостимые значения, потом пишите тест который сгенерирует файл всех допустимых значений - вы его сконвертируете своим кодом и iconvom - результат сравните с помощю md5sum. Немного заморочно - зато надежно ...

Имеллось ввиду валидация последовательностей а не кодирование.

Имеллось ввиду валидация последовательностей а не кодирование.

И для валидации процедуры кодирования эта таблица тоже не нужна. UTF-8 может кодировать любую последовательность символов Unicode, кроме суррогатов, а они находятся в диапазоне от U+D800 до U+DFFF, что можно проверить без всякой таблицы. Что же, по-твоему, ещё нужно знать о репертуаре Юникода для валидации UTF-8?

общее НЕ соответствие 4м условиям: d800-dfff

ОК.

fdd0-fdef, xfffe-xffff

Non-characters допустимы внутри приложения. Ими следует пользоваться исключительно для внутренних технических нужд, но в принципе, может потребоваться закодировать их в UTF-8. Или стандарт этого не рекомендует?

FTGJ, не только U+FFFE и U+FFFF являются non-characters, но и все остальные последние пары плоскостей: U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF... Их можно кодировать и передавать в составе строк, но только пока они остаются в рамках одной системы (которая назначает им смысл). Стандарт рекомендует заменять на U+FFFD non-characters, встреченные во «внешних» строках (которые приходят извне системы и не должны содержать non-characters). Но их присутствие не является ошибкой и не делает текст некорректным.

Собсно, я бы взял вон тот файл в качестве кунсткамеры некорректных последовательностей, чтобы проверить вменяемость их обработки. Корректные последовательности вполне можно проверить полностью, их всего чуть больше миллиона. То, что декодер будет в начальном состоянии после считывания корректного символа, проверять не надо (иначе декодер следует тут же отправить в /dev/null). По идее, этого будет достаточно.

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