当前位置: 首页 > 面试题库 >

为什么Java和Go的gzip会得到不同的结果?

乐正秦斩
2023-03-14
问题内容

首先,我的Java版本:

string str = "helloworld";
ByteArrayOutputStream localByteArrayOutputStream = new ByteArrayOutputStream(str.length());
GZIPOutputStream localGZIPOutputStream = new GZIPOutputStream(localByteArrayOutputStream);
localGZIPOutputStream.write(str.getBytes("UTF-8"));
localGZIPOutputStream.close();
localByteArrayOutputStream.close();
for(int i = 0;i < localByteArrayOutputStream.toByteArray().length;i ++){
    System.out.println(localByteArrayOutputStream.toByteArray()[i]);
}

输出为:

31 -117 8 0 0 0 0 0 0 -53 72 -51 -55 -55 47 -49 47 -54 73 1 0 -83 32 -21 -7 10
0 0 0

然后是Go版本:

var gzBf bytes.Buffer
gzSizeBf := bufio.NewWriterSize(&gzBf, len(str))
gz := gzip.NewWriter(gzSizeBf)
gz.Write([]byte(str))
gz.Flush()
gz.Close()
gzSizeBf.Flush()
GB := (&gzBf).Bytes()
for i := 0; i < len(GB); i++ {
    fmt.Println(GB[i])
}

输出:

31 139 8 0 0 9 110 136 0 255 202 72 205 201 201 47 207 47 202 73 1 0 0 0 255
255 1 0 0 255 255 173 32 235 249 10 0 0 0

为什么?

我以为这可能是最初由这两种语言的不同字节读取方法引起的。但是我注意到0永远不能转换为9 []byte

我写错了代码吗?有什么方法可以使我的Go程序获得与Java程序相同的输出?

谢谢!


问题答案:

从RFC 1952开始,GZip文件头的结构如下:

+---+---+---+---+---+---+---+---+---+---+
|ID1|ID2|CM |FLG|     MTIME     |XFL|OS | (more-->)
+---+---+---+---+---+---+---+---+---+---+

查看您提供的输出,我们有:

                          |    Java |          Go
ID1                       |      31 |          31
ID2                       |     139 |         139
CM (compression method)   |       8 |           8
FLG (flags)               |       0 |           0
MTIME (modification time) | 0 0 0 0 | 0 9 110 136
XFL (extra flags)         |       0 |           0
OS (operating system)     |       0 |         255

因此,我们可以看到Go正在设置标头的修改时间字段,并将操作系统设置为255(未知)而不是0(FAT文件系统)。在其他方面,它们表示文件是以相同方式压缩的。

通常,这些差异是无害的。如果要确定两个压缩文件是否相同,则应真正比较文件的解压缩版本。



 类似资料:
  • 我在这里创建了两个函数,它们几乎100%相同。唯一的区别是函数的regex字符集的顺序不同。为什么这两个函数会产生不同的输出?

  • 问题内容: 为什么需要添加“ L”字母以获得正确的长值?还有什么其他价值呢? 问题答案: 你的第一个值实际上是一个long(因为是,并且是,所以带值的值的结果就是一个long值。 但是第二个值是一个整数(因为你仅将一个值与一个值混用。所以结果将是一个整数。现在,所获得的结果超出了整数的实际范围。因此,在分配给该变量之前,被截断以适合有效的整数范围。 查看以下打印语句: 当你运行上面的代码时: 输出

  • 问题内容: 我一直都在思考和互相扮演布尔对象。但是,这种想法被涉及空数组时的意外行为所动摇。 这是一个演示小品。为什么表现不佳? 问题答案: 因为。您可以将长度值强制改为。 编辑: AngularJS的指令或取决于用于评估传入值的函数。这是toBoolean()的源代码: 您可以在JS控制台中验证以下代码: 这就解释了为什么。由于何时直接传递到,因此它会评估正确的结果。然而,当被传递到,它不评估到

  • 问题内容: 为什么更改总和顺序会返回不同的结果? = = 双方的Java和JavaScript的返回相同的结果。 我知道,由于以二进制表示浮点数的方式,某些有理数( 例如1/3-0.333333 … )无法精确表示。 为什么简单地更改元素的顺序会影响结果? 问题答案: 也许这个问题很愚蠢,但是为什么仅仅改变元素的顺序会影响结果呢? 它将根据值的大小更改四舍五入的点。作为示例 _样的_事情,我们所看

  • 为什么改变求和顺序会返回不同的结果? = Java和JavaScript都返回相同的结果。 我知道,由于浮点数在二进制中的表示方式,一些有理数(如1/3-0.333333...)不能精确表示。 为什么简单地改变元素的顺序会影响结果?

  • 我每次都会得到新的回应。 我想知道为什么用第一种方法得到同样的reponse?