Преобразование между строкой, u16string и u32string

mbstowcs() и wcstombs() не обязательно конвертировать в UTF-16 или UTF-32, они преобразуют в wchar_t и независимо от локали wchar_t кодировка. Все локали Windows используют два байта wchar_t и UTF-16 в качестве кодировки, но другие основные платформы используют 4-байтовый wchar_t С UTF-32 (или даже кодировкой без Юникода для некоторых локалей). Платформа, которая поддерживает только однобайтовые кодировки, может иметь даже один байт wchar_t и кодировка отличается по локали. Так что wchar_t мне кажется, что плохой выбор для переносимости и Unicode. *

некоторые лучшие варианты были введены в C++11; новые специализации std:: codecvt, новые классы codecvt и новый шаблон, чтобы сделать их использование для конверсий очень удобным.

сначала новый класс шаблона для использования codecvt-std:: wstring_convert. После создания экземпляра класса std::wstring_convert можно легко конвертировать между строками:

std::wstring_convert<...> convert; // ... filled in with a codecvt to do UTF-8 <-> UTF-16
std::string utf8_string = u8"This string has UTF-8 content";
std::u16string utf16_string = convert.from_bytes(utf8_string);
std::string another_utf8_string = convert.to_bytes(utf16_string);

для того, чтобы сделать различных преобразование вам просто нужны разные параметры шаблона, одним из которых является фасет codecvt. Вот некоторые новые грани, которые просты в использовании с wstring_convert:

std::codecvt_utf8_utf16<char16_t> // converts between UTF-8 <-> UTF-16
std::codecvt_utf8<char32_t> // converts between UTF-8 <-> UTF-32
std::codecvt_utf8<char16_t> // converts between UTF-8 <-> UCS-2 (warning, not UTF-16! Don't bother using this one)

примеры использования этих:

std::wstring_convert<std::codecvt_utf8_utf16<char16_t>,char16_t> convert;
std::string a = convert.to_bytes(u"This string has UTF-16 content");
std::u16string b = convert.from_bytes(u8"blah blah blah");

новые специализации std::codecvt немного сложнее использовать, потому что они имеют защищенный деструктор. Чтобы обойти это, вы можете определить подкласс, который имеет деструктор, или вы можете использовать функцию шаблона std:: use_facet для получения существующего codecvt пример. Кроме того, проблема с этими специализациями заключается в том, что вы не можете использовать их в Visual Studio 2010, поскольку специализация шаблонов не работает с типами typedef'D и что компилятор определяет char16_t и char32_t как typedefs. Вот пример определения собственного подкласса codecvt:

template <class internT, class externT, class stateT>
struct codecvt : std::codecvt<internT,externT,stateT>
{ ~codecvt(){} };

std::wstring_convert<codecvt<char16_t,char,std::mbstate_t>,char16_t> convert16;
std::wstring_convert<codecvt<char32_t,char,std::mbstate_t>,char32_t> convert32;

специализация char16_t преобразует между UTF-16 и UTF-8. Специализация char32_t, UTF-32 и UTF-8.

обратите внимание, что эти новые преобразования, предоставляемые C++11, не включите любой способ преобразования непосредственно между UTF-32 и UTF-16. Вместо этого вам просто нужно объединить два экземпляра std::wstring_convert.

***** * я подумал, что добавлю примечание о wchar_t и его цели, чтобы подчеркнуть, почему он обычно не должен использоваться для Unicode или портативного интернационализированного кода. Ниже приводится краткая версия моего ответа https://stackoverflow.com/a/11107667/365496

что такое wchar_t?

wchar_t-это определено так, что кодировка char любой локали может быть преобразована в wchar_t, где каждый wchar_t представляет ровно одну кодовую точку:

тип wchar_t-это отдельный тип, значения которого могут представлять различные коды для всех членов наибольшего расширенного набора символов, указанного среди поддерживаемых локалей (22.3.1). -- [basic.основополагающим] 3.9.1/5

этой не требовать, чтобы wchar_t был достаточно большим, чтобы представлять любые персонаж из всех районов одновременно. То есть кодировка, используемая для wchar_t, может отличаться между локалями. Это означает, что вы не можете обязательно преобразовать строку в wchar_t, используя одну локаль, а затем преобразовать обратно в char, используя другую локаль.

поскольку это, похоже, основное использование на практике для wchar_t, вы можете задаться вопросом, что это хорошо, если не это.

первоначальным намерением и целью wchar_t было сделать обработку текста простой, определив ее так что это требует сопоставления один к одному из кодовых единиц строки с символами текста, что позволяет использовать те же простые алгоритмы, используемые со строками ascii для работы с другими языками.

к сожалению, требования к wchar_t предполагают сопоставление один к одному между символами и кодовыми точками для достижения этого. Unicode нарушает это предположение, поэтому вы также не можете безопасно использовать wchar_t для простых текстовых алгоритмов.

это означает, что портативное программное обеспечение не может использовать wchar_t либо как общее представление текста между локалями, либо для обеспечения возможности использования простых текстовых алгоритмов.

какая польза wchar_t сегодня?

не так много, для портативного кода в любом случае. Если __STDC_ISO_10646__ определяется, тогда значения wchar_t непосредственно представляют кодовые точки Unicode с одинаковыми значениями во всех локалях. Это позволяет безопасно выполнять преобразования между языками, упомянутые ранее. Однако вы не можете полагаться только на него, чтобы решить, что вы можете использовать wchar_t таким образом, потому что, хотя большинство платформ unix определяют его, Windows не использует ту же локаль wchar_t во всех локалях.

причина, по которой Windows не определяет __STDC_ISO_10646__ я думаю, это потому, что Windows использует UTF-16 в качестве кодировки wchar_t и потому, что UTF-16 использует суррогатные пары для представления кодовых точек больше, чем U+FFFF, что означает, что UTF-16 не удовлетворяет требованиям для __STDC_ISO_10646__.

для конкретного кода платформы wchar_t может быть более полезным. Это по сути требуется в Windows (например, некоторые файлы просто не могут быть открыты без использования имен файлов wchar_t), хотя Windows является единственной платформой, где это верно, насколько я знаю (поэтому, возможно, мы можем думать о wchar_t как "Windows_char_t").

в ретроспективе wchar_t явно не полезен для упрощения обработки текста или в качестве хранилища для независимого от локали текста. Портативный код не должен пытаться использовать его для этих целей.