.NET 十进制格式因源而异

Posted 2023-04-14

【中文标题】.NET 十进制格式因源而异

【英文标题】：.NET Decimal formats differently depending on source

【发布时间】：2014-02-05 09:22:10

【问题描述】：

我有一个从未见过的案例。

在一种情况下，我们通过代码分配十进制值，例如值foo.DecimalField = 200M; 当我 ToString() 这个没有格式化程序或文化时，我得到了 "200" 的值

在另一种情况下，当从 EntityFramework 分配相同的字段时，调试器仍然说该字段的确切值是200M，但是当ToString()'ing 它时，它会产生"200.00"

如果这里是浮点问题，或者调试器中有隐藏的小数，我会明白的。

但既然我使用的是定点小数类型，那怎么可能呢？ 没有网络服务器或任何可能影响文化的东西。

我错过了什么？ 小数类型的行为是否会因它的初始化方式而有所不同（我假设有一些阅读器在内部从 EF 获取小数时会初始化小数）

【问题讨论】：

也许你可以做一个SSCCE

decimal 仍然是浮点类型，它只是十进制而不是二进制。

小数在对它们执行运算时会保留它们的精度，因此如果您通过不同精度的计算得到这两个数字，这是预期的行为。

另外，如果你想要一个一致的转换，为什么不提供你想要的格式ToString()？

我当然会提供一个格式，我只是很困惑为什么会发生这种情况，我的印象是小数类型总是使用相同的精度

【参考方案1】：

与Double、Decimal 不同保留零，例如

  Decimal d0 = 200M;
  Decimal d1 = 200.0M;
  Decimal d2 = 200.00M;

  // 200 
  String St0 = d0.ToString();
  // 200.0 (or 200,0 depending on CultureInfo.CurrentCulture)
  String St1 = d1.ToString();
  // 200.00
  String St2 = d2.ToString();

因此，在计算、数据库读取等过程中，一个值似乎是200M，而另一个值似乎是200.00M。

【讨论】：

这篇“文章”也提供了一些见解：csharpindepth.com/Articles/General/Decimal.aspx（简而言之，指数被存储，因此它“知道”小数位数）