UTF-8中文字符（基本汉字）为三字节序列，首字节在0xE0–0xEF范围，第二、三字节均在0x80–0xBF范围，且需满足：首字节为0xE0时第二字节≥0xA0，为0xEF时第二字节≤0xBF。
UTF-8 中文字符的字节特征是什么
UTF-8 编码下，中文字符（基本汉字）落在 Unicode 的 U+4E00–U+9FFF 区间，对应 UTF-8 编码是 **三字节序列**，且首字节固定在 0xE0–0xEF 范围。注意：不是所有三字节序列都是中文——比如 0xE0 0x80 0x80 是合法 UTF-8，但解码为 U+0080（控制字符），不属于中文。所以不能只看字节数，得结合首字节范围和后续字节约束判断。
关键约束：
- 首字节 ∈
[0xE0, 0xEF] - 若首字节 ==
0xE0，则第二字节必须 ≥0xA0（否则是U+0000–U+09FF区间） - 若首字节 ==
0xEF，则第二字节必须 ≤0xBF（否则超出U+9FFF） - 第二、三字节都必须 ∈
[0x80, 0xBF]
如何安全地从 char* 中提取并判断一个 UTF-8 字符
不能直接对 char 数组单字节判断——中文占多个字节，必须先识别出完整字符边界。常见错误是把 str[0] 当作“一个字符”去比对，结果把中文拆成乱码字节误判。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::string::iterator或下标 + 手动跳过：检查s[i]，若s[i] & 0x80 == 0→ ASCII；若(s[i] & 0xE0) == 0xC0→ 两字节；若(s[i] & 0xF0) == 0xE0→ 三字节；若(s[i] & 0xF8) == 0xF0→ 四字节 - 拿到起始位置
i后，先验证后续字节是否符合 UTF-8 格式（避免非法序列误判），再组合解码 - 不推荐手写解码逻辑——容易漏掉代理对或扩展区，优先用
std::mbrtoc32或 ICU 库
用 std::mbrtoc32 判断是否为中文（推荐方案）
std::mbrtoc32 是 C++11 引入的标准方式，能正确处理多字节到 char32_t 的转换，并自动跳过非法序列。它依赖当前 locale 的编码设置，因此必须确保 locale 支持 UTF-8：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::setlocale(LC_ALL, "en_US.UTF-8"); // 或 "" 表示系统默认 UTF-8 locale
使用步骤：
- 传入指向
char的指针、缓冲区大小、以及一个mbstate_t状态对象（需初始化为 0） - 返回值
static_cast<:size_t>(-3)</:size_t>表示不完整字符；static_cast<:size_t>(-1)</:size_t>表示非法序列；否则返回消耗的字节数 - 解码成功后，检查
char32_t c32是否 ∈[0x4E00, 0x9FFF]（常用汉字）、[0x3400, 0x4DBF]（扩展 A）、[0x20000, 0x2A6DF}（扩展 B）等
注意：std::mbrtoc32 不是线程安全的（因内部可能用静态 state），多线程中应每个线程独立声明 mbstate_t st = {}。
常见误判场景和坑
直接用 unsigned char c = s[i]; if (c >= 0x80) 判定“非 ASCII” —— 这只能说明是多字节字符的某一部分，不能说明是中文。比如欧元符号 € 是三字节 0xE2 0x82 0xAC，首字节 0xE2 符合中文首字节范围，但显然不是中文。
其他易错点：
- 忽略字节序和平台差异：Windows 控制台默认是 GBK，
std::cin读入的可能是 GBK 编码，不是 UTF-8 - 用
std::wstring_convert+std::codecvt_utf8：C++17 已弃用，且在某些编译器（如 MSVC）上实现不全 - 正则匹配
[\u4e00-\u9fff]：这是 Unicode 码点，不是 UTF-8 字节，不能直接用于char*字符串 - 没做越界检查：访问
s[i+1]前未确认i+1
真正可靠的路径只有一条：先按 UTF-8 规则完整解析出码点，再按 Unicode 区间判断。中间任何跳过验证的捷径，都会在生僻字、标点、emoji 或损坏数据上翻车。
