[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Возможна ли поддержка тиклем юникода?



Hello!

В сообщении от Monday 19 January 2009 14:56:02 Serhiy Storchaka написал(а):
> Alexey Pechnikov wrote:
> > В libunicode-0.7v/include/unicode.h есть
> > typedef u_int16_t Uchar;
> >
> > Разве это не utf-16? Плюс предлагаются функции преобразования utf8 <->
> > utf16. Про utf32 в коде не вижу даже упоминания.
>
> Странно, в 0.4 использовались по крайней мере 32-битные символы для
> внутреннего представления, да и код рассчитан на >16 бит. Мы точно об одной
> и той же библиотеке говорим?

Наверное, о разных - вроде их две, одна из которых гномовская, а другая "сама по себе". Впрочем, 
хватает и towupper/towlower, эта либа пожалуй и не нужна.

> > Возможно, но использование libicu в 4 раза замедляет запросы, это просто
> > немыслимо. Ну и  размер либы нереально большой.
>
> Энтерпрайз. Ну вот такой он непростой, уникод.

Зато понятно, почему разработчики избегают этой либы. Но, к сожалению, некоторые используют, а в 
паре с эскулайт использование icu и вовсе выглядит чудовищно.

>
> > С iconv понятно, перекодировку внешних данных делаю именно через него, а
> > храню все уже в utf8. А как правильно работать с utf8, чтобы избежать
> > лишних перекодировок? Поскольку расширение нужно для embedded СУБД,
> > вопрос производительности приоритетный. Есть строки в utf8, какие функции
> > использовать для достижения максимальной производительности?
>
> А какие функции нужны?

Удаление акцента для символов utf8. Библиотека unaccent работает, но как-то странно - обязательно 
делает перекодировку даже для utf-16be (при вызове unac_string_utf16 почему-то заглавная буква Ё 
превращается в непонятный значок, а unac_string с указанием кодировки возвращает корректный 
результат), хотя по документации не должна, и я никак не могу понять, можно ли ее использовать для 
работы с utf8 представлением.

strncasecmp с utf8 почему-то не работает.

wcsncasecmp для utf16 не проверял, может быть и работает...

Best regards, Alexey.


Reply to: