java.lang.Integer 的 Java 反序列化 - 异常

发布于 2024-07-19 21:24:10 字数 320 浏览 7 评论 0原文

反序列化 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

黯然 2024-07-26 21:24:10

我遇到了同样的问题,这是因为当我们尝试将 Integer 对象存储到 String 时,字符编码变得混乱,并且在反序列化时,serialVersionUID 读取是错误的。 这就是这个错误的根本原因。
为了避免此错误,请在将其存储到字符串之前使用 Base64 编码
查看此答案并为我解决了问题。

        /** Read the object from Base64 string. */
   private static Object fromString( String str ) throws IOException, ClassNotFoundException {
        byte [] data = Base64.getDecoder().decode(str);
        ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data));
        Object o = ois.readObject();
        ois.close();
        return o;
   }

    /** Write the object to a Base64 string. */
    private static String toString( Serializable o ) throws IOException {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream( baos );
        oos.writeObject( o );
        oos.close();
        return Base64.getEncoder().encodeToString(baos.toByteArray()); 
    }

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.

        /** Read the object from Base64 string. */
   private static Object fromString( String str ) throws IOException, ClassNotFoundException {
        byte [] data = Base64.getDecoder().decode(str);
        ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data));
        Object o = ois.readObject();
        ois.close();
        return o;
   }

    /** Write the object to a Base64 string. */
    private static String toString( Serializable o ) throws IOException {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream( baos );
        oos.writeObject( o );
        oos.close();
        return Base64.getEncoder().encodeToString(baos.toByteArray()); 
    }
烂柯人 2024-07-26 21:24:10

我在编译的 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

心头的小情儿 2024-07-26 21:24:10

检查 Integer 的源代码,这是我在几个版本的 java 中为 Integer 提供的内容:

/** use serialVersionUID from JDK 1.0.2 for interoperability */
private static final long serialVersionUID = 1360826667806852920L;

所以我想说问题出在你的一个类上,你在序列化和反序列化之间进行了更改,并且没有特定的serialVersionUID...

也许你应该看看这个,相同的问题描述,它看起来比如错误的序列化/反序列化代码......

check the source code for Integer, here is what I have for Integer in several verions of java:

/** use serialVersionUID from JDK 1.0.2 for interoperability */
private static final long serialVersionUID = 1360826667806852920L;

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....

葬シ愛 2024-07-26 21:24:10

那不应该发生。 请注意,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.

赴月观长安 2024-07-26 21:24:10

通过查看 JDK 源代码,1360826667806852920 是 Integer 的正确 serialVersionUID。 我无法在 JDK 中找到 serialVersionUID 1360826667802527544 的任何类。

有趣的是,在 Google 上搜索 1360826667802527544 发现其他一些人也遇到此问题,尤其是 Sun 论坛上的此帖子。 那里的问题是,该人将字节存储在字符串中,并且序列化的数据被破坏。 由于您获得了相同的 serialVersionUID ,因此您很可能遇到了类似的问题。

切勿将字节存储在 String 中。 使用字节数组或设计用于保存字节而不是字符的类。

From looking at the JDK source, 1360826667806852920 is the correct serialVersionUID for Integer. I wasn't able to find any classes in the JDK with the serialVersionUID 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文