简短而亲切的版本：

在一台机器上了百绕试验机decimal.TryParse（）是将1.01至0.01

On one machine out of around a hundred test machines decimal.TryParse() is converting "1.01" to 0.01

好了，这是要听起来很疯狂，但忍耐一下......

Okay, this is going to sound crazy but bear with me...

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

We have a client applications that communicates with a webservice through JSON, and that service returns a decimal value as a string so we store it as a string in our model object:

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

当我们在屏幕上显示它被格式化的小数位数的特定数量的值。因此，我们在使用的过程是字符串 - >十进制小数，然后 - >字符串

When we display that value on screen it is formatted to a specific number of decimal places. So the process we use is string -> decimal then decimal -> string.

应用程序目前正在进行最后的测试和超过100台机器，在这一切工作正常运行。然而在的一个的，如果机十进制值拥有国内领先的1则是取而代之的是一个零。我加了简单的记录到code，所以它看起来是这样的：

The application is currently undergoing final testing and is running on more than 100 machines, where this all works fine. However on one machine if the decimal value has a leading '1' then it is replaced by a zero. I added simple logging to the code so it looks like this:

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;
}

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

On my machine - any every other client machine - the logfile output is:

  在原始字符串值：1.010000   在解析的十进制值：1.010000   在格式化字符串值：1.01    Original string value: 1.010000 Parsed decimal value: 1.010000 Formatted string value: 1.01

在有缺陷的计算机输出结果是：

On the defective machine the output is:

  在原始字符串值：1.010000   在解析的十进制值：0.010000   在格式化字符串值：0.01    Original string value: 1.010000 Parsed decimal value: 0.010000 Formatted string value: 0.01

所以，这样看来，decimal.TryParse方法是有过错的。

So it would appear that the decimal.TryParse method is at fault.

东西：

卸载并重新安装客户端应用程序 卸载并重新安装.NET 3.5 SP1 的数字（以英语（英国））对那些工作机的比较残次机的区域设置 - 无差异

有没有人见过这样的事，或有什么建议吗？我赶紧跑出去的想法......

Has anyone seen anything like this or has any suggestions? I'm quickly running out of ideas...

当我在写这篇一些更多的信息进来了：传递的10000的字符串值，以Convert.ToInt32（）返回0，这样也似乎放弃了领先1

While I was typing this some more info came in: Passing a string value of "10000" to Convert.ToInt32() returns 0, so that also seems to drop the leading 1.

根据意见进一步测试：

1.01 - > 0.01 在111.01 - > 11.01 在123.01 - > 23.01 在231.01 - > 231.01 在01.01 - > 1.01

所以看上去，它仅影响1和仅当它们是字符串的第一个字符。很奇怪，但至少它是一致的。

So it would appear that it only affects 1s and only if they are the first character of the string. Very odd, but at least it's consistent.

推荐答案

我能够重现你的结果。 试想一下：

I am able to reproduce your results. Consider:

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

然后：

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

的事情是：区域设置不显示你当前的正号，然后主要是：您解析号码时未设置区域性

The thing is: Regional Settings does not show you the current positive sign, and mainly: you did not set the culture when parsing the number.

该值可能来自不同的地方：它可能来自注册表，系统默认设置，或默认值可能已设置code：

The value may come from various locations: It may have come from the registry as the system defaults, or the defaults could have been set by code:

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