char8_t/char16_t/char32_t是C++20引入的独立字符类型，非typedef；宽度分别为≥8/16/32位，与unsigned char等不兼容；仅表存储单元，无编码语义；u8""、u""、U""字面量分别对应其类型。
char8_t / char16_t / char32_t 是什么，不是什么
char8_t、char16_t、char32_t 是 C++20 引入的**独立字符类型**，不是 typedef 或别名。它们各自有确定的宽度：char8_t 至少 8 位（通常就是 8 位），char16_t 至少 16 位（常见为 16），char32_t 至少 32 位（常见为 32）。它们和 unsigned char、uint16_t、uint32_t **不兼容**——不能隐式转换，也不能混用在模板或重载中。
关键点：它们只表示“存储单元”，不自带编码语义。比如 char16_t 字符串可以是 UTF-16，也可以是 GBK 的高位字节（虽然没人这么干）；C++ 标准不管内容，只管类型安全。
- 写
u8"hello"→ 类型是const char8_t[6]，内容是 UTF-8 编码字节 - 写
u"café"→ 类型是const char16_t[5]，内容是 UTF-16 编码（é可能占 1 或 2 个char16_t） - 写
U"??"→ 类型是const char32_t[2]？错，是[1]—— 因为char32_t足够存一个 Unicode 码点，U"??"是单个标量值（U+1F4BB + U+200D + U+1F4BC），但组合后仍是单个码点？不，实际是 Emoji ZWJ 序列，共 3 个码点 →U"??"长度为 3，不是 1
std::string_view 和 std::basic_string 怎么选
别直接用 std::string 存 Unicode 文本——它底层是 char，和 UTF-8 兼容但语义模糊；也别盲目用 std::u16string，它只是 std::basic_string，不提供任何 UTF-16 解码逻辑。
推荐组合：
立即学习“C++免费学习笔记（深入）”；
- UTF-8 文本（文件、网络、API）→
std::string或std::string_view（char类型，但内容为 UTF-8 字节） - 需要逐码点处理（如大小写转换、分词）→ 先用 ICU、utf8cpp 或手写解码器转成
std::vector，再操作 - Windows API 交互 →
std::wstring（wchar_t，非标准 Unicode，Win32 下是 UTF-16）；C++20 后可考虑std::u16string+std::from_chars配合平台转换函数 -
std::u8string是 C++20 新增，等价于std::basic_string；但注意：它不等于“UTF-8 安全字符串”，仍需手动验证有效性
常见错误：把 char16_t 当“Unicode 字符”来遍历
UTF-16 是变长编码：U+0000–U+FFFF 占 1 个 char16_t，而 U+10000–U+10FFFF（如 ? U+1F30D）需用代理对（surrogate pair）：高位代理（0xD800–0xDBFF）+ 低位代理（0xDC00–0xDFFF），共 2 个 char16_t 表示 1 个码点。
所以以下代码是错的：
for (size_t i = 0; i < s.size(); ++i) {
char16_t c = s[i]; // 可能只拿到代理对的一半
process_code_point(c); // 错！c 不一定是完整码点
}正确做法是用 UTF-16 解码循环：
for (size_t i = 0; i < s.size(); ) {
char32_t cp;
if (i + 1 < s.size() &&
s[i] >= 0xD800 && s[i] <= 0xDBFF &&
s[i+1] >= 0xDC00 && s[i+1] <= 0xDFFF) {
cp = 0x10000 + ((s[i] - 0xD800) << 10) + (s[i+1] - 0xDC00);
i += 2;
} else {
cp = s[i];
i += 1;
}
process_code_point(cp);
}跨平台 I/O 和 locale 几乎没用
C++ 标准库的 std::wcout、std::codecvt（已弃用）、std::locale 在 Unicode 处理上基本不可靠：Windows 上 wcout 默认窄输出，Linux/macOS 对宽字符支持参差不齐，std::codecvt_utf8_utf16 在 C++20 被移除。
务实方案：
- 输入：读文件用二进制模式（
std::ios::binary），按 BOM 判断 UTF-8/UTF-16/UTF-32，再用轻量库（如 utf8cpp）解码 - 输出：统一转为 UTF-8
std::string，写入文件或 stdout（现代终端基本都支持 UTF-8） - 避免
std::wifstream直接读 UTF-16 文件——它依赖 locale，行为不确定 - Windows 控制台需调用
SetConsoleOutputCP(CP_UTF8)并确保终端字体支持，否则std::cout 仍可能乱码
真正难的不是类型声明，而是边界：BOM 怎么跳、代理对怎么拆、组合字符（如 é + ◌́）怎么归一、零宽连接符怎么处理——这些 C++ 标准库一个都不管。
