【问题标题】:.NET Decimal formats differently depending on source.NET 十进制格式因源而异
【发布时间】:2014-02-05 09:22:10
【问题描述】:

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

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

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

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

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

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

【问题讨论】:

  • 也许你可以做一个SSCCE
  • decimal 仍然是浮点类型,它只是十进制而不是二进制。
  • 小数在对它们执行运算时会保留它们的精度,因此如果您通过不同精度的计算得到这两个数字,这是预期的行为。
  • 另外,如果你想要一个一致的转换,为什么不提供你想要的格式ToString()
  • 我当然会提供一个格式,我只是很困惑为什么会发生这种情况,我的印象是小数类型总是使用相同的精度

标签: c# number-formatting fixed-point


【解决方案1】:

DoubleDecimal 不同保留零,例如

  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

【讨论】:

猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多