10-11-2024 10:15 AM
Looking to compress a single string of data with Gzip, a single file compression format.
Using the OpenG gives me the following error:
ZLIB Inflate Extended__ogtk.vi<APPEND>
<b>Complete call chain:</b>
ZLIB Inflate Extended__ogtk.vi
Simple Text Compression Gzip.vi
Furthermore, I cannot open the file with 7zip even after saving it. What metadata am I missing for this compression to work correctly?
Solved! Go to Solution.
10-11-2024 10:32 AM
Are you sure to use the latest version 5.0.5 of the OpenG ZIP library?
And how? Would you mind donwnconverting the VI to 2020 or earlier?
10-11-2024 10:43 AM
Yes,
v5.0.5-1
I am simply passing in a string. Since Gzip is single file compression, shouldn't it be enough to just save the compressed string as a file?
Attached is the VI saved as 20.0
10-11-2024 03:40 PM
Two remarks:
1) The "detect" seems to somehow stumble. If you select explicitly "gzip" for the Inflate that one will work.
2) gzip is a binary stream. This means you should use the Write Binary File function, not the Write Text File function!
10-14-2024 08:37 AM
I looked at it over the weekend. I had misunderstood something about how the code worked when I naively added the detect selection to the VI interface. Basically you can select zlib + gzip if you want the code to detect what type of header is present. But there is no fail proof way to detect if there is a header or not. This is because the two header standards have guaranteed different values in the first two bytes. But there is no way to guarantee that a headerless deflate stream couldn't contain values in the two bytes that might not be recognized as valid gzip or zlib header. It's unlikely to happen but not impossible. So I'll have to remove that detect option in the next release. I rather don't have that option than letting users believe there would be a safe way to detect what sort of deflate stream is passed to the function.