Note that there are some explanatory texts on larger screens.

plurals
  1. POzlib decompression failing
    text
    copied!<p>I'm writing an application that needs to uncompress data compressed by another application (which is outside my control - I cannot make changes to it's source code). The producer application uses zlib to compress data using the z_stream mechanism. It uses the Z_FULL_FLUSH frequently (probably too frequently, in my opinion, but that's another matter). This third party application is also able to uncompress it's own data, so I'm pretty confident that the data itself is correct. </p> <p>In my test, I'm using this third party app to compress the following simple text file (in hex):</p> <p><code>48 65 6c 6c 6f 20 57 6f 72 6c 64 21 0d 0a</code></p> <p>The compressed bytes I receive from the app look like this (again, in hex):</p> <p><code>78 9c f2 48 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 00 00 00 ff ff</code></p> <p>If I try and compress the same data, I get very similar results:</p> <p><code>78 9c f3 48 cd c9 c9 57 08 cf 2f ca 49 51 e4 e5 02 00 24 e9 04 55</code></p> <p>There are two differences that I can see:</p> <p>First, the fourth byte is <code>F2</code>, rather than <code>F3</code>, so the deflate "final block" bit has not been set. I assume this is because the stream interface never knows when the end of the incoming data will be, so never sets that bit?</p> <p>Finally, the last four bytes in the external data is <code>00 00 FF FF</code>, whereas in my test data it is <code>24 E9 04 55</code>. Searching around I found on this page</p> <p><a href="http://www.bolet.org/~pornin/deflate-flush.html" rel="noreferrer">http://www.bolet.org/~pornin/deflate-flush.html</a></p> <p>...that this is a signature of a sync or full flush.</p> <p>When I try and decompress my own data using the <code>decompress()</code> function, everything works perfectly. However, when I try and decompress the external data the <code>decompress()</code> function call fails with a return code of <code>Z_DATA_ERROR</code>, indicating corrupt data.</p> <p>I have a few questions:</p> <ol> <li><p>Should I be able to use the zlib "uncompress" function to uncompress data that has been compressed with the z_stream method?</p></li> <li><p>In the example above, what is the significance of the last four bytes? Given that both the externally compressed data stream and my own test data stream are the same length, what do my last four bytes represent?</p></li> </ol> <p>Cheers</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload