C＃压缩文件反而变大？

Question

用C＃2.0中的两个压缩类压缩文件，文件反而变大
原文件大小 ： 14M  格式exe
GZipStream压缩后：22M
DeflateStream压缩后：22M
rar压缩后：14.4M但是DeflateStream和GZipStream压缩txt文件和doc文件一般会变小

Answer 1

exe这种格式的文件本身就无法再压缩了 不是所有格式文件都能再压缩设想 我们把一个.rar格式的东东压缩再压缩 岂不可以无限压缩了？

Answer 2

楼上的，你说的大家都知道，但是也不能14M 变成 22M吧？WinRar也不过是略微的有所变化，它压缩exe一般都是14M变成13M左右而已。

Answer 3

WinRar压缩.net的程序，压缩比甚至在1/3左右，所以真的如搂住所说，就确实不正常了。建议试验用Winrar压缩后进行比较大小

Answer 4

GZipStream
DeflateStream 有点基于base64的加密  变大很正常

Answer 5

你写一个只有一个字节（或者一个字节也没有）的文本文件，再用winrar压缩一下，你看看压缩后的体积变大多少倍。

Answer 6

具体算法我没研究过，但我知道压缩的大概原理
只有存在大量重复信息的数据文件才有可能被压缩
给你举个通俗的例子
比如某片区域是00000000000000000000，可以用"20个0"来替换
长度缩短了；
但如果是00，用"2个0"来替换反而会变长
Exe文件本身存放的是可执行指令，他的0与1很少有大量重复
加上压缩算法附加的标志信息，当然会变大
rar变大的比较小，是因为他是一个成熟的软件，经过很多年发展、改进了
考虑得比较周到~

Answer 7

zip格式的确压缩率不高
没有rar, ace, 7z来得高

Answer 8

soaringbird，不要混淆概念——你能说1岁和2岁的孩子差一倍的年龄？？普通0字节和100字节，不能算100倍吧？但是如果10M压缩成了20M——我只是说这种压缩比说不过去，知道么？假如变成12、14也只是说它没有压缩成功，略微增大了，但是也不能弄个10 To 20吧？基数不同的时候——是不一样的。

Answer 9

你写一个只有一个字节（或者一个字节也没有）的文本文件，再用winrar压缩一下，你看看压缩后的体积变大多少倍。
------你这属于胡搅蛮缠，谁吃多了去压缩一个字节的文件？？你不知道winrar文件的文件头就有近一百个字节？？把文件头一去掉，真正经过压缩的数据不会变大。

Answer 10

//-----一个算法动不动就把文件压缩成以前的两倍，我还真没觉得这个算法有什么利用价值
什么叫动不动？
难道rar压缩的1.x倍就有价值？我不知道有何价值请解释！问题的根源在于你就不该企图去压缩一个Exe文件！

Answer 11

赞同viena(维也纳N02) 的说法，如果楼主真的有时间可以研究rar的算法公式，然后再根据你自己文件中0、1的分布手工算一次，这样就会很清楚了。压缩后变大很正常，至于变大了多少需要参考文件的结构。

Answer 12

//问题的根源在于你就不该企图去压缩一个Exe文件！难道你保证所有的“用户”都和你一样精通“算法”？把2个以上的exe压缩，并不是仅仅是为了体积的缩小吧？？——而是为了发送和传递便捷。而且不是因为我们写不出来高效而又压缩比高的算法就没有权利质疑它的问题吧？敢问，你不会下蛋，就不可以批评某种鸡蛋不好吃？？这是什么逻辑阿？？现在大家探讨的是，能把10M压缩成20M的算法的合理性。——难道算法有问题，大家因为自己不能写算法，就要睁一眼闭一眼？？所以站着说话不腰疼的肯定不是有反对意见的人。============================================================================
viena——大家都是探讨技术，希望不要生气，就是就事论事而已。能得到三个星星说明你很能帮助别人，也希望你有和技术一样宽广的胸怀。

Answer 13

弄个exe减肥的工具试试吧基于字典的压缩算法，需要将字典数据放在压缩文件中，某些情况下会变大,并不奇怪

Answer 14

lovingkiss(坦白从良 抗拒强奸) 我觉得你的态度有问题，要讨论算法就好好讨论，不用说那些无聊的比喻。

Answer 15

//把2个以上的exe压缩，并不是仅仅是为了体积的缩小吧？？——而是为了发送和传递便捷
那你需要的是文件连接与拆分，而不是压缩，根本不用什么算法
开辟缓冲区读写就可以了

Answer 16

suliang1984——1984，呵呵~~争论也好，拍砖也好，无外乎想表达清楚自己的观点，只要不是恶意相向，何来无聊比喻~~算了，彼此有代沟，就别切磋了。//viena，不过压缩比为2：1，也是不争的事实，大家就不要探讨了，基本上大家对压缩都了解，对算法也都清楚，唯一的看法就是一个觉得好，一个觉得不好，争下去没有意义了。仁者见仁智者见智吧。呵呵~~

Answer 17

to lovingkiss(坦白从良 抗拒强奸)：但是在我眼里，你是一个开发者，而不是所谓的“用户”
换句话说，你是下蛋的，而不是吃蛋的rar是一个成熟的软件，它是给用户用的
而你的程序中用到的算法或者代码，是另外一回事
任何算法都是半成品而非一个软件，都只能解决某一方面的问题
如果你觉得你选的算法不适合你用，你可以换一个，或者自己写一个
完全没必要在这里唧唧歪歪那两个确实比rar差，但又怎么样呢？
你为什么不拿你写的软件与顶级高手写的同类软件去对比呢？
因为你知道这种对比没有意义~

Answer 18

to viena：
你说的对，但是你忘记了一点，你的软件是给用户用的，不是给自己用的
而且你确实是下蛋的，不是吃蛋的，只是你下蛋的方法——是现成的算法。
但是你不是最终用户，最终用户是不懂算法优劣的，他只是知道你的算法
让他的文件从10M变成了20M，你却有口难辩，你总不能对他们说
算了，别用我的压缩了，用Rar吧，他比我成熟

Answer 19

lovingkiss(坦白从良 抗拒强奸) 很遗憾，我只能说你没看懂我的话，思维没有逻辑？
我的软件是给用户用的，但是我会用适合我的算法，
如果实在没有，或者写不出来，我会转换思路，试试别的途径，
而不是非要异想天开的非要强求某个算法能达到rar的水平，
如果你能做到，你完全可以用.NET写一个rar出来了
两个字，可笑~

Answer 20

lovingkiss(坦白从良 抗拒强奸) 我总觉得你有点钻牛脚尖，rar是用于有必要使用压缩的用户的，其实程序完全可以遍历待压缩对象的结构，然后评估是否符合压缩的规格，但这样有必要么？

Answer 21

viena我更遗憾——你偷换了概念，而且纠缠不休，白瞎了你的三个星星
我没有“强求某个算法能达到rar的水平”，你的明白？？
我只是对一个压缩算法把10M弄成20M表示质疑而已，你的明白？？真的明白？？
我看你没明白！！——我根本没用到这个算法，看清楚了我不是楼主。质疑 ：
zhì yí 
对某件事情或事物表示怀疑  不知所谓，还可笑！！为了争辩而争辩来体现自己的能力？？有意义么？suliang1984
大家不是一个层面上的，没有讨论的必要。

Answer 22

说你偷换概念还别不服气~~你那只眼睛看到我要求压缩和Rar一样了？？
怎么叫适合自己的算法？？——白痴都知道，10M压缩成了20M的算法不能用。还愣要给别人扣帽子...

Answer 23

呵呵，RAR的是专利算法……如果你喜欢，可以找RAR的作者问问授权费……虽然说压缩后变大这么多有些离谱，但是既然是免费的你就忍忍吧……

Answer 24

不好意思，把你当成了楼主
但你也看清楚了，楼主说的并不是10M弄成20M
但我认为你的质疑是没有必要的我是冲zhouhongyun(最终幻想)的那句话
而不是你的质疑
相反我倒认为是你在纠缠不休

Answer 25

增大了近乎一倍，只能说这种算法不适用于exe文件，
而且试图压缩exe文件本身就不应该
你的质疑没有意义

Answer 26

原文件大小 ： 14M  
GZipStream压缩后：22M
DeflateStream压缩后：22M有所差别？呵呵，算了，NND，咱两个吵啥啊~~一点意义都没有
不说了，呵呵，再说大家都不用吃晚饭了。

Answer 27

//白痴都知道，10M压缩成了20M的算法不能用那你说14M压缩成了14.4M的rar能不能用？白痴知不知道？

Answer 28

我还真想知道winrar压缩什么文件能从14M压缩到14.4M,我连续试了几个EXE文件，都有不同程度的缩小，电驴从3.35M压缩到2.71M,迅雷从3.62M压缩到2.87M，这样的压缩率不是没实用价值吧？？把文件越压越大，我还真没见过这种情况

Answer 29

winrar实验了一下，exe文件基本大小不变
13249544——>压缩后13299704，确实大了100多个字节，但是去掉Rar必然的文件头，
似乎没有变大。

Answer 30

我左眼右眼都看到了，且看如下：//很遗憾，我只能说你没看懂我的话，思维没有逻辑？
——首先说我思维没有逻辑
//如果你能做到，你完全可以用.NET写一个rar出来了
——其次，鄙视我的能力，虽然我确实写不出来，相信你也写不出来，大家半斤八两，虽然你三个星星。
两个字，可笑~
——嘲笑这件事情的可笑，一个巴掌拍不响，可笑也是你我两个人阿

Answer 31

不是所有的EXE都不可以压缩吧？一般来说编译出来的EXE都是可以被压缩地：）至于原因还用说么？不过对于把一个EXE从10M压到20M，确实是有点极端

Answer 32

为何要质疑呢？单单因为他将exe压缩后变大了近一倍 就要去否定它么？

Answer 33

/*
不是所有的EXE都不可以压缩吧？
一般来说编译出来的EXE都是可以被压缩地：）至于原因还用说么？
*/
那可不一定，具体要看EXE的内容了，如果它本身包含数据，比如资源文件
就与纯EXE文件不一样，
如果EXE文件内部不包含任何数据的话(完全无序)
压缩结果必然是增大无疑的

Answer 34

//没用的石头？？——这似乎是我的观点阿，我质疑的就是它的没用阿。
你理解错了，我的意思是你不该去压缩一个exe文件，是这种做法不应该而不是这个算法没用

Answer 35

压缩exe文件就是象买石头一样可笑，你再去评价石头的大小当然也可笑

Answer 36

如果EXE文件内部不包含任何数据的话(完全无序)
压缩结果必然是增大无疑的
------你用winrar压缩一个EXE文件看看，看怎么个增大无疑法

Answer 37

压缩exe——也不是所有的都不可以压缩，拜托你搞清楚了，不信的话你去压缩一下.Net生成的exe，压缩比可以在1/3左右，部分安装程序已经优化过了，压缩比在1:1左右你能说压缩exe完全无用？？

Answer 38

=================================
=================================
=================================
=================================
拜托，大部分的exe是可以被压缩的！
=================================
=================================
=================================
=================================

Answer 39

绝大部分的exe是可以被压缩的！

Answer 40

jiatong1981，关键石头进去了一个，出来了两个，哈哈

Answer 41

我说的理想的状态，但EXE文件内部一般都回包含数据的
但是你不能否认，压缩后变大是可能的
如果压缩的结果可能是变大，这种压缩还有意义吗？

Answer 42

拜托，难道EXE就是.NET的程序集吗？
你用VC Delphi VB 等等等等任何可以生成本地代码的编译个Exe再压缩看看

Answer 43

你用VC Delphi VB 等等等等任何可以生成本地代码的编译个Exe再压缩看看
------你完全可以自己试一下再发言，我已经试了很多VC编译的EXE，还真吓了一跳，平均压缩比达到1/3

Answer 44

//是没意义，不过文件变大两倍就不是意义的问题了，而是会不会挨砖头的问题
我说的是rar，既然用rar(或者你找一个比rar强的试试)压缩exe都没有意义，
结论是压缩exe没有意义，
那么文件是否变大两倍或更多倍又怎样呢？
有意义吗？

Answer 45

=================================
=================================
=================================
=================================
拜托，除了VC的我没有实验！我这里没有VC
其他的exe是可以被压缩的！而且VB的最高，基本上都是1/3的压缩比
你能不能试验之后再和我说啊。
不能压缩的大多数都是安装程序——也就是本身都压缩过的那种exe
=================================
=================================
=================================
=================================

Answer 46

你不做实验——光凭着三寸不烂之舌吵架，能不被砸么？？你可以试验之后再说——也少挨几个砖头，虽然我没有做VC的试验。Vb、Dephi、Pb、.Net的几种都是可以压缩的，大部分都保持在1/3的压缩比
已经不少了，1M的剩下300k，你还能说exe不可以被压缩么？？

Answer 47

我不知道你用的什么样的EXE，但是楼主用rar压缩的EXE确实变大了总是事实吧~

Answer 48

zhouhongyun(最终幻想)也实验了VC，看样子常见的开发工具都齐全了——别告诉我你的exe专指打包压缩后的exe

Answer 49

//楼主用rar压缩的EXE确实变大了总是事实吧~你验证过？？没有吧？？我验证过，而且是大量的试验，我有发言权。
但是我也不是无懈可击，因为我没有验证他说的2倍压缩比的算法。——但是庆幸的是
我质疑的只是“如果”这个比例存在，那么这个算法的可行性而已。

Answer 50

windows应用程序只是Exe中的一部分，即使你做了很多试验，不等于就代表了大多数可能的情况

Answer 51

我不是不去做试验，我这儿真正的Exe程序只有.NET的，其他的都没有
建一个空项目编译的话似乎不具有代表性~

Answer 52

Delphi exe问题偶一直使用delphi开发，刚刚做的测试就是压缩DELPHI程序。仅仅是一个空的FORM而已，一样可以被压缩：）

Answer 53

不是特意的换帐户，CSDN不让过多发言//我不是不去做试验，我这儿真正的Exe程序只有.NET的，其他的都没有
我崩溃，打死我都不信，你操作系统里面会只有.net的exe？你计算机除了开发工具还有没有应用软件？？——不要给自己的懒惰找理由。//建一个空项目编译的话似乎不具有代表性~
我压缩的没有一个是空项目编译的——我这里碰巧有好多种语言编辑的应用程序，所以就一并试验了。基本上保证1/3的压缩比（安装类的程序除外），这点你不用置疑，你可以去试验，或者我可以截图给你，我绝对不会为了拍你而造假，那就真的违背了探讨技术的初衷了。我也希望自己找到个例，可惜，没有找到。//大量的试验能说明什么呢？你穷尽了所有的可能情况了吗？
你不觉得自己太过强词夺理么？？我做了大量的试验去验证，你什么都不作还让我们去穷尽这个。我总不能吃过所有的鸡蛋才敢说鸡蛋带壳吧？？你说得话让我想起一个笑话
就是那个把所有火柴都划着了，然后告诉妈妈，所有的都好用的孩子。
========================================================
不要总咬着什么什么硬犟，给个麻花都不干啊——你总要拿出证据啊？？
你一个证据都没有，然后就说我们的论证不够多，是不是有些霸道呢？
有些时候，不是星星多就可以了啊~~~~~~~惹火了，明天我去弄个太阳。
========================================================
我们都有同样的爱好——争论，也就是所谓的拍砖。黔驴技穷也是开玩笑的，扯不上什么人身攻击啊。真是的，你要觉得我说得过分了，那为了这个驴俺向嫩道歉——但是争论并不会认输。

Answer 54

我承认Windows程序exe是可以压缩的
不过在我的印象里，exe是没法压缩的，是dos时代打下的烙印但是要注意，我承认这句话说错了，不等于认同你们的说法~

Answer 55

Windows程序，动辄几百K，甚至上M，里面不可能全部是计算机指令
我说的exe是指只包含指令而不包含任何数据的理想情况~

Answer 56

还是不要争了，争也不要言辞过激。zip算法不如rar算法优秀是一个事实，不光压缩exe，就是压缩文本文件也比rar差一大截呢。
.net的gzipstream采用的子算法更是差劲。
在.Net上可以用的压缩库还有SharpZipLib，支持多种压缩算法（没有rar）,比VS自带的效果要好些，但还是比不上rar。

Answer 57

这年头抓住三星用户小尾巴，可不容易那——千万别放手阿。
//Windows程序，动辄几百K，甚至上M，里面不可能全部是计算机指令
//我说的exe是指只包含指令而不包含任何数据的理想情况~我也是从Dos走过来的，你说得我理解，但是即便是最底层的C写出来的，直接进行汇编的。也不可能只包含指令而不包含任何数据的，它编译后的体积一般是直接汇编的2倍，多出来的，怎么可能全是指令？？难道它没事自己堆栈玩儿么？再退1万步讲，就是当年的MSC51的汇编，基本上你要做一个硬件系统，也不可能不开辟数据空间的。至少你要有打印之类的字符对照表之类的，因为那时候的汇编，大多数也只能放在程序当中的。别告诉我你只是用汇编来做一个小时钟。。，那个东西用个晶振就OK的，当然不会有数据。
============================================
我喜欢吵架，也喜欢较真——一定要全歼阿~~~~~~~~~~~~~