I found that, for the same string, the result of using zlib in golang is different with that in c. How can I compress in golang and decompress in c by zlib ? Which version does go use?
Asked
Active
Viewed 802 times
2 Answers
4
Just because the compressed data is different doesn't mean that it can't be decompressed. zlib-compliant compressed data generated anywhere can be decompressed by a compliant zlib decoder anywhere else. Did you try decompressing?
As for the difference, @twotwotwo points out that compress/zlib in Go is not the original zlib library, but rather a different implementation written in Go. So it would be expected to generate different output if it uses different algorithms to find matches and/or emit blocks.
Mark Adler
- 101,978
- 13
- 118
- 158
-
It's most awesome you answer so many zlib and compression q's here. The question text incorrectly suggested that asker was using zlib-the-library from Go (and the first rev of my answer did nothing to set that straight). So, bears noting that Go's compressed output is different because it's using its own compression code instead of zlib, and the details of its algorithm differ ([related bug](https://github.com/golang/go/issues/2726)). Suspect that your point that different compressed output doesn't mean it can't be decompressed w/zlib is what asker needed to know, though. – twotwotwo Jan 09 '15 at 07:31
2
As background, Go doesn't come with the zlib library, and compress/zlib is only has its name 'cause it works with zlib format data. Though the format's the same, the details of the compression algorithm aren't (leading, for example, to worse speed and slightly worse compression for the Go library). So output won't typically match, even at the same compression level and with the same wrapper.
The answer from an author of zlib (Mark Adler) raises the essential point that different output doesn't mean the output can't be decompressed by zlib. I think that's your real answer here, but leaving the rest of this around because it has some non-overlapping information about what Go's doing/your options in Go.
The Vitess project (YouTube's internal MySQL proxy) needed the speed of C zlib for their application, so they wrote an adapter, cgzip. You didn't say what format you wanted the output in; if the answer is not gzip, you'll have to fork and modify cgzip so it calls the right bits of zlib to produce what you need.
The upside of using cgzip or similar is that it'll act like zlib because it's using zlib. The downside is that you'll no no longer have a pure-Go app, so you lose the trivial cross-compiles and gain an additional dependency on the environment your program's built and run in (though in zlib's case, the ubiquity and stable API mean it's much less of an issue to take it as a dep than some libraries).
twotwotwo
- 28,310
- 8
- 69
- 56