为什么float.Parse（“ 123,45”）不会引发异常

Question

...但是返回12345？

Single.Parse的文档说：

  

例外

     

...

     

FormatException

     

s不代表数字值。

     

...

据我所知，“ 123,45”不代表正确的数值（在使用逗号作为千位分隔符的国家/地区）。

系统的CultureInfo具有：

CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator == "."
CultureInfo.CurrentCulture.NumberFormat.NumberGroupSeparator == ","
CultureInfo.CurrentCulture.NumberFormat.NumberGroupSizes == [3]

显然，逗号被简单地忽略了，这会导致更令人讨厌的结果：看起来完全错误的“ 123,45.67”或“ 1,23,45.67”变成了12345.67。

补充问题

我不知道文档中的这句话应该是什么意思，以及这是否与本案有关：

  

如果在解析操作期间在s参数中遇到分隔符，并且适用的货币或数字十进制分隔符和组分隔符相同，则分析操作将假定分隔符是十进制分隔符而不是组分隔符。

Answer 1

在默认和美国文化中，逗号（,）作为组之间的分隔符是合法的。想像这样的大数字：

987,654,321

对于一个小组来说，在错误的地方并不重要；解析器不是那么聪明。它只是忽略分隔符。

对于补充问题，某些区域性使用逗号作为小数点分隔符，而不是组分隔符。文档的这一部分阐明了如果以某种方式将组分隔符和十进制分隔符设置为相同字符会发生什么情况。

Answer 2

正如乔尔所说，“解析器不是那么聪明”。源代码可用，因此这里就是证明。

Single.Parse的代码最终调用Number.ParseNumber。

有趣的是，给Number.ParseNumber 提供了一个NumberFormatInfo对象，该对象确实具有一个NumberGroupSizes属性，该属性定义了“每个组中的位数小数点左边”。

但是，您会注意到在851行中，它检查组分隔符，而不必费心引用NumberGroupSizes属性来检查组分隔符是否在预期的范围内位置。实际上，Number.ParseNumber 从不使用NumberGroupSizes属性。

NumberFormatInfo.NumberGroupSizes仅在将数字转换为字符串时使用。