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. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
