Re: Возможна ли поддержка тиклем юникода?
Hello!
> В этче есть.
Есть, но версия 0.4 и это притом, что версия 0.7 датируется, если не ошибаюсь, 2000-м годом (на
sf.net).
> >> > Еще вопрос по последней - в ней используется
> >> > utf-16, хотя хотелось бы работать со стандартным для линукса utf-8,
> >>
> >> Есть и UTF-8, и UTF-16, и UTF-32, разных эндингов, и конвертация в
> >> другие кодировки (неплохая компактная переносимая альтернатива iconv
> >> получается, как я погляжу).
> >
> > Все операции выполняются с utf-16. Это что же, конвертить в utf16 и
> > обратно при каждом преобразовании? Стандарт в линуксе это utf-8.
>
> Нет, функции работают преимущественно с UTF-32 или UTF-8. Откуда UTF-16?
В libunicode-0.7v/include/unicode.h есть
typedef u_int16_t Uchar;
Разве это не utf-16? Плюс предлагаются функции преобразования utf8 <-> utf16. Про utf32 в коде не
вижу даже упоминания.
> >> В этой библиотеке нет функции сравнения строк. Для правильного сравнения
> >> похоже и нужны мегабайты libicu.
Возможно, но использование libicu в 4 раза замедляет запросы, это просто немыслимо. Ну и размер
либы нереально большой.
> Если не смущает зависимость от локали и переносимость за пределы линукса,
> то всё это делается стандартными функциями C99 для работы с широкими и
> многобайтовыми символами (man -k multibyte wide-character 'wide character')
> и iconv. В линуксе, кстати, представление wchar_t будет совпадать с UTF-32.
С iconv понятно, перекодировку внешних данных делаю именно через него, а храню все уже в utf8. А как
правильно работать с utf8, чтобы избежать лишних перекодировок? Поскольку расширение нужно для
embedded СУБД, вопрос производительности приоритетный. Есть строки в utf8, какие функции
использовать для достижения максимальной производительности?
Кроссплатформенное решение без внешних зависимостей я уже отладил, без поддержки локали (приведение
к одному регистру - удаление умляутов - сравнение по коду).
Из описания:
wchar_t
Integer type whose range of values can represent distinct wide-character codes for all members of
the largest character set specified among the locales supported by the compilation environment: the
null character has the code value 0
wchar_t - это два байта, то есть UTF-16, откуда возьмется utf-32?
Best regards, Alexey.
Reply to: