Hello!
> ICU — это стрельба по воробьям межконтинентальной баллистической ракетой.
> Библиотека, первоначально написанная для Java и потом портированная для C++
> и C. Большинство функций вряд ли понадобятся (некоторые довольно
> экзотические, как например запись чисел словами на разных языках).
Не знал таких подробностей. Немного поковыряв, удалось ICU скомпилить с
эскулайт под линукс и
виндоус, теперь в рассылке эскулайт периодически подсказываю, как это делается,
а сам мечтаю
избавиться от такого балласта. Эскулайтом я постепенно в своих проектах
постгрес заменяю, нужные
расширения написал (не много и нужно, в сущности - работа с ip-адресами, md5
суммы для текстовой
строки, для строки таблицы и целой таблицы, сжатие/распаковка данных, генерация
uuid и т.п.), пора
бы и "отбросить хвост" в виде libicu. Кстати, разработчик ГИС-модуля к sqlite
использует iconv для
перекодирования. А вот полнотекстовый поиск работает с юникодом через ICU.
> Что имеется ввиду под поддержкой уникода? Обычно требуется только:
> 1) Унифицированное представление текста на разных языках. Обычно UCS2, UCS4
> или UTF-8. Иногда используют wchar_t и/или мультибайтовые строки.
Попробую конкретизировать. Итак, юникод - UTF-8. Хотелось бы еще UTF16, хотя я
ни разу его не
использовал и не видел, чтобы кто-то использовал. Но движок sqlite имеет
нативную поддержку UTF16,
может пригодиться.
Требуется ввод/вывод - смотрел примеры перекодирования через iconv, вроде
устраивает.
Далее, нужно сравнение символов, сортировка строк, смена регистра.
Вот что требуется от функций смены регистра:
** upper('ABC') -> 'abc'
** lower('abc') -> 'ABC'
** lower('I', 'en_us') -> 'i'
** lower('I', 'tr_tr') -> 'ı' (small dotless i)
Сравнение с шаблоном, как я понимаю, через вышеперечисленное пишется, но
хотелось бы пример, чтобы
грамотно реализовать функции LIKE и REGEXP - они и так медленные, писать надо
аккуратно.
> 2) Ввод/вывод в разных кодировках. Достаточно iconv или recode. Тикль и
> питон тащат свои таблицы перекодировки. Львиную долю тут занимают всякие
> китайские и японские кодировки, если очень жмёт, то можно сэкономить.
На этом экономить точно не стоит, поскольку в стране восходящего солнца
вменяемых разработчиков
хватает и с ними можно будет и в апстрим протащить, т.к. они тоже знакомы с
проблемой кодировок не
по наслышке .
> 3) Определение класса символа (буква, цифра, пробел и т. п.),
> преобразование регистра. Для wchar_t есть стандартные локалезависимые
> функции в C99. Для уникода можно взять нетяжёлую libunicode.
Наверное, мне это и надо, если с этими функциями можно выполнить преобразования
вида
lower('I', 'en_us') -> 'i'
> 4) Чисто уникодные функции. Комбинированные символы, названия каждого
> символа и т. п. Тут уже нужна специальная библиотека. И немаленькая.
Названия символов в движке СУБД знать не требуется. А что такое
"комбинированные символы"?
P.S. Есть кроссплатформенный способ реализации - забиндить нужные функции из
тикля (питона, etc.).
Но, во-первых, для сравнения символов такой метод получается медленнее раза в 2
- 4, чем через
libicu. Во-вторых, иногда нужно вызвать sqlite просто из консоли и хотелось бы
иметь встроенные
функции.
Best regards, Alexey.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
