c# - 为什么这个小数点在 ToString() 上显示小数点后 8 位？

Question

我有一个 decimal 类型的变量，其值为 1.0。我将它保存到 SQL Server 2012 表的一个列中，该表的类型是 decimal(10, 8)。

检索值后，我看到它是 1，但是当我调用 ToString() 时，返回的值是 "1.00000000"(见下文)。

我意识到小数点后8位对应数据库中的数据类型。但是， Entity Framework 生成的属性中没有赋予它这种行为的属性或任何东西，所以我不知道这是怎么发生的。

以下是我在立即窗口中进行的一些测试:

myDecimal
1
myDecimal.ToString()
"1.00000000"
myDecimal == 1
true
myDecimal == 1.0m
true

正如您从最后 2 次测试中看到的那样，这也不是浮点错误的情况(不是我期望的，因为十进制是定点数，但我不得不尝试，因为我用完了想法)。

知道小数的 ToString() 是如何产生一个有 8 位小数的字符串的吗？

编辑:为了比较，请看下面的测试。

1m.ToString()
"1"

Answer 1

原因是小数类型没有规范化。同一个数字有多种表示形式，这些表示形式将表示为不同的字符串。

这不是您的数据库类型的特殊属性，这是 decimal 的正常工作方式。没有特殊的 DataAnotation 或任何附加到变量的东西。

(1m).ToString() == "1"
(1.00000000m).ToString() == "1.00000000"
((1m)==(1.00000000m)) == true

对于给定的 double，只有一种有效表示，即 mantissa * 2^exponent

的一种组合

对于十进制，mantissa * 10^exponent 有多个有效表示。每个代表相同的数字，但通过多种可能的表示形式提供的附加信息用于在将十进制转换为字符串时选择尾随数字的默认数量。确切的细节并没有很好的记录，而且我没有找到任何关于在添加或乘以小数时指数究竟发生了什么的信息。但它对 ToString() 的影响很容易验证。

缺点是 Equals() 和 GetHashCode() 操作比规范化数字格式更复杂，并且在实现中存在细微错误:C# Why can equal decimals produce unequal hash values?

This article by Jon Skeet goes into a bit more detail :

A decimal is stored in 128 bits, even though only 102 are strictly necessary. It is convenient to consider the decimal as three 32-bit integers representing the mantissa, and then one integer representing the sign and exponent. The top bit of the last integer is the sign bit (in the normal way, with the bit being set (1) for negative numbers) and bits 16-23 (the low bits of the high 16-bit word) contain the exponent. The other bits must all be clear (0). This representation is the one given by decimal.GetBits(decimal) which returns an array of 4 ints. [...]

The decimal type doesn't normalize itself - it remembers how many decimal digits it has (by maintaining the exponent where possible) and on formatting, zero may be counted as a significant decimal digit.

您可以通过比较 decimal.GetBits() 返回的值来验证您拥有的两个小数是否不相同，即:

decimal.GetBits(1m) == {int[4]}
    [0]: 1
    [1]: 0
    [2]: 0
    [3]: 0

decimal.GetBits(1.00000000m) == {int[4]}
    [0]: 100000000
    [1]: 0
    [2]: 0
    [3]: 524288

依赖这种行为来格式化小数可能很诱人，但我建议在转换为字符串时始终明确选择精度，以避免混淆和不可预见的意外，例如，如果数字事先乘以某个因子。