Java 可使用额外字节序列化

我使用

ObjectOutputStream

方法

writeUnshared（）

对

-999

进行了序列化测试（

long num=-999

）

我将源代码部署到两个不同的weblogic服务器：

机器1：

bea 10.3.2，Jrockit 160_14_R27.6.5-32，Windows server 2003

机器2：

bea 10.3.2，Jrockit 160_14_R27.6.5-32，Windows xp

结果是不同的：

结果1：

ACED00057372000E6A6176612E6C616E672E6C66E673B8BE490CC8F23DF0200014A000576616C7565787200106A6176612E6C616E672E756D62657286AC951D0B94E08B020000072016A6176612E6C616E672E672F626A567400000000000000000000000000000770FFFFFFFC19

结果2：

ACED00057372000E6A6176612E6C616E672E6C6F6E673B8BE490CC8F23DF0200014A000576616C7565787200106A6176612E6C616E672E756D62657286AC951D0B94E08B02000007FFFFFC19

差异为

7200106A6176612E6C616E672E4F626A656374000000000000000078

，等效的ascill转换如下：

r[0][16]java.lang.Object[0][0][0][0][0][0][0][0][0][0][0]x


r = TC_CLASSDESC
X = TC_ENDBLOCKDATA

[0][16] = length of the new class description
java.lang.object = the class being describe

我的问题是，是否有任何设置包括或排除以下额外字节？

---

有没有办法使测试在两台不同的服务器上保持一致

您想测试什么？我们将序列化哈希存储在数据库中。当我们从数据库中检索原始值999时，我们将尝试序列化它并比较存储在数据库中的值以确保数据的完整性。我们使用的是Java版本6。我不知道您的问题的答案，但我知道我不会依赖不同的机器以这种方式生成相同的哈希。编写一个自己的散列函数，以便在不同的机器、java环境、java次要版本等中控制其值。我需要找出额外数据块的原因，以便说服我的老板更改当前的算法。我完全同意，当前用于检查数据完整性的哈希算法似乎不是万无一失的，我遇到的问题就说明了这一点。