我们的中间层向我们发送序列化的对象,有时由于服务器上 Java 中的一些数学运算,发送一个 0,作为 0E+3。反序列化对象时,我们得到 XmlException --> System.OverflowException,因为该值对于小数来说太大或太小。
为什么 decimal.Parse 不能处理这种转换?
有没有办法保护我们的客户免受以这种方式传入的这些数字?
我们的中间层向我们发送序列化的对象,有时由于服务器上 Java 中的一些数学运算,发送一个 0,作为 0E+3。反序列化对象时,我们得到 XmlException --> System.OverflowException,因为该值对于小数来说太大或太小。
为什么 decimal.Parse 不能处理这种转换?
有没有办法保护我们的客户免受以这种方式传入的这些数字?
你可以试试:
decimal.Parse(numberText, System.Globalization.NumberStyles.Any)
编辑:
不幸的是,这不适用于 0E+3
作品:
Console.WriteLine(decimal.Parse("0", System.Globalization.NumberStyles.Any));
Console.WriteLine(decimal.Parse("123.45", System.Globalization.NumberStyles.Any));
Console.WriteLine(decimal.Parse("1.35E+6", System.Globalization.NumberStyles.Any));
Console.WriteLine(decimal.Parse("1.54E-5", System.Globalization.NumberStyles.Any));
不起作用:
Console.WriteLine(decimal.Parse("0E+3", System.Globalization.NumberStyles.Any));
问题编号总是0E+3吗?
如果是这样,您可以编写一个辅助方法来处理此问题:
decimal ParseDecimal(string number)
{
if (number.Equals("0E+3", StringComparison.OrdinalIgnoreCase))
{
return 0;
}
return decimal.Parse(number, System.Globalization.NumberStyles.Any);
}
如果它们以这种方式出现,Java 可能会将这种计算作为双精度进行(这意味着您也不需要小数的额外精度)......考虑使用双精度而不是十进制。
如果必须,只需E[+-]?([0-9]+)$
使用正则表达式手动修剪并自己进行乘法运算。或者作为特殊情况匹配^0E
(似乎NumberStyles.Any
无法处理)并返回0。
将其更改为浮点数或双精度数,它将正确解析。尽管要小心,但精度会低得多(浮点数为 7 位,双精度位为 15-16 位,十进制为 28-29 位)。