COMPRESS() compatibility with other compression utilities

[justin_willey]

Are COMPRESS() / DECOMPRESS() only intended for use within a SQLA database or are the algorithms used compatible with external utilities? In other words, should I expect the output zip archive of this process to be accessible by Windows Explorer, 7zip etc:

create variable uncomp long binary;
create variable comp long binary;
set uncomp = xp_read_file('c:\\temp\\stuff.txt');
set comp = compress(uncomp,'zip');
call xp_write_file('c:\\temp\\stuff.zip',comp);

I find I can't read that file outside SQLA (nor if I use the gzip algorithm). Am I missing something obvious (wouldn't be the first time!)?

The docs say "Zip is a widely supported compression algorithm. Gzip is compatible with the gzip utility on Unix, whereas the zip algorithm is not. " I'm doing my gzip testing on Windows with 7zip, not on Linux/Unix, but other gzip archives seem to work fine.

v17.0.9.4838

[VolkerBarth]

You certainly have noticed Mark's old response here, haven't you?

Note, I'm just adding the link, I have not tested anything related to compressing files at all...

[graeme_perrow · Accepted solution]

John is correct that we use a custom header but only if no compression algorithm is given. If you give 'zip' or 'gzip' as an algorithm, we do not use the header, making the compression compatible with outside tools.

However the name of the 'zip' algorithm is a bit misleading - it does not make the output compatible with Windows .zip files. This algorithm simply compresses data (i.e. a single file) while .zip files are a compressed archive format. If you use 'gzip' as the algorithm instead of 'zip', Windows tools should be able to decompress the data.

[justin_willey · Accepted solution]

Thanks Graeme - that all makes sense.

[johnsmirnios]

I believe that although we use the standard algorithms, we add a custom header to identify encryption type and/or remove some of the headers that the file-based utilities would add. For example, zip files contain a directory of files included in the archive and that would be very expensive to include on a per-value basis.

[justin_willey]

Thanks - yes that makes sense about the folder stuff being the difference.