Zlib

数据头

zlib在压缩数据时支持使用gzip数据头（header）、zlib数据头或者不使用数据头。通常情况下，数据压缩使用zlib数据头，因为它提供了错误数据检测的功能。当数据不使用数据头写入时，由于没有任何错误检测的原始DEFLATE数据，那么解压缩的软件将无法得知压缩数据在什么地方结束。

gzip数据头比zlib数据头要大，因为它保存了文件名和其他文件系统信息——事实上，这等同于广泛使用的gzip文件的数据头格式。注意zlib函数库本身并不能创建一个gzip文件，但是它可以将压缩数据写入到一个现成的、具有gzip文件头的文件中。

算法

截至2018年9月，zlib仅支持一个LZ77的变种算法，即DEFLATE的算法。

这个算法使用的系统资源很少，并且对各种数据都能提供很好的压缩效果。这种算法也由ZIP文件所使用。（尽管zip文件格式也支持几种其他的算法）。

zlib的数据头理论上允许使用其他算法，但目前为止仍然只有这一种算法被使用。

使用资源

zlib提供了帮助控制CPU和内存资源使用的方法。通过设置不同的压缩级别数值，即可改变压缩率和压缩速度。

除此之外，zlib还提供了内存管理的功能，以便于在诸如嵌入式系统等资源较为受限的环境中使用。

策略

zlib的压缩算法可以针对特定类型的数据进行优化。

若用户总是使用zlib压缩特定类型的数据，则可以选择有针对性的策略来提高压缩效率和性能。例如，如果用户的数据包含很长的重复数据，那么可以用RLE（运行长度编码）策略进行优化。

对于一般的数据，默认策略往往是最佳的。

错误处理

当采用zlib或gzip数据头时，zlib可以检测并跳过压缩文件数据中的错误。

此外，如果全刷新点（full-flush points）被写入到压缩后的数据流中，那么zlib可以跳过损坏的数据并继续解压缩，并重新同步到下个全刷新点。（尽管zlib并不能纠正错误并修复损坏的数据）。全刷新点技术对于在不可靠的传输途径上的大数据流是很有用的，因为这种场景下丢失一些过去的数据很可能并没有太大影响（比如一些多媒体应用场景）。然而，创建太多的全刷新点会极大地影响速度和压缩率。

数据长度

zlib并没有对于压缩和解压缩数据长度的限制，通过重复调用库函数可以处理无限多的数据块。一些辅助代码（计数变量）可能会因此溢出，但是不影响实际的压缩和解压缩。当压缩一个较长或是无限长数据流时，最好写入全刷新点。

zlib已经成为了一种事实上的业界标准，以至于在标准文档中，zlib和DEFLATE常常被互换使用。数以千计的应用程序直接或间接依靠zlib压缩函数库^[3]，包括：

• Linux核心：使用zlib以实现网络协议的压缩、文件系统的压缩以及引导时解压缩自身的核心。
• libpng，用于PNG图形格式的一个实现，对bitmap数据规定了DEFLATE作为流压缩方法。
• Apache：使用zlib实现http 1.1。
• OpenSSH、OpenSSL：以zlib达到优化加密网络传输。
• FFmpeg：以zlib读写Matroska等以DEFLATE算法压缩的多媒体流格式。
• rsync：以zlib优化远程同步时的传输。
• Subversion、Git和CVS等版本控制系统，使用zlib来压缩和远端仓库的通讯流量。
• dpkg和RPM等包管理软件：以zlib解压缩RPM或者其他数据包。

因为其代码的可移植性、宽松的许可许可以及较小的内存占用，zlib在许多嵌入式设备中也有应用。

• gzip
• DEFLATE
• RFC 1950, RFC 1951, RFC 1952
• LZ77
• ZIP (文件格式)

• 自由软件铸造场

• zlib官方网站 （页面存档备份，存于互联网档案馆）
• php-zlib使用方法