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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
