PAKO and MINGW return different gzip outputs from the same input

Hi, using the same data as input, pako and mingw’s gzip commands return different outputs, as shown below:

The input is this file:

Is there a reason for this to happen?

functions I used: pako pako.gzip(input); mingw gzip < input.oct > input.gz

if I decompress the file generated by pako using the gunzip command in mingw, I get the original “raw” file without problems…

I really don’t want to bother you all with “third-party issues”, but it turns out that with mingw I can compress and use the result in other applications without problems, but with pako I’m not that lucky…

I think it is worth informing that I’m passing the pako output through a ‘blob’ to make it available as a download for the user, and i’m using the “application/gzip” mime type.

[CubeBR]

So, it turns out that the inputs I was using were not exactly the same, my fault. The confusion occurred because, for one of the inputs, I was using plain text structured as hexadecimal (with space characters for easy viewing), and the other was a file encoded correctly as hexadecimal, this was obviously affecting the pako output…

[puzrin]

There are lot of low-level deflate options - window size, compression level and so on. To compare binaries you should know those values.

Pako has tests, proving results are the same with zlib, that’s enougth https://github.com/nodeca/pako/blob/master/test/deflate.js.