对于Java中明显的gzip文本，不是gzip格式

Question

我一直在尝试实现解压以GZIP格式压缩的文本，下面是我实现的方法

private byte[] decompress(String compressed) throws Exception {
    ByteArrayOutputStream out = new ByteArrayOutputStream();
    ByteArrayInputStream in = new 
        ByteArrayInputStream(compressed.getBytes(StandardCharsets.UTF_8));
    GZIPInputStream ungzip = new GZIPInputStream(in);
    byte[] buffer = new byte[256];
    int n;
    while ((n = ungzip.read(buffer)) >= 0) {
        out.write(buffer, 0, n);
    }
    return out.toByteArray();
}

现在我正在测试以下压缩文本的解决方案：

H4sIAAAAAAAACjM0MjYxBQAcOvXLBQAAAA==

而且gzip格式也没有例外。我尝试了不同的方法，但仍然存在这个错误。也许有人知道我做错了什么？

Answer 1

这不是gzip格式的。一般来说，压缩后的数据不能是字符串（因为压缩后的数据是字节，而字符串不是字节。一些语言/教程/20世纪80年代的思维将二者混为一谈，但现在是20世纪20年代。我们不再这样做了。这里的字符比英语中使用的要多）。

看起来可能发生了以下情况：

• 有人有一些数据。
• 他们把它压缩了。
• 然后他们使用Base64编码将gzip流（字节）转换为字符。
• 他们寄给你了
• 您现在想回到数据。

考虑到发生了两个转换（首先是gzip-it，然后是base64-it），您还需要做两个相反的转换。你需要：

• 获取输入字符串，并对其进行de-base64处理，得到字节

因此：

byte[] gzipped = java.util.Base64.getDecoder().decode(compressed);
var in = new GZIPInputStream(new ByteArrayInputStream(gzipped));
return in.readAllBytes();

注：

像这样将数据从输入推送到输出流是一种资源浪费和一堆挑剔的代码。没有必要写这个；只需调用readAllBytes。

如果传入的Base64很大，有一些方法可以以流式传输的方式来实现这一点。这需要这个方法接收一个Reader（而不是不能流式传输的String），并返回一个InputStream而不是byte[]。当然，如果输入不是特别大，就没有必要了。上面的方法有些浪费——基本64版数据和非基本64版数据，以及解压缩的数据同时都在内存中，你无法避免这一点，垃圾收集器也无法收集这两者之间的任何东西（因为调用方很可能会继续引用基本64版字符串）。

换句话说，如果压缩率为50%，且未压缩数据总量为100MB，则此方法需要的时间超过：

100MB（未压缩）50MB（压缩）50*4/3=67MB（压缩但基于64MB）=~217MB内存。

您比我们更清楚VM运行在多少堆上，以及输入数据可能会有多大。

注意：Base64传输效率极低，每3个字节的输入数据需要4个字节的Base64内容，如果数据传输采用UTF-16，则每3个字节甚至需要8个字节。哎哟考虑到内容是gzip压缩的，这感觉有点愚蠢：首先我们煞费苦心地缩小这个东西的大小，然后我们随意地把它放大33%，可能没有什么好的理由。你可能想检查一下通向这个的“管道”，也许你可以。。。消除这个问题的base64方面。

例如，如果你有一个有线协议，有人认为JSON是个好主意，那么。。仅仅不要这样做。如果需要传输大量原始数据，JSON不是一个好主意。使用protobuf，或者发送JSON和Blob的组合，等等。