为什么 Java 和 Go 的 gzip 得到不同的结果？
Why do gzip of Java and Go get different results?
首先，我的 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
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 程序相同的输出？
谢谢！
首先是 Java 中的 byte 类型是有符号的，它的范围是 -128..127，而在 Go 中 byte 是 [= 的别名18=] 并且范围为 0..255。所以如果你想比较结果，你必须将负 Java 值移动 256（添加 256）。
提示：要以无符号方式显示 Java byte 值，请使用：byteValue & 0xff 使用 8 将其转换为 int byte 的位作为 int 中的最低 8 位。或者更好：以十六进制形式显示两个结果，这样您就不必关心 sign-ness...
即使你进行了转换，你仍然会看到不同的结果。这可能是由于不同语言的默认压缩级别不同。请注意，虽然 Java 和 Go 中默认的压缩级别都是 6，但这并没有指定，不同的实现允许选择不同的值，并且它也可能在未来的版本中改变。
即使压缩级别相同，您仍然可能会遇到差异，因为 gzip 基于 LZ77 and Huffman coding，它使用建立在频率（概率）上的树来决定输出代码，如果不同的输入字符或位模式具有相同的频率，分配的代码可能在它们之间不同，而且多个输出位模式可能具有相同的长度，因此可能会选择不同的。
如果您想要相同的输出，唯一的方法是（请参阅下面的注释！）使用 0 压缩级别（根本不压缩）。在 Go 中使用压缩级别 gzip.NoCompression，在 Java 中使用 Deflater.NO_COPMRESSION.
Java:
GZIPOutputStream gzip = new GZIPOutputStream(localByteArrayOutputStream) {
{
def.setLevel(Deflater.NO_COMPRESSION);
}
};
开始：
gz, err := gzip.NewWriterLevel(gzSizeBf, gzip.NoCompression)
但我不会担心不同的输出。 Gzip 是一个标准，即使输出不同，您仍然可以使用任何用于压缩数据的 gzip 解码器解压缩输出，解码后的数据将完全相同。
以下是简化的扩展版本：
这并不重要，但您的代码不必要地复杂。您可以像这样简化它们（这些版本还包括设置 0 压缩级别和转换负 Java byte 值）：
Java版本：
ByteArrayOutputStream buf = new ByteArrayOutputStream();
GZIPOutputStream gz = new GZIPOutputStream(buf) {
{ def.setLevel(Deflater.NO_COMPRESSION); }
};
gz.write("helloworld".getBytes("UTF-8"));
gz.close();
for (byte b : buf.toByteArray())
System.out.print((b & 0xff) + " ");
转到版本：
var buf bytes.Buffer
gz, _ := gzip.NewWriterLevel(&buf, gzip.NoCompression)
gz.Write([]byte("helloworld"))
gz.Close()
fmt.Println(buf.Bytes())
备注：
gzip 格式允许在输出中包含一些额外的字段 (headers)。
在 Go 中，这些由 gzip.Header 类型表示：
type Header struct {
Comment string // comment
Extra []byte // "extra data"
ModTime time.Time // modification time
Name string // file name
OS byte // operating system type
}
并且可以通过 Writer.Header 结构字段访问它。 Go 设置并插入它们，而 Java 不会 （将 header 字段保留为零）。因此，即使您在两种语言中将压缩级别设置为 0，输出也不会相同（但 "compressed" 数据将在两种输出中匹配）。
不幸的是，标准 Java 没有提供 way/interface 到 set/add 这些字段，Go 也没有在输出中填写 Header 字段是可选的，因此您将无法生成准确的输出。
一个选项是为 Java 使用支持设置这些字段的第 3 方 GZip 库。 Apache Commons Compress is such an example, it contains a GzipCompressorOutputStream class which has a constructor which allows a GzipParameters 要传递的实例。 GzipParameters 等同于 gzip.Header 结构。只有使用它才能生成准确的输出。
但如前所述，生成精确输出没有 real-life 值。
从 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是设置了header的修改时间字段，并且将操作系统设置为255（未知）而不是0（FAT文件系统）。在其他方面，它们表示文件以相同的方式压缩。
总的来说，这些差异是无害的。如果你想确定两个压缩文件是否相同，那么你应该真正比较文件的解压版本。
首先，我的 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 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 程序相同的输出？
谢谢！
首先是 Java 中的 byte 类型是有符号的，它的范围是 -128..127，而在 Go 中 byte 是 [= 的别名18=] 并且范围为 0..255。所以如果你想比较结果，你必须将负 Java 值移动 256（添加 256）。
提示：要以无符号方式显示 Java byte 值，请使用：byteValue & 0xff 使用 8 将其转换为 int byte 的位作为 int 中的最低 8 位。或者更好：以十六进制形式显示两个结果，这样您就不必关心 sign-ness...
即使你进行了转换，你仍然会看到不同的结果。这可能是由于不同语言的默认压缩级别不同。请注意，虽然 Java 和 Go 中默认的压缩级别都是 6，但这并没有指定，不同的实现允许选择不同的值，并且它也可能在未来的版本中改变。
即使压缩级别相同，您仍然可能会遇到差异，因为 gzip 基于 LZ77 and Huffman coding，它使用建立在频率（概率）上的树来决定输出代码，如果不同的输入字符或位模式具有相同的频率，分配的代码可能在它们之间不同，而且多个输出位模式可能具有相同的长度，因此可能会选择不同的。
如果您想要相同的输出，唯一的方法是（请参阅下面的注释！）使用 0 压缩级别（根本不压缩）。在 Go 中使用压缩级别 gzip.NoCompression，在 Java 中使用 Deflater.NO_COPMRESSION.
Java:
GZIPOutputStream gzip = new GZIPOutputStream(localByteArrayOutputStream) {
{
def.setLevel(Deflater.NO_COMPRESSION);
}
};
开始：
gz, err := gzip.NewWriterLevel(gzSizeBf, gzip.NoCompression)
但我不会担心不同的输出。 Gzip 是一个标准，即使输出不同，您仍然可以使用任何用于压缩数据的 gzip 解码器解压缩输出，解码后的数据将完全相同。
以下是简化的扩展版本：
这并不重要，但您的代码不必要地复杂。您可以像这样简化它们（这些版本还包括设置 0 压缩级别和转换负 Java byte 值）：
Java版本：
ByteArrayOutputStream buf = new ByteArrayOutputStream();
GZIPOutputStream gz = new GZIPOutputStream(buf) {
{ def.setLevel(Deflater.NO_COMPRESSION); }
};
gz.write("helloworld".getBytes("UTF-8"));
gz.close();
for (byte b : buf.toByteArray())
System.out.print((b & 0xff) + " ");
转到版本：
var buf bytes.Buffer
gz, _ := gzip.NewWriterLevel(&buf, gzip.NoCompression)
gz.Write([]byte("helloworld"))
gz.Close()
fmt.Println(buf.Bytes())
备注：
gzip 格式允许在输出中包含一些额外的字段 (headers)。
在 Go 中，这些由 gzip.Header 类型表示：
type Header struct {
Comment string // comment
Extra []byte // "extra data"
ModTime time.Time // modification time
Name string // file name
OS byte // operating system type
}
并且可以通过 Writer.Header 结构字段访问它。 Go 设置并插入它们，而 Java 不会 （将 header 字段保留为零）。因此，即使您在两种语言中将压缩级别设置为 0，输出也不会相同（但 "compressed" 数据将在两种输出中匹配）。
不幸的是，标准 Java 没有提供 way/interface 到 set/add 这些字段，Go 也没有在输出中填写 Header 字段是可选的，因此您将无法生成准确的输出。
一个选项是为 Java 使用支持设置这些字段的第 3 方 GZip 库。 Apache Commons Compress is such an example, it contains a GzipCompressorOutputStream class which has a constructor which allows a GzipParameters 要传递的实例。 GzipParameters 等同于 gzip.Header 结构。只有使用它才能生成准确的输出。
但如前所述，生成精确输出没有 real-life 值。
从 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是设置了header的修改时间字段，并且将操作系统设置为255（未知）而不是0（FAT文件系统）。在其他方面，它们表示文件以相同的方式压缩。
总的来说，这些差异是无害的。如果你想确定两个压缩文件是否相同，那么你应该真正比较文件的解压版本。