语言环境对 strtol 有什么影响？答案

【问题标题】：What effect does locale have on strtol?语言环境对 strtol 有什么影响？
【发布时间】：2018-01-21 06:55:50
【问题描述】：

"The GNU C Library: Parsing of Integers" 说，关于strtol：

在标准“C”语言环境以外的语言环境中，此函数可以识别其他依赖于实现的语法。

当前安装的 C 语言环境可以接受其他数字格式。

我隐约知道 GNU 扩展 scanf("%'d", &intvalue) 用于“选择”使用千位分隔符解析整数；但我的印象是，上面的引文指的是别的东西，特别是关于strtol（不是sscanf）的东西，以及除了将语言环境设置为"C"之外不能“选择退出”的东西。

哪些“其他数字格式”是可能的，在什么语言环境中？显然，理论上的可能性是无穷无尽的，所以我特意寻找一个存在于当前现实世界系统中的语言环境，和/或在网上有信誉的地方记录。

【问题讨论】：

我没有完整的答案，但至少十进制分隔字符在芬兰是逗号而不是点/句点；在芬兰语中，“w”和“v”在排序时也具有相同的排名。
@AkiSuihkonen：谢谢；小数点分隔符确实是一个相当知名的语言环境问题，当小数点分隔符为, 与. 时，我已经确认strtod("3,14", NULL) 具有different behavior。但是这个问题比较棘手，因为它是关于strtol，它是针对整数的，所以不关心小数分隔符。
了解的唯一方法是阅读您正在使用的实现的函数的文档。如果没有信息，则可能没有任何变化（您只会得到标准行为）。如果有信息，则适用于该版本，但不一定适用于任何其他版本。
好吧，千位分隔符不是……可能是其他数字系统，但我还找不到：D
在其他语言和框架上，locale 显然可以支持其他数字系统，例如拉丁语 (IV == 4) 或印度语。

标签： c locale string-parsing strtol

【解决方案1】：

glibc had a bug 与 infamous Turkish locale 相关联，即 fixed just recently。字母 i 在 strtol 中的处理不正确，因为土耳其语言环境下的大写版本是 İ（U+0130 拉丁大写字母 I，上面带有点）。尽管这种行为并非有意为之，但它仍会影响数百万个现实世界的系统。

也就是说，我很确定没有主要的 C 库实现故意允许其他数字格式。原因很简单，它会导致严重的互操作性问题。

【讨论】：

非常有趣！这是一个很好的例子；尽管 glibc 显然认为这是一个错误。它仅影响base >= 19（其中i 表示值为“18”的数字）。我没有想到 10 以外的基地。我绝对可以看到一个实现选择用 base=64、base=96 等做一些聪明的事情；也许这属于我引用的狡猾措辞。所以你认为黄鼠狼措辞适用于奇怪的基地，而不是 基地 10 的奇怪行为？