zlib压缩率

‘壹’ 如何发挥zlib压缩解压的最大效

首先说明，这里不是横向比较zlib与别的引擎(rar,leo,powerarc...),是探索如何发挥zlib压缩/解压的最大效率。
先看看如下代码在效率上的差异:
var MS:TMemoryStream;(1):begin MS:=TMemoryStream.Create; MS.Size:=$400000;//4M------------------------------------------------(2):var i:integer;begin MS:=TMemoryStream.Create; for i:=1 to 1024 do MS.Size:=MS.Size+4096;

你会发现，方法(1)只要1个毫秒，方法(2)却要20秒。
因此，如果把解压缩程序写成下面这样，会非常没有效率:
procere ZlibDeCompress(instream,outStream:TStream);var ACS:TDeCompressionStream; buf:array[1..4096] of byte; numread:integer;begin inStream.Position:=0; ACS:=TDeCompressionStream.Create(inStream); try repeat numRead:=ACS.Read(buf,sizeof(buf)); if numread>0 then outStream.Write(buf,numRead); until (numRead=0); finally ACS.Free; end;end;

如果我们知道原始资料的大小，一次确定outStream.Size,效率就可以提高几十倍。方法很简单，我们可以在压缩时，把原始资料的Size写在压缩Stream的头部，如,写一个LongWord的大小,解压时就可以先读出Size,因此，最有效率的解压程序为:
procere ZlibDecompressStream2(Source,Dest:TMemoryStream);var zstream: TZStreamRec; SourceLen,DestLen:LongWord;begin FillChar(zstream,SizeOf(TZStreamRec),0); SourceLen:=Source.Size; Source.Position:=0; Source.Read(DestLen,SizeOf(LongWord)); Dest.Size:=DestLen; zstream.next_in:=Pointer(LongWord(Source.Memory)+SizeOf(LongWord)); zstream.avail_in:=SourceLen-SizeOf(LongWord); zstream.next_out:=Dest.Memory; zstream.avail_out:=DestLen; ZDecompressCheck(InflateInit(zstream)); try ZDecompressCheck(inflate(zstream,Z_NO_FLUSH)); finally ZDecompressCheck(inflateEnd(zstream)); end;end;

用一个4M的文件试试，效率提高近70倍。
同样道理，在压缩的时候，如果能预先知道压缩后的大小，也能提高效率不少，但这似乎是不可能的，也不能盲目的给outStream.Size一个"足够大"的数值，只能按引擎的原理估算一个最接近的数值，zlib推荐的为:
((SourceLen+(SourceLen div 10)+12)+255) and not 255
因此，最有效率的压缩程序为:
procere ZlibCompressStream2(Source,Dest:TMemoryStream; CompressLevel:TZCompressi);var zstream: TZStreamRec; SourceLen,DestLen:LongWord;begin FillChar(zstream,SizeOf(TZStreamRec),0); SourceLen:=Source.Size; DestLen:=SizeOf(LongWord)+((SourceLen+(SourceLen div 10)+12)+255) and not 255; Dest.Size:=DestLen; Dest.Position:=0; Dest.Write(SourceLen,Sizeof(LongWord)); zstream.next_in:=Source.Memory; zstream.avail_in:=SourceLen; zstream.next_out:=Pointer(LongWord(Dest.Memory)+SizeOf(LongWord)); zstream.avail_out:=DestLen-SizeOf(longWord); ZCompressCheck(DeflateInit(zstream,ZLevels[CompressLevel])); try ZCompressCheck(deflate(zstream,Z_FINISH)); finally ZCompressCheck(deflateEnd(zstream)); end; Dest.Size:=zstream.total_out+SizeOf(LongWord);end;

‘贰’ ClickHouse数据压缩

ClickHouse支持多种方式的数据压缩：LZ4和ZSTD。
关于压缩算法的测试，见 这篇文章 。简而言之，LZ4在速度上会更快，但是压缩率较低，ZSTD正好相反。尽管ZSTD比LZ4慢，但是相比传统的压缩方式Zlib，无论是在压缩效率还是速度上，都可以作为Zlib的替代品。
下面我们对比一下这两种压缩方式。压缩测试所用的表（lineorder）结构和数据来自 这里 。未压缩的数据集是680GB。
把上述数据加载到ClickHouse后，默认的LZ4压缩算法下，数据容量是184G（压缩到27%），而ZSTD达到了135GB（压缩到20%）。
如果想要使用ZSTD压缩方式，修改为如下配置即可：

压缩比率对比

压缩后的查询性能如何，我们来跑如下查询看看：

为了保持客观，查询测试会跑两次，第一次是冷数据请求，这次的数据没有被操作系统缓存，第二次是热数据情求，这次的数据已经被操作系统的内存缓存了。
LZ4的性能如下：

ZSTD性能如下：

冷数据查询情况下，两者区别不大，因为消耗在IO方面的时间，远大于消耗在数据解压缩上面的时间。
热数据请求下，LZ4会更快，此时IO代价小，数据解压缩成为性能瓶颈。
综上所述，默认的LZ4压缩方式，会给我们提供更快的执行效率，但是同时需要占用较多的磁盘容量。
ClickHouse抛开高效的SQL执行效率，数据压缩比率也是一个非常喜人的地方。使用Hadoop Node低配置服务器，再加上ClickHouse优秀的压缩性能，单机容量轻松可达几十T，推荐直接使用默认的LZ4压缩方式，用可以接受的少量空间来换查询执行效率的提升。

‘叁’ Zlib的compress、uncompress问题，请教一下！

1. lz77算法对于过小的数据本身性能就不好，导致压缩率极低
2. deflate算法用的静态huffman算法，会引入额外数据
3. deflate算法本身也需要维护数据的额外数据

最终导致压缩结果比压缩前更大。

因为压缩的缓冲区没申请购，导致堆出错，所以delete的时候会崩溃。

‘肆’ 数据流压缩原理和数据压缩Zlib的实现

压缩的本质就是去冗余，去除信息冗余，使用最短的编码保存最完整的数据信息。所以对于不同的场景，压缩采用的算法也因时制宜，比如视频和图片可以采用有损压缩，而文本数据采用无损压缩。压缩率又取决于信息的冗余度，也就是内容中重复的比例。那些均匀分布的随机字符串，压缩率会降到最低，即香农限

deflate是zip文件的默认算法。它更是一种数据流压缩算法。

LZ77压缩算法采用字典的方式进行压缩，是一种简单但是很高效的数据压缩算法。其方式就是把数据中一些可以组织成短语的字符加入字典。维护三个概念： 短语字典、滑动窗口、向前缓冲区

压缩的逆过程，通过解码标记和保持滑动窗口中的符号来更新解压数据。当解码字符被标记:将标记编码成字符拷贝到滑动窗口中，一步一步直到全部翻译完成

在流式传输中，不定长编码数据的解码想要保持唯一性，必须满足唯一可以码的条件。而异前缀码就是一种唯一可译码的候选，当然这样会增加编码的长度，却可以简化解码。

huffman编码是一种基于概率分布的贪心策略最优前缀码。huffman编码可以有效的压缩数据，压缩率取决于数据本身的信息冗余度

计算数据中各符号出现的概率，根据概率从小到大，从下往上反向构建构造码树，这样最终得到的编码的平均长度是最短的。同时也是唯一可译的

解读：在一开始，每一个字符已经按照出现概率的大小排好顺序，在后续的步骤中，每一次将概率最低的两棵树合并，然后用合并后的结果再次排序（为了找出最小的两棵树）。在gzip源码中并没有专门去排序，而是使用专门的数据结构（比如最小堆或者红黑树）。

使用优先队列实现huffman树，最后基于Huffman树最终实现文件压缩。
具体步骤：

gzip = gzip 头 + deflate 编码的实际内容 + gzip 尾

zlib = zlib 头 + deflate 编码的实际内容 + zlib 尾

压缩之前：初始化各种输入输出缓冲区；
压缩：我们可以不断往这些缓冲区中填充内容，然后由deflate函数进行压缩或者indeflate函数进行解压

总结：在调用deflate函数之前，应用程序必须保证至少一个动作被执行（avail_in或者avail_out被设置），用提供更多数据或者消耗更多的数据的方式。avail_out在函数调用之前千万不能为零。应用程序可以随时消耗被压缩的输出数据

‘伍’ 二进制压缩算法有哪些

二进制数据压缩算法二进制是计算技术中广泛采用的一种数制。二进制数据是用0和1两个数码来表示的数。它的基数为2，进位规则是“逢二进一”，借位规则是“借一当二”，由18世纪德国数理哲学大师莱布尼兹发现。当前的计算机系统使用的基本上是二进制系统，数据在计算机中主要是以补码的形式存储的。计算机中的二进制则是一个非常微小的开关，用“开”来表示1，“关”来表示0。

20世纪被称作第三次科技革命的重要标志之一的计算机的发明与应用，因为数字计算机只能识别和处理由‘0’。‘1’符号串组成的代码。其运算模式正是二进制。19世纪爱尔兰逻辑学家乔治布尔对逻辑命题的思考过程转化为对符号“0‘’。‘’1‘’的某种代数演算，二进制是逢2进位的进位制。0、1是基本算符。因为它只使用0、1两个数字符号，非常简单方便，易于用电子方式实现。

二进制压缩 - 算法

二进制压缩

在编程时遇到每个数据只有两种状态，且 dfs 或者 bfs 时遍历时间复杂度高时，可以采用二进制压缩数据，尤其是二维数组。LZFSE

1，zlib和gzip都对deflate进行了封装，比deflate多了数据头和尾

1，苹果开源了新的无损压缩算法 LZFSE ，该算法是去年在iOS 9和OS X 10.10中 引入 的。按照苹果公司的说法，LZFE的压缩增益和ZLib level 5相同，但速度要快2~3倍，能源效率也更高。

LZFSE基于Lempel-Ziv，并使用了 有限状态熵编码，后者基于Jarek Duda在

非对称数字系统（ANS）方面所做的熵编码工作。简单地讲，ANS旨在“终结速度和比率的平衡”，既可以用于精确编码，又可以用于快速编码，并且具有数据加密功能。使用ANS代替更为传统的

Huffman和 算术编码方法的压缩库 越来越多，LZFSE就位列其中。

显然，LZFSE的目标不是成为最好或最快的算法。事实上，苹果公司指出，

LZ4的压缩速度比LZFSE快，而 LZMA提供了更高的压缩率，但代价是比Apple

SDK提供的其他选项要慢一个数量级。当压缩率和速度几乎同等重要，而你又希望降低能源效率时，LZFSE是苹果推荐的选项。

GitHub上提供了LZFSE的参考实现。在MacOS上构建和运行一样简单：

$ xcodebuild install DSTROOT=/tmp/lzfse.dst

如果希望针对当前的iOS设备构建LZFSE，可以执行：

xcodebuild -configuration “Release” -arch armv7 install DSTROOT=/tmp/lzfse.dst

除了 API文档之外，苹果去年还提供了一个 示例项目，展示如何使用LZFSE 进行块和流压缩，这是一个实用的LZFSE入门资源。

LZFSE是在谷歌 brotli之后发布的，后者在去年开源。与LZFSE相比，brotli 似乎是针对一个不同的应用场景进行了优化，比如压缩静态Web资产和Android APK，在这些情况下，压缩率是最重要的。

‘陆’ zlib函数compress解释

zlib 是通用的压缩库，提供了一套 in-memory 压缩和解压函数，并能检测解压出来的数据的完整性(integrity)。zlib 也支持读写 gzip (.gz) 格式的文件。下面介绍两个最有用的函数——compress 和 uncompress。

int compress(Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen);

compress函数将 source 缓冲区中的内容压缩到 dest 缓冲区。 sourceLen 表示source 缓冲区的大小(以字节计)。注意函数的第二个参数 destLen 是传址调用。当调用函数时，destLen表示 dest 缓冲区的大小，destLen > (sourceLen + 12)*100.1%。当函数退出后，destLen 表示压缩后缓冲区的实际大小。此时 destLen / sourceLen 正好是压缩率。

compress 若成功，则返回 Z_OK；若没有足够内存，则返回 Z_MEM_ERROR；若输出缓冲区不够大，则返回 Z_BUF_ERROR。

‘柒’ 压缩文件格式rar和zip有什么区别

楼上的见解比较狭隘。我来全面的解释一下。

一、目录表（TOC）与分卷（Volume）

抛开压缩算法不谈，我认为zip、rar在文件格式上最大的差异就在目录表（Table of Contents，TOC）：zip有TOC，而rar没有。

TOC这个词其实是从出版界借用过来的，指的就是每一本书正文前面的“目录”，它的作用地球人都知道：如果想快速找到书中某一内容，可以先查TOC，然后按照TOC指明的页码直接翻即可。

在纸质书里TOC是印刷出来的一张表，而在电子文件里则是由结构化数据构成的一张表，它的目的同样是为了快速定位：如果想找文件中的某一内容，可以先查TOC，知道感兴趣的内容在文件的什么位置，直接跳过去就行了。最常见的运用就是avi、rm等多媒体文件：播放的时候经常有人在播放条上点来点去跳着看（即“随机访问”），如果没有TOC，在长达几百兆的文件里来回定位会慢死。

具体到zip文件里，TOC是放在文件尾部的一张表，里面列出了zip包中每一个文件的属性（文件名、长度等）和在zip包中的存放位置。如果需要随机访问zip包中的某一个文件，只需在TOC里找到这个文件的存放位置，直接跳过去即可。

而RAR文件里则没有TOC，在文件头之后所有文件按顺序连续存放。

这种差异造成的结果就是：随机访问时zip比rar快，而顺序访问时rar比zip快。

所谓随机访问，就是前面说过的随机访问压缩包中某个指定的文件。举一个简单的例子：一本反编译或下载到的网页电子书，有大量HTML、图像、css、js，然后打成压缩包。现在要求在不解包的情况下访问其中的页面：可以想象，打开每个HTML页面的时候，它所附带的图像、css、js等文件可能随机分布在整个压缩包里，如果没有TOC，查找每个文件的时候都要从头开始找，将会有多慢。 所以各位可以理解为什么jar包就是标准zip包，而我也只用zip格式保存反编译出来的电子书、漫画、PDG书等一切可能需要随机访问的东西。

所谓顺序访问，就是将整个压缩包从头解到尾。在这方面RAR具有天然的优势。而且为了节省WinRAR列文件的时间，对于单个RAR我一般都直接通过右键菜单解压缩，很少双击压缩包打开再解压。

由于rar的原作者已经去世，造成这种差异的确切原因我相信已不可考，但我个人猜测可能与DOS时代的备份软件之争有关：在DOS时代，电脑硬盘不像现在这样奢侈，20MB就算很大了。这样的容量用两盒软盘 即可备份，备份成本相对数据本身的价值来说非常低廉。因此在DOS时代，很多公司和机构都制定有定期硬盘备份政策，以免因为人为或非人为的因素 （早期硬盘可没有如今可靠）而造成不可挽回的数据损失。在备份软件方面，虽然微软已经随DOS提供了BackupRestore工具，但是他们基本不具备数据压缩能力，因此在压缩软件中提供备份功能，就成为DOS时代的一个时尚。由于DOS时代的备份介质多为软盘，因此压缩 软件的备份功能其实就转化成如今很常见的一个功能：分卷压缩功能，即按照软盘容量进行分卷压缩，然后将分卷压缩文件备份（Backup）到软盘，需要的时候再解压，或恢复（Restore）到硬盘。

DOS时代最有名的zip工具是pkzip，出现得比DOS版的RAR早。在分卷压缩时，pkzip按照zip文件规范，将TOC存放在最后，即存储在最后一卷，由此带来如下问题：

1、恢复时，每解压一张盘，都要先将最后一张盘插进去一次，读一次TOC。
2、只要最后一张盘上的TOC坏了，就算其它盘都是好的，也不能正常解压。

这两个缺点，尤其是第一个缺点实在是太臭名昭着了，因此当时出现了非常强烈的改革呼声。在这个关键时刻，DOS版的RAR出现了：不仅压缩率比pkzip高（这点在DOS时代非常重要，毕竟软盘又贵容量又小），而且由于吸取了当时对zip格式的批评，取消了TOC，因此：

1、在恢复分卷压缩的备份文件时，不需要频繁插入带有TOC的分卷，按顺序换盘即可。
2、即使某个分卷损坏，也可以跳过，从完好的分卷再开始解压。

由于这些原因（当然还有其它原因），RAR推出后迅速取得了成功，pkzip在DOS时代就开始流失用户，到Windows时代基本消声匿迹。在Windows时代推出的Winzip，则彻底放弃了分卷压缩功能（zip格式永远的痛？）。 而从我看到的源自WinRAR的UnRAR源代码来看，现在WinRAR的解压思路明显还是把文件按顺序从头解到尾，看来当年备份恢复工具之争的影响，还真是深远。

二、固实（solid）压缩方式

在压缩算法方面，我觉得rar格式最特色的是固实（solid）压缩方式。WinRAR v3.42的帮助文件中对固实压缩的说明如下：

固实压缩文件是 RAR 的一种特殊压缩方式存储的压缩文件，它把压缩文件中的全部文件都当成一个连续数据流来看待。

这段说明其实揭示了固实压缩格式能够提高压缩比的奥秘：数据压缩的基础是“重复”，例如aaaabbb这个字符串，里面就有重复，如果表示为a4b3，看起来是不是变短了？这就是“数据压缩”。“重复”是一个具有相对意义的概念，在某一范围内看起来没有重复，或重复不多的数据，把范围扩大，说不定就能找到更多重复的数据了，这就是固实压缩的奥秘。

举一个简单的例子：用zip和普通rar压缩一堆jpg文件，很难压下去，但是用固实压缩方式的rar就可以，其原因就在于：jpg文件本身已经是压缩格式了，单个jpg文件里很难再 找到可利用的重复数据，因此不论是用zip还是普通的rar都很难再压缩，因为他们都将需要压缩的文件分隔开来一个一个处理。但是对于固实rar来说，是将 所有需要压缩的jpg文件当作一个整体来压缩，这些jpg之间就存在重复的数据，如他们都有相同的文件头（其中包括各种数据表）等，这就出现了可压缩的空间。从我看到的资料来看，Flash文件也采用了类似的技术对jpg进行压缩：如果在Flash文件中使用了多个jpg文件，它们可以共用一个文件头。

当然天下不会有白吃的午餐，固实压缩方式在提高压缩比的同时，也有一些限制，在WinRAR v3.42帮助文件中的说法是：

固实压缩可增加压缩性能，特别是在添加大量的小文件的时候，但它也有一些重要的不利因素

对已存在的固实压缩文件更新时较慢；
要从固实的压缩文件解压单个文件时，它之前的文件都需先经过分析。这造成当从固实的压缩文件内取出文件时会比一般压缩文件取出文件慢一些。但是，当从固实的压缩文件解压全部的文件时，解压速度并没有影响。
如果在固实压缩文件中的任何文件损坏了，要从损坏的范围中解压全部的文件是不可能的。因此，如果固实压缩文件是保存在例如软盘等媒介时，推荐你在制作时使用“恢复记录”。
固实压缩的适用场合为

压缩文件很少更新的时候;
不需要经常从压缩文件中解压一个文件或是部分文件的时候;
压缩效率比压缩速度更为重要的时候。
与前面说的“随机访问”对应，固实压缩的RAR文件可能是世界上最不适合随机访问的：如果需要访问固实RAR包中的某个文件，就要从文件头开始解压，一直解到这个文件。

三、安全性

这里的安全性包含几个方面的含义：文件系统安全性、密码保护安全性和文件数据安全性。

由于制订zip格式规范的时候操作系统本身的文件安全性还没有引起足够的重视，因此zip格式只记录最基本的文件属性，包括只读属性等，没有其它附加的安全属性。

rar格式刚推出的时候，文件系统的安全性只能参照DOS，和zip差不多。但是rar毕竟是一种封闭的格式，想怎么改作者一个人说了就算，因此当Windows中出现NTFS，并且引入扩展的文件系统安全属性时，rar也积极跟进，所以现在应该说rar格式在这方面比zip强 。

在zip和rar格式中均提供了密码保护功能，但是密码保护的安全强度不同。

zip由于格式开放、代码开源，因此zip密码破解软件出现得比较早，也比较多。初期以暴力破解为主，威胁不大，真正对zip密码安全的致命一击是known plain text（已知明文）攻击法：如果知道加密zip文件中某段内容（密文，ciphertext）解密后的真正内容（明文，plain text），就可以反推出zip加密口令。在这种攻击方法的威胁，及某些国家的法律对密码技术的限制下， 着名开源组织zlib宣布永久放弃对加密zip的支持，详见zlib网站上的相关说明（不过在zlib发行的源代码里仔细找找，还是能找到原来的加解密相关代码）。

记得rar刚推出的时候也和zip一样，虽然不能列出加密文件中的文件内容，但可以列出加密文件中的文件名。后来大概也是被known plain text攻击法吓到了，增加了一个“加密文件名”选项，干脆连加密rar文件里有哪些文件都看不见，让攻击者想猜明文都无从猜起。

rar格式比zip晚推出，在安全方面吸取了足够的教训，因此采用的是美国国家标准与技术局（National Institute of Standard and Technology, NIST）推荐的、目前公认安全程度比较高的AES对称加密算法 ，密钥长度128位。在ASE被攻破以前（NIST认为30年内无法攻破），大家都只能在暴力法上兜圈子，所以密码安全性应该说比zip高。对此WinRAR 3.42的帮助文件是这样描述的：

ZIP 格式使用私有加密算法。 RAR 压缩文件使用更强大的 AES-128 标准加密。如果你需要加密重要的信息，选择 RAR 压缩文件格式会比较好一些。为了确实的安全性，密码长度请最少要 8 个字符。不要使用任何语言的单词作为密码，最好是任意的随机组合字符和数字，并且要注意密码的大小写。请记住，如果你遗失你的密码，你将无法取出加密的文件，就算是 WinRAR 的作者本身也无法解压加密过的文件。

在数据安全性方面，RAR格式本身支持一种特殊的附加信息类型，叫做“恢复记录”。如果RAR文件有恢复记录，在介质物理损坏或其它原因造成数据丢失时，WinRAR可以按照“恢复记录”尝试对数据进行修复。而zip格式无恢复记录，因此在数据安全性方面应该说比RAR弱。

虽然RAR文件本身支持恢复记录，但是在WinRAR里此选项缺省是关闭的，而打开后会导致压缩出来的RAR文件体积增加（增加的百分比与设置有关），可能会令某些人感到不习惯（我就亲眼见到有人在论坛上抱怨为什么压出来的RAR文件会如此庞大），所以这个功能基本上形同虚设。

四、开放性

开放性的对比很明显：zip格式不仅文件格式完全公开，而且有专门的开源组织提供操作源代码，跨平台使用也没有多大限制；rar格式完全保密，作者只提供解压所需源代码，不提供压缩所需源代码 ，跨平台使用有点麻烦。

zip开源组织中，最出名的是zlib和InfoZip，二者各有侧重：zlib偏重对内存缓冲区的压缩，因此被png等开源组织用做内部压缩算法，连java的jar程序内核都来自zlib，打出来的jar包自然也是一个标准的zip文件；InfoZip偏重对文件的操作 （包括口令保护），应用似乎不如zlib广泛，但我个人觉得其实它还是满好用的，前提是需要对它的源代码进行一些必要的修改。

在png组织的网页中有说到png格式的来历，我觉得也很有意思：做png的一班人，其实原来都是做gif格式的，但是由于Unisys公司开始对gif格式的核心——LZW压缩算法征收专利费，这帮人怒了，干脆提出png格式：大结构方面还是采用分段结构，但是核心压缩算法采用开源的zlib，压缩 效果在多数情况下比gif的LZW更强。由于没有版权限制，在静态图形领域png得到广泛应用，如果不是及时提出动画支持并因此在web上大行其道，我估计gif早就死掉了。

RAR的解压源代码在其官方网站www.rarlab.com上提供，通常比WinRAR的正式版本晚一点，不过据说是直接从WinRAR的源代码中抠出来的，所以兼容性应该没有什么问题。

五、结论

以下观点纯属个人观点，仅供参考，不具有如何指导意义：

如果经常需要对压缩包进行随机访问，应该选zip而不是rar。虽然将下载到的rar重新压缩成zip会麻烦一次，但是以后会减少无数的麻烦。
如果需要分卷压缩（如某些网站对上传文件大小有限制），则只能用rar。事实上，这也是我唯一会使用rar格式的场合，其它时候一律zip没商量。

‘捌’ 扩展名为“.rar”和“.zip”的压缩文件有什么不同

一、发明者不同

1、rar：是一种专利文件格式，用于数据压缩与归档打包，开发者为尤金·罗谢尔。

2、zip：是一种数据压缩和文档储存的文件格式，原名Deflate，发明者为菲尔·卡茨。

二、特点不同

1、rar：RAR通常情况比ZIP压缩比高，但压缩/解压缩速度较慢。分卷压缩：压缩后分割为多个文件。

2、zip：指出文件可以不经压缩或者使用不同的压缩算法来存储。然而，在实际上，ZIP几乎差不多总是在使用卡茨（Katz）的DEFLATE算法。

三、加密算法不同

1、rar：RAR 2.0使用AES-128-cbc，（rar5.0以后为AES-256CBC）。之前RAR的加密算法为私有。加入冗余数据用于修复，在压缩包本身损坏但恢复记录够多时可对损坏压缩包进行恢复。

2、zip：持基于对称加密系统的一个简单的密码，现在已知有严重的缺陷，已知明文攻击，字典攻击和暴力攻击。ZIP也支持分卷压缩。

‘玖’ zip、bzip、lzma和ZLib如果极限压缩的话，那种压缩率最高除这几种之外，还有没有压缩率更高的压缩方式

LZMA和ZLIB压缩测试：
输出结果：
zlib压缩:255ms size:5.08MB
zlib解压:12ms
lzma压缩:1974ms size:5.11MB
lzma解压:399ms
LZMA.AS解压:27381ms
这结果真让人大失所望，不知道是不是测试的有问题，没有更小，反而更大了。而且解压时间长了几十倍。as版的LZMA解压时间更是无法接受。还是继续用zlib吧。

ZLIB最高