Question

简短而甜蜜的版本：

在大约一百台测试机器中的一台机器上，decimal.TryParse（）将“1.01”转换为0.01

好的，这听起来很疯狂，但请耐心等待......

我们有一个客户端应用程序通过JSON与Web服务进行通信，并且该服务将十进制值作为字符串返回，因此我们将其作为字符串存储在模型对象中：

[DataMember(Name = "value")]
public string Value { get; set; }

当我们在屏幕上显示该值时，它被格式化为特定的小数位数。所以我们使用的过程是字符串 - ＆gt;小数再小数 - ＆gt;字符串。

该应用程序目前正在进行最终测试，并且运行在100多台机器上，这一切都运行良好。但是在一台机器上如果十进制值的前导'1'则将其替换为零。我在代码中添加了简单的日志记录，因此它看起来像这样：

Log("Original string value: {0}", value);
decimal val;
if (decimal.TryParse(value, out val))
{
    Log("Parsed decimal value: {0}", val);
    string output = val.ToString(format, CultureInfo.InvariantCulture.NumberFormat);
    Log("Formatted string value: {0}", output);
    return output;
}

在我的机器上 - 任何其他客户端机器 - 日志文件输出是：

原始字符串值：1.010000

解析十进制值：1.010000

格式化字符串值：1.01

在有缺陷的机器上输出为：

原始字符串值：1.010000

解析十进制值：0.010000

格式化字符串值：0.01

因此看起来decimal.TryParse方法有问题。

我们尝试过的事情：

卸载并重新安装客户端应用程序
卸载并重新安装.net 3.5 sp1
将有缺陷的机器的数字区域设置（使用英语（英国））与工作机器的区域设置进行比较 - 没有差异。

有没有人见过这样的或有任何建议？我很快就没有想法......

当我输入此内容时，会有更多信息传入：将字符串值“10000”传递给Convert.ToInt32（）会返回0，因此也似乎会丢弃前导1。

基于评论的进一步测试：

1.01 - ＆gt; 0.01
111.01 - ＆gt; 11.01
123.01 - ＆gt; 23.01
231.01 - ＆gt; 231.01
01.01 - ＆gt; 1.01

因此它似乎只会影响1，并且只有它们是字符串的第一个字符。很奇怪，但至少它是一致的。

Answer 1

我能够重现你的结果。考虑：

public NumberFormatInfo OneIsPositiveSignFormat()
{
    NumberFormatInfo custom = new NumberFormatInfo();
    custom.PositiveSign = "1";
    return custom;
}

然后：

if (decimal.TryParse(value, NumberStyles.Number, OneIsPositiveSignFormat(), out val))

事情是：区域设置不会显示当前的正号，主要是：解析数字时没有设置文化。

值可能来自不同的位置：它可能来自注册表，因为系统默认，或者默认值可能是由代码设置的：

CultureInfo customCulture = (CultureInfo)CultureInfo.InvariantCulture.Clone();
customCulture.NumberFormat = OneIsPositiveSignFormat();
Thread.CurrentThread.CurrentCulture = customCulture;

Answer 2

查看为此计算机设置区域设置的方式可能是“。”设置为千位分隔符而不是小数分隔符。尝试使用Decimal.TryParse（String，NumberStyles，IFormatProvider，out Decimal val）并传递使用小数分隔符创建的NumberFormatInfo“。”

decimal.TryParse（）删除前导“1”

2 个答案: