Кто как получает на C / C++ utf8 (utf16) string из пользовательских данных?

буду рад посмотреть на некостыльную:

std::u16string stringToUTF16LE(const char * const src, const char * const encoding);

Да что ты долбишь этим wchar? Тебе нужно получить UTF16LE из UTF8, в педивикии сказано, как это сделать.

какой? wchar_t -> utf8?

пойми: формат wchar_t не определён. Определено лишь то, что в него любой utf-8 символ помещается (в маздае своё видение слова «любой». Например «☣» это по маздайному «не любой»). А уж КАК оно туда влазит — хрен его знает. Ещё определено то, что ОДИН wchar_t == ОДИН символ. Т.е. длинна ☣ равна _одному_ wchar_t, зачем собственно эти wchar_t и нужны. Если это тебе не нужно, юзай utf-8, и не выноси мозг окружающим.

Я не понял: тебе нужно кроссплатформенное решение в аппаратном плане или кроссплатформенное в мастдаечном плане? Если второе, то винфак там →

Тебе нужно получить UTF16LE из UTF8

мне нужно UTF16-LE из «some encoding» (CP1251, ISO-8859-1, ASCII, KOI8-R, etc).

буду рад посмотреть на некостыльную

ну дык в педовике написан алгоритм, что тебе в нём непонятно-то? При чём тут вообще wchar_t???

Япона мать! Тебе же в самом начале говорили: чтобы "some encoding" преобразовать в UTF8, пользуйся libenca. Дальше делай что угодно с этим юникодом, а уж сохранять — сохраняй, как вздумается. В общем, ты тут раздул хрен знает что!

мне нужно UTF16-LE из «some encoding» (CP1251, ISO-8859-1, ASCII, KOI8-R, etc).

сначала в UTF-8 iconv(3), потом уже в UTF16-LE(алгоритм в вике). Я бы так сделал.

А wchar_t он просто для другого нужен.

Определено лишь то, что в него любой utf-8

The ISO/IEC 10646:2003 Unicode standard 4.0 says that:

«The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers.»

хз для чего он нужен.

The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers

тут говорится о том, что ЛЮБЫЕ компиляторы НЕ поддерживаются. Это не удивительно, ибо иные железяки в принципе не умеют юникод. Естественно там само понятие «юникод» лишено смысла, и wchar_t имеет ширину 8 бит.

А вот если данная железяка умеет юникод, то этот тип МОЖЕТ быть использован для хранения одного символа.

хз для чего он нужен.

объяснял же: для _посимвольной_ обработки. Ну типа «выделить первые 17 _символов_ из Over9000 строк». В utf-8 ты с этой задачей будешь долго колупаться, расковыривая каждую строку посимвольно. А вот в wchar_t это просто первые 17 элементов массива типа wchar_t.

Есть большой класс задач нечёткого поиска, в которых ты должен найти например максимально похожее к данному слово в каком-то большом тексте. Это достаточно дорого и так, а уж в utf-8 так вообще котастрофа. Wchar_t тут как нельзя кстати.

UTF-32 для такого.

facepalm.xpm

On Unix systems, UTF-32 strings are sometimes used for storage, due to the type wchar_t being defined as 32-bits.

http://en.wikipedia.org/wiki/UTF-32

как можно быть таким упоротым?

Блин, какой же ты упорныйотый!

нет способа получения из wchar_t того же utf-8. Могучая libc такого не умеет.

Мны, ну, всегда есть wctomb. Могучая libc. Фряшный ман утверждает, что это вообще ISO/IEC 9899:1999 (ISO C99). На винде тоже есть

Ну, а если хочется самому всё делать, то по интернетам путешествует ConvertUTF.c

В общем, не вижу, в чём ужас. В нашем продукте compatibility layer накрывает *nix'ы (X11/SDL), Android, Bada, Blackberry, винды от CE до 8'ки и Айфон. И ничо, не бог весть какой толщины прокладка, по крайней мере, в этом месте.

мір не кончается на Unix

Мны, ну, всегда есть wctomb. Могучая libc.

Код выше я давал. Могучая.

Ну, а если хочется самому всё делать, то по интернетам путешествует ConvertUTF.c

как только выхожу на UTF то проблемы кончаются. Проблема как раз в том, как выйті на UTF. Решается. Мутно. Еслі данные брать с cin, то скорее всего кроссплатформенно только на #ifdef

Разницу между \u016d и \x016d понимаешь?

Мне пофиг. У меня КОИ8.

ну вот рекомендую ознакоміться с матчастью.

понимаешь

ознакоміться

Я так понял, это — троллинг такой. Так? Давай-ка пиши по-человечески. Или вали на ЛОР.укр

1) я не украінец

2) когда под боком (в буфере) есть «и» - тогда вставляю. Когда нету - значіт нету.

Ну вот осиль сначала три раскладки на клавиатуре, а потом уже юникодом майся!

Мне і так нормально. По теме есть что?

Ну, повторюсь: на мой взгляд, там нет никаких сложностей, непереносимого кода в этом месте почти нет. собственно, имею перед глазами реализацию. Да, совет: отделите чтение/запись байтовых данных от собственно кодирования. Примером может быть java.io.*

аналог InputStreamReader/OutputStreamWriter как раз и хочется получить :)

В C++11 есть изкаробочная поддержка преобразования в/из UTF-8, правда в libstdc++ от gcc ее пока никак не запилят. Для преобразования UTF-8 -> UTF-16 и обратно использую свой велик, на половину основаный на чужом коде, а для работы с другими кодировками без сторонних библиотек обойтись уже будет сложно.

Насколько я понимаю, это работает только для перекодирований UTF->UTF & char * -> wchar_t *, а сделать char * -> UTF8 напрямую нельзя.

вот этот код в DeaDBeeF кстаті не thread-safe:

static int
curl_req_send (const char *req, const char *post) {
    trace ("sending request: %s\n", req);
    CURL *curl;
    curl = curl_easy_init ();

(deadbeef-0.5.6/plugins/lastfm/lastfm.c)

http://curl.haxx.se/libcurl/c/curl_easy_init.html

спасибо за инфу. пропустил этот момент.