java.lang.Integer 的 Java 反序列化 - 异常
反序列化 HashMap
时收到以下异常:
java.io.InvalidClassException: java.lang.Integer; local class incompatible: stream classdesc serialVersionUID = 1360826667802527544, local class serialVersionUID = 1360826667806852920
在同一台计算机上使用相同的 JRE 进行序列化和反序列化。 JDK 1.6.0_12
Recieved the following exception when deserializing a HashMap<String, Integer>
:
java.io.InvalidClassException: java.lang.Integer; local class incompatible: stream classdesc serialVersionUID = 1360826667802527544, local class serialVersionUID = 1360826667806852920
Serialized and deserialized on the same machine, with the same JRE. JDK 1.6.0_12
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我遇到了同样的问题,这是因为当我们尝试将 Integer 对象存储到 String 时,字符编码变得混乱,并且在反序列化时,serialVersionUID 读取是错误的。 这就是这个错误的根本原因。
为了避免此错误,请在将其存储到字符串之前使用 Base64 编码。
查看此答案并为我解决了问题。
I faced the same issue and it is because when we are trying to store Integer object to String, the character encoding is getting messed up and while deserialization the serialVersionUID read is wrong. That's the root cause of this error.
To avoid this error use Base64 encoding before storing it to String.
see this answer and the problem resolved for me.
我在编译的 jasperreport 上遇到了同样的问题。
由于 ant 构建的过滤,服务器上的打包耳朵已损坏。 结果原来的jasperreport文件跟耳边的有一些差异。
我已经修改了 ant 构建以仅复制文件(而不是过滤)而不过滤
I've run into the same issue on a compiled jasperreport.
The packed ear on the server was corrupted due to the filtering of the ant build. As a result, the original jasperreport file with the one on the ear had some differences.
I've modified the ant build to copy only the file (instead of filtering) and not filter the
检查 Integer 的源代码,这是我在几个版本的 java 中为 Integer 提供的内容:
所以我想说问题出在你的一个类上,你在序列化和反序列化之间进行了更改,并且没有特定的serialVersionUID...
也许你应该看看这个,相同的问题描述,它看起来比如错误的序列化/反序列化代码......
check the source code for Integer, here is what I have for Integer in several verions of java:
So I'd say the problem comes from a class of yours that you changed between serialization and deserialization and that has no specific serialVersionUID...
Maybe you should look at this, same problem description and it looks like wrong serialization / deserialization code....
那不应该发生。 请注意,ID 仅最后几位数字不同; 第二个是我在 JDK 源代码中看到的。
我的猜测是序列化流以某种方式损坏了。
That shouldn't happen. Note that the IDs differ only in the last few digits; the second one ist the one I see in my JDK sources.
My guess is that the serialized stream got corrupted somehow.
通过查看 JDK 源代码,1360826667806852920 是
Integer
的正确serialVersionUID
。 我无法在 JDK 中找到serialVersionUID
1360826667802527544 的任何类。有趣的是,在 Google 上搜索 1360826667802527544 发现其他一些人也遇到此问题,尤其是 Sun 论坛上的此帖子。 那里的问题是,该人将字节存储在字符串中,并且序列化的数据被破坏。 由于您获得了相同的
serialVersionUID
,因此您很可能遇到了类似的问题。切勿将字节存储在
String
中。 使用字节数组或设计用于保存字节而不是字符的类。From looking at the JDK source, 1360826667806852920 is the correct
serialVersionUID
forInteger
. I wasn't able to find any classes in the JDK with theserialVersionUID
1360826667802527544.Interestingly, searching for 1360826667802527544 on Google turned up a few other people with this problem, notably this thread on Sun's forums. The problem there was that the person was storing bytes in a String, and the serialized data was getting mangled. Since you're getting the same
serialVersionUID
it seems very likely that you're running into a similar problem.Never store bytes in a
String
. Use a byte array or a class designed to hold bytes, not chars.