Здравствуйте, Аноним, Вы писали:

А>Но это в теории. А как конкретно будет выглядеть код с использованием локалей, скажем, для такой простой задачи:
А>- имеем некий текст в std::string;
А>- имеем название кодировки, в которой этот текст. Например, "windows-1251", или "koi8-r", или "CP866", или даже "UTF-8". До компиляции программы кодировка неизвестна;
А>- на выходе хотим поиметь std::string с той же строкой в utf-8.

Если необходимо просто конвертить строки, то можно делать это так:
http://iculocale.svn.sourceforge.net/viewvc/iculocale/trunk/iculocale/make_string.h?revision=7&view=markup
примеры использования здесь:
http://iculocale.svn.sourceforge.net/viewvc/iculocale/trunk/test/make_string_test.cpp?revision=7&view=markup
основные кейсы:

std::string result = iculocale::make_string<std::string>(L"abcd");
std::string result = iculocale::make_string<std::string>(std::wstring(L"abcd"));
std::wstring result = iculocale::make_string<std::wstring>("abcd");
std::wstring result = iculocale::make_string<std::wstring>(std::string(L"abcd"));

В качестве второго — необязательного — параметра может использоваться локаль или фасетка (если его нет используется текущая):

typedef iculocale::codecvt_byname<wchar_t, char, std::mbstate_t> icu_facet_type;

std::locale locale(std::locale::classic(), new icu_facet_type(".utf8"));
std::wstring wresult = iculocale::make_string<std::wstring>("abcd", std::use_facet<icu_facet_type>(locale));

std::locale locale(std::locale::classic(), new icu_facet_type(".utf8"));
std::wstring wresult = iculocale::make_string<std::wstring>("abcd", locale);

Проблемы:
1. Фасетку, в зависимости от платформы, возможно, прийдется реализовать (читай: тянуть с собой ICU), системные зачастую есть простые заглушки.
2. Напрямую windows-1251 в utf-8 так не перефигачишь, прийдется перегонять через wchar_t.

А>Отсутствие внятных туториалов по std::locale несколько напрягает.

Одно из самых внятных описаний есть у Страуструпа то ли в отдельной главе посвященной им то ли в отдельном Приложении.

28.11.11 10:49, chemey написав(ла):
> Здравствуйте, gegMOPO4, Вы писали:
> MOP>В Apache Portable Runtime есть лёгкая реализация iconv на WinAPI. Используйте iconv на Linux и apr-iconv на Windows.
> Ну, не такая уж она и легкая — к ней еще APR собирать надо. И какие-то дополнительные параметры ввели к функциям — пулы, еще чего-то...
> Кстати, скачал исходники apr-iconv 1.2.1 — не нашел никаких вызовов WinAPI. Такое впечатление, что там код абсолютно одинаковый что для *NIX, что для винды.

Действительно, там что-то перемудрили. Похоже, я ошибся, на самом деле имел в виду http://svn.apache.org/repos/asf/stdcxx/trunk/util/iconv.cpp.

25.11.11 17:27, chemey написав(ла):
> Поискал тут в очередной раз что-нибудь достаточно кроссплатформенное для работы с кодировками — и вновь все те же лица: libiconv, ICU, Qt. Причем libiconv официально уже не собирается под виндой без MinGW/Cygwin, ICU монструозен и таскать его везде за собой не хочется. Qt хорош, но цеплять его к не-Qtшным проектам опять же не хочется.

ICU толст потому, что человеческие языки сложные и разнообразные. С задачами, которые он решает, легче и не справишься. Для работы с кодировками он не нужен.

> И я тут подумал — а ведь в большинстве ОСей поддержка перекодирования между всякими кодировками уже есть, встроенная. Под виндой — MultiByteToWideChar() и иже с ними (только кодировки надо задавать числовыми кодами, а не строками). Под линуксей — iconv уже давно в системе прописалась. Под макосями — не знаю, есть ли что-то свое, но iconv точно бывает.
> Неужели нет какой-нибудь оберточной библиотеки на С++, чтобы унифицированно можно было к ней обращаться, а она бы при этом юзала то, что доступно в системе? А в случае отсутствия в системе знакомых библиотек — ограничивалась бы внутренним конвертером (UTF8, UTF16, Latin1 — и хватит).

В Apache Portable Runtime есть лёгкая реализация iconv на WinAPI. Используйте iconv на Linux и apr-iconv на Windows.

Всем привет.

Поискал тут в очередной раз что-нибудь достаточно кроссплатформенное для работы с кодировками — и вновь все те же лица: libiconv, ICU, Qt. Причем libiconv официально уже не собирается под виндой без MinGW/Cygwin, ICU монструозен и таскать его везде за собой не хочется. Qt хорош, но цеплять его к не-Qtшным проектам опять же не хочется.

И я тут подумал — а ведь в большинстве ОСей поддержка перекодирования между всякими кодировками уже есть, встроенная. Под виндой — MultiByteToWideChar() и иже с ними (только кодировки надо задавать числовыми кодами, а не строками). Под линуксей — iconv уже давно в системе прописалась. Под макосями — не знаю, есть ли что-то свое, но iconv точно бывает.

Неужели нет какой-нибудь оберточной библиотеки на С++, чтобы унифицированно можно было к ней обращаться, а она бы при этом юзала то, что доступно в системе? А в случае отсутствия в системе знакомых библиотек — ограничивалась бы внутренним конвертером (UTF8, UTF16, Latin1 — и хватит).

Может, кто-то встречал такое (желательно опенсорц или фриварь)?

Boost.Locale

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

SF>Boost.Locale

Оно, к сожалению, хочет ICU для виндового билда:

If you are using custom ICU build or you are using Microsoft Windows you need to provide a path to location of ICU library

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

C>И я тут подумал — а ведь в большинстве ОСей поддержка перекодирования между всякими кодировками уже есть, встроенная. Под виндой — MultiByteToWideChar() и иже с ними (только кодировки надо задавать числовыми кодами, а не строками). Под линуксей — iconv уже давно в системе прописалась. Под макосями — не знаю, есть ли что-то свое, но iconv точно бывает.

C>Неужели нет какой-нибудь оберточной библиотеки на С++, чтобы унифицированно можно было к ней обращаться, а она бы при этом юзала то, что доступно в системе? А в случае отсутствия в системе знакомых библиотек — ограничивалась бы внутренним конвертером (UTF8, UTF16, Latin1 — и хватит).

Для того, чтобы перегонять текст из одной кодировки в другую, не нужны ICU/iconv.
А по поводу уменьшения степени "монструозности" ICU рекомендую заглянуть сюда (Customizing ICU's Data Library).

#include <locale> // не пойдет ??

Тыц

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

B>#include <locale> // не пойдет ??

B>Тыц

Звучит, конечно, заманчиво.

Но это в теории. А как конкретно будет выглядеть код с использованием локалей, скажем, для такой простой задачи:
— имеем некий текст в std::string;
— имеем название кодировки, в которой этот текст. Например, "windows-1251", или "koi8-r", или "CP866", или даже "UTF-8". До компиляции программы кодировка неизвестна;
— на выходе хотим поиметь std::string с той же строкой в utf-8.

Еще хотелось бы иметь вменяемую обработку ошибок (кривые данные во входной строке, неизвестная кодировка, и т.п.).

Насколько это будет сложно написать? Насколько такое решение будет работоспособно?
Отсутствие внятных туториалов по std::locale несколько напрягает.

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

MOP>В Apache Portable Runtime есть лёгкая реализация iconv на WinAPI. Используйте iconv на Linux и apr-iconv на Windows.
Ну, не такая уж она и легкая — к ней еще APR собирать надо. И какие-то дополнительные параметры ввели к функциям — пулы, еще чего-то...
Кстати, скачал исходники apr-iconv 1.2.1 — не нашел никаких вызовов WinAPI. Такое впечатление, что там код абсолютно одинаковый что для *NIX, что для винды.

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

MOP>Действительно, там что-то перемудрили. Похоже, я ошибся, на самом деле имел в виду http://svn.apache.org/repos/asf/stdcxx/trunk/util/iconv.cpp.

Очень неплохая реализация, кстати.
Жаль, что кодировки указаны по-уродски и нет алиасов ("CP866" == "IBM866" == "866") — ну да не критично, можно допилить.

Ээээх, вот если бы такую же, но чтоб на С++, и чтоб умела пользоваться нативным iconv на линуксе...

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

C>Здравствуйте, Semper Fidelis, Вы писали:

SF>>Boost.Locale

C>Оно, к сожалению, хочет ICU для виндового билда:

C>

C>If you are using custom ICU build or you are using Microsoft Windows you need to provide a path to location of ICU library

ICU library 3.6 or above is strongly recommended
If no ICU library is given, iconv support is required under POSIX platforms.