Поддерживает ли std::wstring UTF-16 и UTF-32 в Windows?

Question

Я изучаю Unicode и у меня есть несколько вопросов, на которые я надеюсь ответить.

1) Я читал, что в Linux std:: wstring составляет 4 байта, а в Windows - 2 байта. Означает ли это, что внутренняя поддержка Linux - UTF-32, а Windows - UTF-16?

2) Схоже ли использование std:: wstring с интерфейсом std:: string?

3) Предлагает ли VC++ поддержку использования 4-байтового std::wstring?

4) Вам нужно изменить параметры компилятора, если вы используете std::wstring?

В качестве идентификатора я наткнулся на библиотеку строк для работы с UTF-8, которая имеет интерфейс, очень похожий на std:: string, который предоставляет знакомые функции, такие как длина, substr, find, преобразование в верхний / нижний регистр и т. Д. Библиотека Glib:: ustring.

Пожалуйста, не стесняйтесь добавлять любые комментарии или дополнительные советы, потому что мне это действительно нужно.

Спасибо!

Answer 1

1) wstring это basic_string<wchar_t> и размер wchar_t зависит от реализации и не зависит от кодировки (стандарт просто говорит, что "его значения могут представлять отдельные коды для всех членов самого большого расширенного набора символов, указанного среди поддерживаемых локалей". Но да, реализация, которая имеет sizeof(wchar_t)=4 байт поддерживает UTF-32, и sizeof(wchar_t)=2 байт поддерживает UTF-16.

2) wstring это basic_string<wchar_t> в то время как string это basic_string<char>так что да, это очень похожий интерфейс. Вам придется использовать wcout, wcin а также wfstream хотя и есть некоторые другие ограничения, как это.

3) Нет, MSVC определяет wchar_t как unsigned short, который определяет и ограничивает wstring как вы сказали. MSVC предоставляет возможность обработки wchar_t как typedef вместо внутреннего типа. Тогда вы могли бы представить, что переопределите typedef, но я подозреваю, что это чрезвычайно рискованно и зло.

4) Нет, вам решать, какой тип строки вы хотите.

5) UTF-32 и стандарт. Интересно, что в самом независимом от C++ стандарте C++ кодировка UTF-32 явно упоминается только для codecvt: "специализация codecvt <char32_t, char, mbstate_t>преобразует между формами кодирования UTF-32 и UTF-8. codecvt конвертирует между собственными наборами символов для узких и широких символов. "Это говорит о том, что char32_t будет портативный подход к UTF-32. К сожалению, MSVC пока не поддерживает этот тип.

Answer 2

1) Я читал, что в Linux std:: wstring составляет 4 байта, а в Windows - 2 байта. Означает ли это, что внутренняя поддержка Linux - UTF-32, а Windows - UTF-16?

Это на самом деле wchar_tне std::wstringв Linux это 4 байта, в Windows - 2 байта. std::wstring является typedef для std::basic_string<wchar_t>, так std::wstring поддерживает UTF-32 в Linux и UTF-16 в Windows, да.

2) Схоже ли использование std:: wstring с интерфейсом std:: string?

И то и другое std::wstring а также std::string являются typedefs из std:basic_stringпоэтому у них одинаковый интерфейс, просто разные value_type типы (wchar_t против charсоответственно).

3) Предлагает ли VC++ поддержку использования 4-байтового std::wstring?

Не для std::wstring само по себе нет. Но вы можете создать свой собственный std::basic_string typedef, например:

typedef std::basic_string<int32_t> u32string;

На самом деле, это именно то, как новый C++11 std::u16string а также std::u32string типы определены:

typedef std::basic_string<char16_t> u16string;
typedef std::basic_string<char32_t> u32string;

Также не случайно сделать typedef из std::basic_string за TCHAR:

typedef std::basic_string<TCHAR> tstring;

В качестве идентификатора я наткнулся на библиотеку строк для работы с UTF-8, которая имеет интерфейс, очень похожий на std:: string, который предоставляет знакомые функции, такие как длина, substr, find, преобразование в верхний / нижний регистр и т. Д. Библиотека Glib:: ustring.

Технически говоря, вы можете (и многие люди делают) использовать стандарт std::string для UTF-8. Glib::ustring просто идет дальше, используя gunichar (typedef для guint32) вместо charи предоставляет свои интерфейсы для работы в терминах необработанных кодовых точек Unicode вместо кодированных блоков кода.