Re: Возможна ли поддержка тиклем юникода?
Hello!
> Можно, но либо придётся вручную перекодировать данные перед и после вызова
> unac_string_utf16, либо, что лучше, вместо unac_string_utf16 использовать
> unac_char_utf16.
Ради таких перспектив явно не имеет смысла отказываться от привычной utf8. Собственно, если хранить
данные в utf-16, то тиклевские функции для сортировки должны работать быстрее (правда, буква "ё"
вылетает из алфавита).
>
> >> Всё не так просто. См. http://www.unicode.org/reports/tr10/
> >
> > Полную реализацию самому не сделать, а готовых инструментов приемлемого
> > качества не видно. Интересует именно "приемлемая" реализация, но зато
> > быстрая. В сложных случаях можно на уровне приложения назначать функции
> > сортировки/преобразования, но это медленно.
>
> См. Unicode::Collate.
Оно на перле реализовано :-) Вариант на тикле в несколько раз медленнее libicu, который примерно
вчетверо медленнее бинарного сравнения, а в этом перловом модуле много всего понаписано, так что
будет еще намного медленнее, чем на тикле. Можно то же самое делать на тикле, но вот буква "ё" не
сортируется правильно :-) и нет удаления акцентов.
Резюме - продолжаю пользоваться таблицами символов utf8 для преобразования регистра и удаления
акцентов, скорость этого решения позволяет заменять стандартную collate NOCASE. Все остальные пути
приводят к замедлению движка SQLite существенно более, чем на 50%, что я полагаю неприемлемым для
production. Начинаю понимать, почему для первых 127 символов в эскулайте определены матрицы
преобразований...
Best regards, Alexey.
Reply to: