icu的normalizer2实例必须通过getinstance()获取，仅支持全大写无空格的模式名如"nfc"；normalize()需用unicodestring并预清空，转utf-8须调用toutf8string()；windows静态链接需定义u_static_implementation宏。
ICU的Normalizer2怎么选实例？
C++里做Unicode规范化，核心就是Normalizer2类，但它不直接构造，得从Normalizer2::getInstance()拿。你不能随便传个字符串进去——传"NFC"可以，但"nfc"或"NFC "（带空格）会返回nullptr，后续调用normalize()直接崩溃。
- 实例名必须全大写、无空格：只认
"NFC"、"NFD"、"NFKC"、"NFKD"
- 第二个参数是
UNormalizationMode2枚举，但一般不用手动传，走字符串接口更稳
- 首次调用会加载数据，耗时略高；建议在初始化阶段缓存好实例，别每次临时取
const icu::Normalizer2* nfc = icu::Normalizer2::getInstance(nullptr, "NFC", UNORM2_COMPOSE, status);
if (U_FAILURE(status)) {
// 处理错误，比如status == U_MISSING_RESOURCE_ERROR 表示icudt*.dat没找到
}
normalize()输出字符串为什么乱码或截断？
常见现象：输入"café"（带重音符），输出变成"cafe"或空字符串，甚至触发U_BUFFER_OVERFLOW_ERROR。根本原因是ICU默认用UnicodeString，它内部是UTF-16，而你可能直接拿.data()当UTF-8用，或没预留足够容量。
-
UnicodeString不是C风格零终止字符串，.length()返回UTF-16码元数，不是字节数
- 转UTF-8要用
toUTF8String()或toUTF8()，别用.getBuffer()硬转
- 目标
UnicodeString必须预先setLength(0)清空，否则旧内容残留
icu::UnicodeString src = u"café";
icu::UnicodeString dst;
dst.remove(); // 等价于 setLength(0)
nfc->normalize(src, dst, status);
if (U_SUCCESS(status)) {
std::string utf8;
dst.toUTF8String(utf8); // 正确转UTF-8
}
链接ICU库时U_STATIC_IMPLEMENTATION要不要定义？
Windows下用静态链接ICU（如icuuc.lib）却忘了定义宏，会导致Normalizer2::getInstance返回nullptr，且无明确报错。Linux/macOS动态链接通常没事，但Windows静态库必须显式声明。
- 仅在编译你自己的代码时定义：
-DU_STATIC_IMPLEMENTATION（GCC/Clang）或项目属性里加预处理器定义
- 定义位置必须在
#include <unicode></unicode>之前，否则无效
- 如果用CMake，记得在
target_compile_definitions()里加，别只加在add_definitions()全局作用域
为什么NFKC把全角数字转成半角后，长度变短了？
这是NFKC的预期行为，不是bug。它会做兼容性分解+合成，比如全角０（U+FF10）→ 半角0（U+0030），全角空格 （U+3000）→ ASCII空格 （U+0020）。但要注意：某些字体渲染下，半角字符宽度变窄，UI布局可能错位；更隐蔽的是，NFKC还会折叠连字（如ffi → ffi）、替换上标数字（⁴ → 4），这些变换不可逆。
- 如果只要标准化不改语义，优先用
NFC；需要搜索/比较宽松匹配才用NFKC
- 对用户输入做
NFKC前，务必记录原始字符串——比如密码校验、日志审计等场景，原始形态不能丢
- ICU 73+新增
UNORM2_DECOMPOSE模式，适合只想展开不合成的场景，但得自己处理后续合成逻辑
"NFC"、"NFD"、"NFKC"、"NFKD"
UNormalizationMode2枚举，但一般不用手动传，走字符串接口更稳normalize()输出字符串为什么乱码或截断？
常见现象：输入"café"（带重音符），输出变成"cafe"或空字符串，甚至触发U_BUFFER_OVERFLOW_ERROR。根本原因是ICU默认用UnicodeString，它内部是UTF-16，而你可能直接拿.data()当UTF-8用，或没预留足够容量。
-
UnicodeString不是C风格零终止字符串，.length()返回UTF-16码元数，不是字节数 - 转UTF-8要用
toUTF8String()或toUTF8()，别用.getBuffer()硬转 - 目标
UnicodeString必须预先setLength(0)清空，否则旧内容残留
icu::UnicodeString src = u"café";
icu::UnicodeString dst;
dst.remove(); // 等价于 setLength(0)
nfc->normalize(src, dst, status);
if (U_SUCCESS(status)) {
std::string utf8;
dst.toUTF8String(utf8); // 正确转UTF-8
}
链接ICU库时U_STATIC_IMPLEMENTATION要不要定义？
Windows下用静态链接ICU（如icuuc.lib）却忘了定义宏，会导致Normalizer2::getInstance返回nullptr，且无明确报错。Linux/macOS动态链接通常没事，但Windows静态库必须显式声明。
- 仅在编译你自己的代码时定义：
-DU_STATIC_IMPLEMENTATION（GCC/Clang）或项目属性里加预处理器定义
- 定义位置必须在
#include <unicode></unicode>之前，否则无效
- 如果用CMake，记得在
target_compile_definitions()里加，别只加在add_definitions()全局作用域
为什么NFKC把全角数字转成半角后，长度变短了？
这是NFKC的预期行为，不是bug。它会做兼容性分解+合成，比如全角０（U+FF10）→ 半角0（U+0030），全角空格 （U+3000）→ ASCII空格 （U+0020）。但要注意：某些字体渲染下，半角字符宽度变窄，UI布局可能错位；更隐蔽的是，NFKC还会折叠连字（如ffi → ffi）、替换上标数字（⁴ → 4），这些变换不可逆。
- 如果只要标准化不改语义，优先用
NFC；需要搜索/比较宽松匹配才用NFKC
- 对用户输入做
NFKC前，务必记录原始字符串——比如密码校验、日志审计等场景，原始形态不能丢
- ICU 73+新增
UNORM2_DECOMPOSE模式，适合只想展开不合成的场景，但得自己处理后续合成逻辑
-DU_STATIC_IMPLEMENTATION（GCC/Clang）或项目属性里加预处理器定义#include <unicode></unicode>之前，否则无效target_compile_definitions()里加，别只加在add_definitions()全局作用域NFKC把全角数字转成半角后，长度变短了？
这是NFKC的预期行为，不是bug。它会做兼容性分解+合成，比如全角０（U+FF10）→ 半角0（U+0030），全角空格 （U+3000）→ ASCII空格 （U+0020）。但要注意：某些字体渲染下，半角字符宽度变窄，UI布局可能错位；更隐蔽的是，NFKC还会折叠连字（如ffi → ffi）、替换上标数字（⁴ → 4），这些变换不可逆。
- 如果只要标准化不改语义，优先用
NFC；需要搜索/比较宽松匹配才用NFKC - 对用户输入做
NFKC前，务必记录原始字符串——比如密码校验、日志审计等场景，原始形态不能丢 - ICU 73+新增
UNORM2_DECOMPOSE模式，适合只想展开不合成的场景，但得自己处理后续合成逻辑
Unicode规范化不是“一锤子买卖”，NFC/NFD/NFKC语义差异大，选错模式比不规范更危险。尤其在拼接、比较、存储前，得想清楚：你要保真，还是要归一。
