Zlib Download

0 views

Skip to first unread message

Neomi Bensch

unread,

Aug 3, 2024, 4:41:16 PM8/3/24

to atuntrussen

For applications that require data compression, the functions in this moduleallow compression and decompression, using the zlib library. The zlib libraryhas its own home page at There are knownincompatibilities between the Python module and versions of the zlib libraryearlier than 1.1.3; 1.1.3 has a security vulnerability, so we recommend using1.1.4 or later.

Computes an Adler-32 checksum of data. (An Adler-32 checksum is almost asreliable as a CRC32 but can be computed much more quickly.) The resultis an unsigned 32-bit integer. If value is present, it is used asthe starting value of the checksum; otherwise, a default value of 1is used. Passing in value allows computing a running checksum over theconcatenation of several inputs. The algorithm is not cryptographicallystrong, and should not be used for authentication or digital signatures. Sincethe algorithm is designed for use as a checksum algorithm, it is not suitablefor use as a general hash algorithm.

Compresses the bytes in data, returning a bytes object containing compressed data.level is an integer from 0 to 9 or -1 controlling the level of compression;1 (Z_BEST_SPEED) is fastest and produces the least compression, 9 (Z_BEST_COMPRESSION)is slowest and produces the most. 0 (Z_NO_COMPRESSION) is no compression.The default value is -1 (Z_DEFAULT_COMPRESSION). Z_DEFAULT_COMPRESSION represents a defaultcompromise between speed and compression (currently equivalent to level 6).

+9 to +15: The base-two logarithm of the window size, whichtherefore ranges between 512 and 32768. Larger values producebetter compression at the expense of greater memory usage. Theresulting output will include a zlib-specific header and trailer.

zdict is a predefined compression dictionary. This is a sequence of bytes(such as a bytes object) containing subsequences that are expectedto occur frequently in the data that is to be compressed. Those subsequencesthat are expected to be most common should come at the end of the dictionary.

Decompresses the bytes in data, returning a bytes object containing theuncompressed data. The wbits parameter depends onthe format of data, and is discussed further below.If bufsize is given, it is used as the initial size of the outputbuffer. Raises the error exception if any error occurs.

When decompressing a stream, the window size must not be smallerthan the size originally used to compress the stream; using a too-smallvalue may result in an error exception. The default wbits valuecorresponds to the largest window size and requires a zlib header andtrailer to be included.

Compress data, returning a bytes object containing compressed data for at leastpart of the data in data. This data should be concatenated to the outputproduced by any preceding calls to the compress() method. Some input maybe kept in internal buffers for later processing.

All pending input is processed, and a bytes object containing the remaining compressedoutput is returned. mode can be selected from the constantsZ_NO_FLUSH, Z_PARTIAL_FLUSH, Z_SYNC_FLUSH,Z_FULL_FLUSH, Z_BLOCK (zlib 1.2.3.4), or Z_FINISH,defaulting to Z_FINISH. Except Z_FINISH, all constantsallow compressing further bytestrings of data, while Z_FINISH finishes thecompressed stream and prevents compressing any more data. After calling flush()with mode set to Z_FINISH, the compress() method cannot be called again;the only realistic action is to delete the object.

A bytes object which contains any bytes past the end of the compressed data. That is,this remains b"" until the last byte that contains compression data isavailable. If the whole bytestring turned out to contain compressed data, this isb"", an empty bytes object.

A bytes object that contains any data that was not consumed by the lastdecompress() call because it exceeded the limit for the uncompressed databuffer. This data has not yet been seen by the zlib machinery, so you must feedit (possibly with further data concatenated to it) back to a subsequentdecompress() method call in order to get correct output.

Decompress data, returning a bytes object containing the uncompressed datacorresponding to at least part of the data in string. This data should beconcatenated to the output produced by any preceding calls to thedecompress() method. Some of the input data may be preserved in internalbuffers for later processing.

If the optional parameter max_length is non-zero then the return value will beno longer than max_length. This may mean that not all of the compressed inputcan be processed; and unconsumed data will be stored in the attributeunconsumed_tail. This bytestring must be passed to a subsequent call todecompress() if decompression is to continue. If max_length is zerothen the whole input is decompressed, and unconsumed_tail is empty.

All pending input is processed, and a bytes object containing the remaininguncompressed output is returned. After calling flush(), thedecompress() method cannot be called again; the only realistic action isto delete the object.

I've just moved over to Ubuntu 8.10 as my dev box; it's my first serious foray into Linux as a daily-use OS, and I'm having a hard time getting Rails going. I have followed a number of tutorials which all seem to work fine, but when I try and use gem install or gem update on anything, I get an error that looks like this:

I have (as recommended in the tutorials) installed zlib, zlib1g, and zlib1g-dev. I've even found a few tutorials on this particular problem (all for flavors other than mine, however) but they didn't help.

I am using Ubuntu 10.04 (Lucid), i wanted to install ruby 1.9.2 because 1.9.1 is not recommended with Rails. So I downloaded the source for 1.9.2 and unzipped/unarchived it. my source distro is ruby-1.9.2-p0. After I unpacked it, I built zlib as follows:

That commands seem to fix the problem, then I execute gem update --system and the error with zlib vanished. Then I install rails with gem install rails. Note to mention I had installed gem before, and after recompile and install zlib, I don't recompile neither install gem (actually I don't knew how uninstall it because I don't found a script to do that)

I am extracting a sheet in an excel workbook and consolidating it into another excel file. After 6 workbooks I get this "zLib Error". I now get it on all my workflows so I stripped it down to one input tool and a Browser and still I get the error after it has read 6 files. It usually zips through 60 files.

As a test, try copying all the files from W:\Global Provision\2020\Q2 to your local computer and repoint the Input tool to read from the local files. If this works, the error could be due to the vpn.

I copied all the files to my hard drive and ran everything from there but it did the same; after processing 6 files it returned this zlib error before stopping. I also tried other workflows working from the hard drive and I get the same results.

This sounds like it could be an alteryx support issue. You can reach them at sup...@alteryx.com or if you go to the support page and click on the email option it will open a template email that you can fill out.

I did that already, as posted in my question.
After decoding, the string I have left is the zipped content.
Since I could not unzip it with elixir, I write the base64 decoded string --which should be the zipped content-- to a file ( called jw315.zip).
If I open that with a folder manager that can unzip it (like thunar e.g.) I see the the correct unzipped content.
So I so not know why I can unzip it with any unzip program, but not with :zlib.unzip.

I have just started migrating an application to 64 bit, hoping to get access to more memory. The code runs, which is good. However, I need to also implement code that decompresses gzipped data. I ran my proof of concept in 32 bits and got it working beautifully, using the OpenG ZLIB library.

So you'll need that 64 bit dll. IIRC, the 64 bit dll I found online somewhere (will look where), uses WinAPI iso C calling convention. I only use one function (from libz, not LVZLib, but that's the same dll).

At some point, I asked the makers of the zlib dll if they could put a pre-compiled 64-bit dll online. They said they liked the idea, but they didn't let me know if they ever did it (not did I asked again).

Some functions, even if we can get a 64-bit pre-compiled dll, might need adaptation to deal with proper pointer sizes. This might not be needed, as most functions will probably pass arrays\strings anyway, so the pointer size will automatically adapt.

EDIT: Just recalled that there is a widely available 64-bit dll available, but the version has a bug, making it not compress on Windows. I had to look long and hard for a more recent version, but I could only find one that had the changed calling convention... I think we need someone to recompile from source code...

Here is a beta version of the LabVIEW ZIP Library that does contain 64 bit support. For Windows it works fine, for the 64 bit Linux variants there seems to be a strange bug that treats directories somehow as files when zipping up a file.

And yes the old zlib library used the standard calling convention, then they changed it to cdecl for all platforms. Not sure if they changed it back again. It was one of the reasons I initially decided to create my own version for the OpenG library together with the fact that I also wanted to have the ZIP handling code in the same DLL/shared library. I found it pretty stupid to have to create conditional VIs just for the sake of interfacing to standard calling convention on Windows and cdecl on all other platforms and at that time there was no conditional compile structure at all, not even as undocumented feature. That only came to life in LabVIEW 7.x.