When using GZIPInputStream in JAVA, it is not passing the whole buffer to zlib and inflate it as a GZIP format. Instead, It seems that GZIP header is been processed in JAVA side, and then pass the remaining part（raw deflate data + GZIP trailer）to zlib and do the inflate work as a DEFLATE format.
My question is how does zlib do inflate work correctly, as the data passed in is not just a raw deflate data? In other words, how does zlib keeps the 8-bytes trailer and not treated it as the data needs to be decompressed?
Asked
Active
Viewed 176 times
0
MO15
- 23
- 3
-
Does [this](https://stackoverflow.com/a/22311297/2970947) answer your question? – Elliott Frisch Dec 29 '21 at 02:59
-
sorry, but no. In my case, the data is not processed as a GZIP format. – MO15 Dec 29 '21 at 03:17
-
Could you post code sample of this issue. – DuncG Dec 29 '21 at 11:09
-
What I ask is a general question, I believe every JAVA code using GZIPInputStream class is facing this. Let me explain my question clearly, GZIP = GZIP header + raw deflate data + GZIP trailer. If using zlib to inflate whole things in GZIP format, everything's fine. However in ```GZIPInputStream``` class, it doesn't use GZIP format but DEFLATE format, and instead of passing whole GZIP things above, it pass the data to zlib without the GZIP header, ie raw deflate data + GZIP trailer. In my opinion, zlib needs to inflate the raw deflate data part and keep GZIP trailer unchanged. – MO15 Dec 29 '21 at 13:07
-
Please provide enough code so others can better understand or reproduce the problem. – Community Jan 06 '22 at 04:37
1 Answers
0
The deflate format is self-terminating. zlib stops decompressing the raw deflate stream until the deflate block marked as the last block is processed. What's left over is the trailer for the Java code to deal with.
Mark Adler
- 101,978
- 13
- 118
- 158