关于c16rtomb()/c32rtomb()区域设置相关性及MSVC实现的技术问询

背景回顾 #

C11引入了c16rtomb()/c32rtomb()及其逆转换函数mbrtoc16()/mbrtoc32()，根据C标准，这类函数的多字节编码规则由当前活跃的C区域设置决定，属于区域设置相关的转换逻辑。但MSVC将其实现为区域设置无关，归类到「独立于区域设置的多字节例程」；而C++20新增的c8rtomb()/mbrtoc8()若脱离区域设置，其设计意义会大打折扣。

问题1：是否有其他编译器遵循标准实现区域设置相关的Unicode多字节转换例程？ #

是的，GCC和Clang在Linux、macOS等主流平台上的实现严格遵循标准，会根据当前C区域设置选择对应多字节编码：

• 当区域设置为zh_CN.UTF-8这类UTF-8编码区域时，mbrtoc16()/mbrtoc32()会将UTF-8多字节序列转换为UTF-16/UTF-32宽字符；c16rtomb()/c32rtomb()执行反向转换。
• 若切换到GBK、Shift-JIS等非UTF-8区域设置，这些函数会自动适配对应区域的多字节编码，完成与UTF-16/UTF-32的转换。

比如在Linux环境下，通过setlocale(LC_ALL, "zh_CN.GBK")切换区域后，调用mbrtoc16()可将GBK编码的多字节字符串转换为UTF-16的char16_t序列，完全符合标准中区域设置相关的要求。

问题2：MSVC的该实现是否属于bug？ #

严格来说，MSVC的实现不符合C++标准要求，但微软将其作为有意的行为差异而非bug维护：

• 微软文档明确说明，他们的c16rtomb()/c32rtomb()系列函数固定使用UTF-8作为多字节编码，不依赖区域设置——这是为了简化Windows平台的Unicode处理逻辑，因为Windows原生更偏向UTF-16（wchar_t对应UTF-16），微软希望提供一套稳定、不随区域设置变化的UTF-8与UTF-16/UTF-32转换接口。
• 虽然不符合标准文本，但微软并未将其标记为bug，而是在文档中明确告知开发者这一行为差异。对于依赖区域设置的多字节转换场景，MSVC推荐开发者使用MultiByteToWideChar/WideCharToMultiByte等Windows特定API实现。

从标准合规性角度，这种实现确实偏离了C++标准要求，跨平台开发时需要特别注意该差异。

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