我有以下代码。。。
int Val=-32768;
String Hex=Integer.toHexString(Val);
这等于 ffff8000
```
int FirstAttempt=Integer.parseInt(Hex,16); // Error "Invalid Int"
int SecondAttempt=Integer.decode("0x"+Hex); // Error "Invalid Int"
因此,最初,它将值-32768转换为十六进制字符串ffff8000,但随后无法将十六进制字符串转换回整数。
在 `.Net` 就像我预期的那样,而且 `returns -32768` .
我知道我可以自己编写一个小方法来转换它,但我只是想知道我是否遗漏了什么,或者这是否真的是一个bug?
10条答案
按热度按时间vbkedwbf1#
当您试图转换有符号字节(如必须使用的utf-16解码字符)时,as integer.tohexstring(byte/integer)不起作用:
或
你可以用倒过来
crcmnpdw2#
int
到十六进制:十六进制到
int
:您也可以使用
long
而不是int
(如果值不符合int
界限):十六进制到
long
:Long.toHexString(longValue)
bttbmeg03#
使用
Integer.toHexString(...)
这是一个很好的答案。但我个人更喜欢用String.format(...)
.试一下这个样品作为测试。
busg9geu4#
java的parseint方法实际上是一堆吃“false”hex的代码:如果要翻译-32768,应该将绝对值转换为hex,然后在字符串前面加上“-”。
integer.java文件有一个示例:
描述非常明确:
sf6xfgos5#
值得一提的是,Java8具有
Integer.parseUnsignedInt
以及Long.parseUnsignedLong
这就是你想要的,特别是:Integer.parseUnsignedInt("ffff8000",16) == -32768
这个名称有点混乱,因为它从十六进制字符串中解析有符号整数,但它确实起作用。egmofgnx6#
它溢出了,因为数字是负数。
试试这个,它会起作用的:
t3irkdon7#
这就是你能做到的。
它不能按你的方式工作的原因:
Integer.parseInt
需要一个有符号的int,而toHexString
生成无符号结果。所以如果你插入比0x7FFFFFF
,将自动抛出错误。如果你把它解析为long
相反,它仍然会被签署。但当您将它转换回int时,它将溢出到正确的值。ztigrdn88#
以下代码将起作用:
368yc8dk9#
尝试使用biginteger类,它可以工作。
mefy6pfw10#
呵呵,好奇。可以说,我认为这是一个“内部缺陷”。
根本原因是整数类是如何编写的。基本上,parseint对正数进行了“优化”。当它解析字符串时,它累积地构建结果,但取反。然后它翻转最终结果的符号。
例子:
66=0x42
解析如下:
现在,让我们看看您的示例FF8000
edit(addition):为了让parseint()对-integer.max\u value<=n<=integer.max\u value“一致地”工作,当累积结果中达到-integer.max\u value时,它们必须实现逻辑来“旋转”,从整数范围的最大端开始,然后从那里继续向下。为什么他们不这样做,人们必须问乔什布洛赫或谁在第一时间实现了它。这可能只是一个优化。
然而,
就因为这个原因,一切正常。在integer的sourcee中可以找到此注解。