Проблема в следующем: очень хочется работать с libmysqlclient, используя utf8-строки для обработки результатов SQL-запроса.

В ответ на SQL-запрос libmysqlclient (предварительно специальным образом пнутый) возвращает utf8-строку в обычном const char* (т.е. один символ в таком массиве может быть представлен несколькими байтами). Такую строку можно вывести в cout, можно даже создать из нее std::string, но вот удобно с такой строкой работать уже нельзя (нельзя, например, вытащить произвольный символ обычным оператором [] и сравнить с символьным литералом).

Поэтому я написал простенький конвертер (потом правда узнал про мега-штуку iconv, но конвертер был уже написан) из utf8 в ucs2 составляющий std::wstring. Но терзают меня смутные сомнения, что есть способ удобно работать с utf8 строками не конвертируя их в ucs2.

Вопросы:

1. Решение с конвертацией utf8 в ucs2 с целью использовать wstring (а потом обратно) — оно вообще нормальное? Мне не нравится.
2. Есть ли возможность используя только стандартную библиотеку удобно работать с utf8-строками?
3. Есть ли utf8 строки в Boost? Очень хочется поработать с boost, но в онлайн документации ничего подходящего не нашел. А повод, чтобы начать был бы хороший.

Здравствуйте, Neavirc, Вы писали:

N>Поэтому я написал простенький конвертер (потом правда узнал про мега-штуку iconv, но конвертер был уже написан) из utf8 в ucs2 составляющий

Немного не по теме
Есть ещё хорошая библиотека ICU от IBM. Она позволяет сделать тоже, что и iconv. Конвертирует символы из одной кодировки в другую
Может быть вам это будет интересным!?

Здравствуйте, Neavirc, Вы писали:

N>Проблема в следующем: очень хочется работать с libmysqlclient, используя utf8-строки для обработки результатов SQL-запроса.

N>В ответ на SQL-запрос libmysqlclient (предварительно специальным образом пнутый) возвращает utf8-строку в обычном const char* (т.е. один символ в таком массиве может быть представлен несколькими байтами). Такую строку можно вывести в cout, можно даже создать из нее std::string, но вот удобно с такой строкой работать уже нельзя (нельзя, например, вытащить произвольный символ обычным оператором [] и сравнить с символьным литералом).

N>Поэтому я написал простенький конвертер (потом правда узнал про мега-штуку iconv, но конвертер был уже написан) из utf8 в ucs2 составляющий std::wstring. Но терзают меня смутные сомнения, что есть способ удобно работать с utf8 строками не конвертируя их в ucs2.

N>Вопросы:

N>1. Решение с конвертацией utf8 в ucs2 с целью использовать wstring (а потом обратно) — оно вообще нормальное? Мне не нравится.
N>2. Есть ли возможность используя только стандартную библиотеку удобно работать с utf8-строками?
N>3. Есть ли utf8 строки в Boost? Очень хочется поработать с boost, но в онлайн документации ничего подходящего не нашел. А повод, чтобы начать был бы хороший.


UTF8-CPP: UTF-8 with C++ in a Portable Way

Neavirc wrote:

> удобно с такой строкой работать уже нельзя (нельзя, например, вытащить
> произвольный символ обычным оператором [] и сравнить с символьным
> литералом).
А это в принципе нельзя. Точнее можно, но с линейной сложностью.
Этот цикл

for(int i=0; i<utf8String.size(); ++i)
{
  if(utf8String[i] == ....)...
}

скажем, на строке длиной 10000 символов будет совершать 100млн операций. Ты действительно этого хочешь?

Здравствуйте, ., Вы писали:

.>А это в принципе нельзя. Точнее можно, но с линейной сложностью.
Ну... Если очень хочется — то можно заранее построить индексы.

Cyberax wrote:

> .>А это в принципе нельзя. Точнее можно, но с линейной сложностью.
> Ну... Если очень хочется — то можно заранее построить индексы.
Уж проще в ucs перевести. И интуитивно кажется, что будет быстрее.

.>>А это в принципе нельзя. Точнее можно, но с линейной сложностью.
C>Ну... Если очень хочется — то можно заранее построить индексы.

Да forward iterator-а хватит за глаза. Такого, чтобы тип выражения *it был wchar_t или uint32, а ++it переходил бы на следующий символ.

Здравствуйте, ., Вы писали:
.>Уж проще в ucs перевести. И интуитивно кажется, что будет быстрее.

Тогда уж в utf-32 (или как его там правильно — UCS-4?). Иначе рано или поздно какие-нить символы потерять можно.