指数 0 值的十进制解析 (0+E3)
我们的中间层向我们发送序列化对象,有时由于服务器上 java 中的一些数学运算,会发送一个 0,结果为 0E+3。当反序列化对象时,我们得到一个 XmlException --> System.OverflowException,因为该值对于小数来说太大或太小。
为什么decimal.Parse不能处理这种转换?
有没有办法保护我们的客户免受这些以这种方式传入的数字的影响?
Our middle tier sends us serialized objects and sometimes a 0, due to some math operations in java on the server, come through as 0E+3. When deserializing the object we get an XmlException --> System.OverflowException because the value is too large or small for a decimal.
Why can't decimal.Parse handle this conversion?
Is there a way to protect our client from these numbers coming in this way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以尝试:
编辑:
不幸的是,这不适用于 0E+3
有效:
不起作用:
问题编号总是 0E+3 吗?
如果是这样,您可以编写一个辅助方法来处理此问题:
You could try:
EDIT:
This doesn't work for 0E+3 unfortunately
Works:
Doesn't work:
Is the problem number always 0E+3?
If so, you could write a helper method to handle this:
Java 可能会以双精度数进行此计算(这意味着您也不需要小数点的额外精度),如果它们以这种方式出现...请考虑使用双精度数而不是十进制数。
如果必须的话,只需使用正则表达式手动删除
E[+-]?([0-9]+)$
并自己进行乘法即可。或者将^0E
作为特殊情况进行匹配(似乎NumberStyles.Any
无法处理)并只返回 0。Java is probably doing this calculation as a double (which means you also don't need the extra precision of a Decimal) if they come out this way... consider using double instead of decimal.
If you have to, just trim out the
E[+-]?([0-9]+)$
manually with a regex and do the multiplication yourself. Or match^0E
as a special case (it seemsNumberStyles.Any
can't handle it) and just return 0.将其更改为浮点数或双精度数,它将正确解析它。尽管要小心,但精度会低得多(浮点型为 7 位,双精度型为 15-16 位,而十进制为 28-29 位)。
Change it to a float or double and it will parse it correctly. Although be careful, the precision will be much lower (7 digits for float or 15-16 digits for double vs 28-29 for decimal).