为何std::tolower无法转换Ç为ç？探究POSIX tolower设计原因

问题背景 #

在Linux/glibc环境下，测试std::tolower(int)和std::tolower(char, std::locale)对所有char值的处理时，发现当前locale环境中'Ç'并未被转换为'ç'。当前Bash的locale设置如下：

$ locale
LANG=en_HK.UTF-8
LANGUAGE=en_HK:en
LC_CTYPE="en_HK.UTF-8"
LC_NUMERIC="en_HK.UTF-8"
LC_TIME="en_HK.UTF-8"
LC_COLLATE="en_HK.UTF-8"
LC_MONETARY="en_HK.UTF-8"
LC_MESSAGES="en_HK.UTF-8"
LC_PAPER="en_HK.UTF-8"
LC_NAME="en_HK.UTF-8"
LC_ADDRESS="en_HK.UTF-8"
LC_TELEPHONE="en_HK.UTF-8"
LC_MEASUREMENT="en_HK.UTF-8"
LC_IDENTIFICATION="en_HK.UTF-8"
LC_ALL=

1. 为什么'Ç'未被转换为'ç'？ #

核心原因在于字符编码和函数的处理范围限制：

• 首先，默认编译选项下glibc的char是有符号类型，'Ç'作为UTF-8字符，单字节值为0xC3（十进制195），超过有符号char的最大值127，会被解释为负数。
• 对于std::tolower(int)：它要求输入必须是EOF或可转换为unsigned char的值，传入负数（非EOF）属于未定义行为，自然无法正确转换。
• 对于std::tolower(char, std::locale)：虽然函数签名接收char，但负数输入会被很多locale的转换逻辑忽略；另外Ç是双字节UTF-8字符，单字节版本的tolower无法识别多字节编码，需要使用宽字符版本std::towlower，或先将UTF-8字符串转换为宽字符序列再处理。

2. POSIX为何规定C locale下的tolower仅支持A-Z和a-z转换？ #

主要基于以下设计考量：

• 历史兼容性：C语言的tolower诞生于ASCII时代，当时字符集仅包含128个字符，A-Z是明确的大写字母范围。C locale作为默认的通用基础locale，必须保持与早期C标准的兼容，确保跨环境的行为一致性。
• 确定性与简洁性：C locale的目标是提供无歧义的最小环境，避免不同地区字符集差异导致的行为波动。仅支持A-Z/a-z的转换逻辑简单、可预测，没有复杂的多语言映射规则。
• 性能优化：早期系统资源有限，仅处理ASCII范围的转换逻辑执行效率更高，适合作为默认行为。
• 分层设计：POSIX将多语言字符处理交给locale机制，用户可切换到特定locale（如en_US.UTF-8）获得完整转换支持，C locale则保留最基础、通用的行为。

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