为何设置en_US.UTF-8 locale后MB_CUR_MAX值为6而非4？

MB_CUR_MAX的取值并非严格绑定UTF-8的理论规范，而是由系统的C标准库实现和当前locale的配置决定，具体原因如下：

• 系统实现的兼容考量：Linux上常用的GNU C库（glibc）在en_US.UTF-8 locale下，将MB_CUR_MAX设为6，这是为了兼容一些历史场景或边缘情况——比如处理某些非标准的UTF-8变体序列，或是支持特定的宽字符转换逻辑，即便这些情况并不符合标准UTF-8的4字节上限。
• 定义的本质差异：标准UTF-8确实最多用4字节表示一个Unicode字符，但MB_CUR_MAX的定义是当前locale下多字节字符的最大可能占用字节数，它的作用是给程序提供一个安全的缓冲区大小参考，确保能容纳当前系统locale支持的所有多字节字符，而非严格对应编码规范的理论最大值。
• locale的扩展支持：部分Linux发行版的en_US.UTF-8 locale可能包含了对其他兼容字符集的扩展支持，这些字符集的单字符字节数可能超过4，从而拉高了MB_CUR_MAX的取值。

实际开发中，建议直接使用MB_CUR_MAX的值来分配多字节字符缓冲区，这是适配当前系统环境的最安全方式；如果需要严格遵循UTF-8的4字节限制，可以在代码中额外添加校验逻辑，但这可能会忽略系统特定的兼容场景。

内容的提问来源于stack exchange，提问作者Irbis