Наш средний уровень отправляет нам сериализованные объекты, а иногда 0 из-за некоторых математических операций в java на сервере проходит как 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.
Измените его на float или double, и он будет правильно его анализировать. Хотя будьте осторожны, точность будет намного ниже (7 цифр для числа с плавающей запятой или 15-16 цифр для двойного против 28-29 для десятичного числа).
