Re: Возможна ли поддержка тиклем юникода?
Alexey Pechnikov wrote:
> После ваших подсказок
> появилась мысль, что для utf8 можно сделать локале-независимую, а для
> utf16 - локале-зависимую реализации и выбирать формат хранения данных в
> зависимости от потребностей. Может быть, вы можете дать оценку такому
> варианту?
Почему бы не сделать две реализации и не сравнить простоту и эффективность?
Sqlite3, как я вижу, предоставляет одинаковый интерфейс независимо от
внутреннего представления, прозрачно перекодируя на лету. Выбор зависит от
того, какое представление чаще используется.
Главные потери будут не на саму перекодировку, а на динамическое выделение
буфферов при каждом преобразовании (unac_string делает это, в отличие от
unac_string_utf16).
Мне представляется более удобным зарегистрировать collation для
SQLITE_UTF16BE, использовать towlower (вручную посимвольно преобразовывая в
UTF-32) и unac_string_utf16 (или посимвольно unac_char_utf16). А внутреннее
представление базы выбрать по результатам тестов готового продукта.
> Я не тестировал скорость обработки utf8/utf16, но по таблицам
> символов должно быть все равно, какое представление выбрано, если таблицы
> составлены в нем же, а системные функции быстрее должны работать с utf16,
> но размер данных увеличится...
Для русского текста размер практически одинаков — два символа на букву.
> Уверен, поскольку могу указать явно, в каком формате мне нужны данные -
> sqlite3_value_text16, sqlite3_value_text16be, sqlite3_value_text16le,
> sqlite3_value_text (последняя функция вернет utf-8). Вызов unac_string
> работает корректно, а unac_string_utf16 "ломает" данные.
Для unac_string_utf16 данные должны быть получены sqlite3_value_text16be, а
не sqlite3_value_text16.
> Да, так оно и сделано по умолчанию, но мне нужно сортировать по алфавиту
> (игнорируя акценты у "ё" и "й"), делать регистронезависимый поиск и
> приведение регистра. Впрочем, без учета системной локали это делается "в
> лоб" с помощью таблиц символов.
Всё не так просто. См. http://www.unicode.org/reports/tr10/
Reply to: