std::wstring是wchar_t的vector,非万能宽字符串;其编码平台相关:Windows为UTF-16,Linux/macOS为UTF-32;length()返回wchar_t个数,非码点数或字节数;跨平台应优先用UTF-8(std::string),仅系统边界转换。

std::wstring 本质是 wchar_t 的 vector,不是“万能宽字符串”
std::wstring 就是 std::basic_string 的别名,底层存储的是 wchar_t 序列,但 wchar_t 的大小和编码含义**平台相关**:Windows 下通常是 UTF-16(2 字节),Linux/macOS 下通常是 UTF-32(4 字节)。这意味着同一段 std::wstring 在不同系统上可能表示不同编码,不能直接跨平台序列化或网络传输。
常见错误现象:
std::wstring s = L"你好"; std::wcout << s.length(); // Windows 输出 2,Linux 可能也输出 2,但内部字节数不同这里
length() 返回的是 wchar_t 个数,不是 Unicode 码点数(如 emoji ZWJ 序列会占多个 wchar_t),更不是字节数。
- 不要假设
std::wstring::size() * sizeof(wchar_t)等于 UTF-8 字节数 - 不要用
std::wstring直接对接 UTF-8 文件或 HTTP 响应体 - Windows API(如
CreateFileW、MessageBoxW)接受LPCWSTR(即const wchar_t*),这时std::wstring.c_str()是安全的;但 Linux 的 POSIX wide API(如fwprintf)虽存在,实际极少使用
Windows 下 std::wstring ↔ UTF-8 转换必须用 WideCharToMultiByte / MultiByteToWideChar
Windows SDK 提供的这两个 API 是最可靠、性能最好、且支持 BOM 和错误处理的转换方式。C++ 标准库(包括 C++11 的 )在 MSVC 中已被弃用,在 GCC/Clang 中行为不一致,不要用 std::wstring_convert 或 std::codecvt_utf8。
正确做法示例(UTF-8 → std::wstring):
std::string utf8_str = "Hello 世界";
int wlen = ::MultiByteToWideChar(CP_UTF8, 0, utf8_str.c_str(), -1, nullptr, 0);
if (wlen == 0) throw std::runtime_error("MultiByteToWideChar failed");
std::wstring wstr(wlen - 1, L'\0'); // -1 排除 null terminator
::MultiByteToWideChar(CP_UTF8, 0, utf8_str.c_str(), -1, &wstr[0], wlen);
-
CP_UTF8是关键常量,不是CP_ACP或CP_OEMCP - 第二次调用传
&wstr[0](C++11 起保证连续存储),不要用wstr.data()(可能不可写) - 若源字符串不含 null 终止符,把
-1换成static_cast,并手动补(utf8_str.size()) L'\0'
Linux/macOS 下推荐用 iconv 或 std::mbstowcs / std::wcstombs(但需设对 locale)
POSIX 系统没有原生 UTF-16 支持,wchar_t 默认为 UTF-32,因此 std::mbstowcs 实际做的是 UTF-8 → UTF-32 转换——前提是当前 C locale 支持 UTF-8。常见坑:程序启动时未显式设置 locale,导致转换失败或截断。
安全写法(必须在转换前调用):
std::setlocale(LC_ALL, "en_US.UTF-8"); // 或 "" 表示继承环境 // 然后才能用: size_t wlen = std::mbstowcs(nullptr, utf8_str.c_str(), 0); if (wlen == static_cast(-1)) { /* 错误 */ } std::wstring wstr(wlen, L'\0'); std::mbstowcs(&wstr[0], utf8_str.c_str(), wlen + 1);
-
std::mbstowcs不识别 BOM,输入必须是纯 UTF-8 - locale 名称因系统而异:
en_US.UTF-8(Ubuntu)、en_US.utf8(Alpine)、UTF-8(macOS) - 更健壮的选择是用
libiconv:明确指定"UTF-8"→"WCHAR_T",不依赖 locale
跨平台项目建议:内部统一用 UTF-8(std::string),只在系统边界转 wchar_t
真正需要 std::wstring 的场景极少:仅限调用 Windows GUI/API、或极少数要求 wchar_t 接口的第三方库。其余所有逻辑(文件读写、JSON 解析、网络收发、日志)都应使用 std::string 存储 UTF-8。
立即学习“C++免费学习笔记(深入)”;
- Windows 上打开文件:用
CreateFileW传wstr.c_str(),但文件内容仍按 UTF-8 读取/写入 - 避免把
std::wstring当作“更高级的字符串”滥用——它不提供 Unicode 正规化、大小写折叠、图形簇计数等能力 - 需要处理 emoji、ZWNJ、变音符号组合时,
std::wstring的length()完全不可靠,必须用 ICU 或 utf8cpp 等库按 Unicode 标准解析
最易被忽略的一点:wchar_t 不是 Unicode 类型,它只是“宽字符”。把它当 Unicode 用,等于把 int 当数学整数用——底层能存,但语义和操作必须额外保障。











