来自子话题：
你的想法很好，软件业就缺你这样有创造性思维的人才&br&&br&按照你的想法压缩下去之后，最终成为1 byte也就是8 bit，然后成为1 bit也就是1位。1位有两个状态，进一步压缩成一个状态，一个状态毋需表示，所以也就不用存储了。&br&看到没有，这就是逆向的道德经，万物成8卦，8成2，2成1，1从有到无。&br&&br&可惜，世人都不理解大道。&br&&br&因为他们还没找到解压的办法。
你的想法很好，软件业就缺你这样有创造性思维的人才按照你的想法压缩下去之后，最终成为1 byte也就是8 bit，然后成为1 bit也就是1位。1位有两个状态，进一步压缩成一个状态，一个状态毋需表示，所以也就不用存储了。看到没有，这就是逆向的道德经，万物成8…
简要概述原理：&br&每个文件都由各种不同代码组成，比如01代码。这类文件只有数字0与1组合。&br&压缩原理就是 【&b&通过寻找其中的规律，简化数字的排列】&/b&。&br&比如&br&&br&可以简化成&br&5个0,2个1,3个0,10个1的排列&br&&br&可以简化成数学的&br&10^10&br&&br&至于&a class=&member_mention& data-editable=&true& data-title=&@yskin& data-hash=&ed1e73e8adefb& href=&///people/ed1e73e8adefb& data-tip=&p$b$ed1e73e8adefb&&@yskin&/a& 说 没见过2G压缩到十几兆的。&br&实际上在极限压缩方式下其实28.1G压到25.8M都可以。&br&&img src=&/ddb047cc04dd66e2a43900_b.jpg& data-rawwidth=&773& data-rawheight=&235& class=&origin_image zh-lightbox-thumb& width=&773& data-original=&/ddb047cc04dd66e2a43900_r.jpg&&附下载&br&&a href=&///?target=http%3A///share/link%3Fshareid%3Duk%3D& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&2^31-1 [AviSynth 16x16 60.000fps AVC-Lossless-yuv420p8]&i class=&icon-external&&&/i&&/a&&br&&br&打开看后基本都能理解这个压缩的大概原理了。&br&&br&&br&下面是几种常见文件压缩算法原理介绍：&br&&br&字典算法&br&&br&字典算法是最为简单的压缩算法之一。它是把文本中出现频率比较多的单词或词汇组合做成一个对应的字典列表，并用特殊代码来表示这个单词或词汇。例如：&br&有字典列表：&br&00=Chinese&br&01=People&br&02=China&br&源文本：I am a Chinese people,I am from China 压缩后的编码为：I am a 00 01,I am from 02。压缩编码后的长度显著缩小，这样的编码在SLG游戏等专有名词比较多的游戏中比较容易出现，比如《SD高达》。&br&----------------------------------------------------------------------------------------------------------------------&br&固定位长算法（Fixed Bit Length Packing）&br&&br&这种算法是把文本用需要的最少的位来进行压缩编码。&br&比 如八个十六进制数：1，2，3，4，5，6，7，8。转换为二进制为：000100， 001000。每个数只用到了低4位，而高4位没有用到（全为0），因此对低4位进行压缩编 码后得到：，，，。然后补充为字节得到：， 111000。所以原来的八个十六进制数缩短了一半，得到4个十六进制数：12，34，56，78。&br&这也是比较常见的压缩算法之一。&br&------------------------------------------------------------------------------------------------------------&br&RLE（Run Length Encoding）&br&&br&是一个针对无损压缩的非常简单的算法。它用重复字节和重复的次数来简单描述来代替重复的字节。尽管简单并且对于通常的压缩非常低效，但它有的时候却非常有用（例如，JPEG就使用它）。&br&&img src=&/9e38cefc796_b.jpg& data-rawwidth=&466& data-rawheight=&168& class=&origin_image zh-lightbox-thumb& width=&466& data-original=&/9e38cefc796_r.jpg&&原理图2.1显示了一个如何使用RLE算法来对一个数据流编码的例子，其中出现六次的符号‘93’已经用3个字节来代替：一个标记字节（‘0’在本例中）重复的次数（‘6’）和符号本身（‘93’）。RLE解码器遇到符号‘0’的时候，它表明后面的两个字节决定了需要输出哪个符号以及输出多少次。&br&&br&&br&&p&这种压缩编码是一种变长的编码，RLE根据文本不同的具体情况会有不同的压缩编码变体与之相适应，以产生更大的压缩比率。&/p&&p&　　变体1：重复次数+字符&br&文本字符串：A A A B B B C C C C D D D D，编码后得到：3 A 3 B 4 C 4 D。&/p&&p&　　变体2：特殊字符+重复次数+字符&br&文本字符串：A A A A A B C C C C B C C C，编码后得到：B B 5 A B B 4 C B B 3 C。编码串的最开始说明特殊字符B，以后B后面跟着的数字就表示出重复的次数。&/p&&p&　　变体3：把文本每个字节分组成块，每个字符最多重复 127 次。每个块以一个特殊字节开头。那个特殊字节的第 7 位如果被置位，那么剩下的7位数值就是后面的字符的重复次数。如果第 7 位没有被置位，那么剩下 7 位就是后面没有被压缩的字符的数量。例如：文本字符串：A A A A A B C D E F F F。编码后得到：85 A 4 B C D E 83 F（85H= B、4H= B、83H= B）&/p&&br&&br&实现RLE可以使用很多不同的方法。基本压缩库中详细实现的方式是非常有效的一个。一个特殊的标记字节用来指示重复节的开始，而不是对于重复非重复节都coding run。&br&因此非重复节可以有任意长度而不被控制字节打断，除非指定的标记字节出现在非重复节（顶多以两个字节来编码）的稀有情况下。为了最优化效率，标记字节应该是输入流中最少出现的符号（或许就不存在）。&br&重复runs能够在32768字节的时候运转。少于129字节的要求3个字节编码（标记+次数+符号），而大雨128字节要求四个字节（标记+次数的高4位|0x80+次数的低4位）。这是通常所有采用的压缩的做法，并且也是相比较三个字节固定编码（允许使用3个字节来编码256个字节）而言非常少见的有损压缩率的方法。&br&在这种模式下，最坏的压缩结果是：&br&输出大小=257/256*输入大小+1&br&&br&其他还有很多很多变体算法，这些算法在Winzip Winrar这些软件中也是经常用到的。&br&----------------------------------------------------------------------------------------------------------------&br&霍夫曼编码（Huffman Encoding）&br&&br&哈夫曼编码是无损压缩当中最好的方法。它使用预先二进制描述来替换每个符号，长度由特殊符号出现的频率决定。常见的符号需要很少的位来表示，而不常见的符号需要很多为来表示。&br&哈夫曼算法在改变任何符号二进制编码引起少量密集表现方面是最佳的。然而，它并不处理符号的顺序和重复或序号的序列。&br&&br&原理我不打算探究哈夫曼编码的所有实际的细节，但基本的原理是为每个符号找到新的二进制表示，从而通常符号使用很少的位，不常见的符号使用较多的位。&br&简短的说，这个问题的解决方案是为了查找每个符号的通用程度，我们建立一个未压缩数据的柱状图；通过递归拆分这个柱状图为两部分来创建一个二叉树，每个递归的一半应该和另一半具有同样的权（权是∑NK =1符号数k, N是分之中符号的数量，符号数k是符号k出现的次数）&br&这棵树有两个目的：&br&1．
编码器使用这棵树来找到每个符号最优的表示方法&br&2．
解码器使用这棵树唯一的标识在压缩流中每个编码的开始和结束，其通过在读压缩数据位的时候自顶向底的遍历树，选择基于数据流中的每个独立位的分支，一旦一个到达叶子节点，解码器知道一个完整的编码已经读出来了。&br&&img src=&/0cbc64816b07b_b.jpg& data-rawwidth=&551& data-rawheight=&89& class=&origin_image zh-lightbox-thumb& width=&551& data-original=&/0cbc64816b07b_r.jpg&&我们来看一个例子会让我们更清楚。图2.2显示了一个10个字节的未压缩的数据。&br&根据符号频率，哈夫曼编码器生成哈夫曼树（图2.4）和相应的编码表示（图2.3）。&br&&img src=&/aebd5e7599_b.jpg& data-rawwidth=&553& data-rawheight=&215& class=&origin_image zh-lightbox-thumb& width=&553& data-original=&/aebd5e7599_r.jpg&&&img src=&/433e9e82ec457e6e7d31b_b.jpg& data-rawwidth=&554& data-rawheight=&330& class=&origin_image zh-lightbox-thumb& width=&554& data-original=&/433e9e82ec457e6e7d31b_r.jpg&&&br&你可以看到，常见的符号接近根，因此只要少数位来表示。于是最终的压缩数据流如图2.5所示。&br&&img src=&/0ac26ddbbd9fe23c74d57b22f3e826fc_b.jpg& data-rawwidth=&487& data-rawheight=&88& class=&origin_image zh-lightbox-thumb& width=&487& data-original=&/0ac26ddbbd9fe23c74d57b22f3e826fc_r.jpg&&&br&&br&&br&压缩后的数据流是24位（三个字节），原来是80位（10个字节）。当然，我应该存储哈夫曼树，这样解码器就能够解码出对应的压缩流了，这就使得该例子中的真正数据流比输入的流数据量大。这是相对较短的数据上的副作用。对于大数据量来说，上面的哈夫曼树就不占太多比例了。解码的时候，从上到下遍历树，为压缩的流选择从左/右分支，每次碰到一个叶子节点的时候，就可以将对应的字节写到解压输出流中，然后再从根开始遍历。 实现哈夫曼编码器可以在基本压缩库中找到，其是非常直接的实现。&br&这个实现的基本缺陷是：&br&1．
慢位流实现&br&2．
相当慢的解码（比编码慢）&br&3．
最大的树深度是32（编码器在任何超过32位大小的时候退出）。如果我不是搞错的话，这是不可能的，除非输出的数据大于232字节。&br&&br&另一方面，这个实现有几个优点：&br&1．
哈夫曼树以一个紧密的形式每个符号要求12位（对于8位的符号）的方式存储，这意味着最大的头为384。&br&2．
编码相当容易理解&br&哈夫曼编码在数据有噪音的情况（不是有规律的，例如RLE）下非常好，这中情况下大多数基于字典方式的编码器都有问题。&br&3.
Rice对于由大word（例如：16或32位）组成的数据和教低的数据值，Rice编码能够获得较好的压缩比。音频和高动态变化的图像都是这种类型的数据，它们被某种预言预处理过（例如delta相邻的采样）。&br&尽管哈夫曼编码处理这种数据是最优的，却由于几个原因而不适合处理这种数据（例如：32位大小要求16GB的柱状图缓冲区来进行哈夫曼树编码）。因此一个比较动态的方式更适合由大word组成的数据。&br&&br&原理Rice编码背后的基本思想是尽可能的用较少的位来存储多个字（正像使用哈夫曼编码一样）。实际上，有人可能想到Rice是静态的哈夫曼编码（例如，编码不是由实际数据内容的统计信息决定，而是由小的值比高的值常见的假定决定）。&br&编码非常简单：将值X用X个‘1’位之后跟一个0位来表示。&br&&br&实现在基本压缩库针对Rice做了许多优化：&br&1．
每个字最没有意义的位被存储为k和最有意义的N-k位用Rice编码。K作为先前流中少许采样的位平均数。这是通常最好使用Rice编码的方法，隐藏噪音且对于动态变化的范围并不导致非常长的Rice编码。&br&2．
如果rice编码比固定的开端长，T，一个可选的编码：输出T个‘1’位，紧跟（log2(X-T)）个‘1’和一个‘0’位，接着是X-T（最没有意义的(log2(X-T))-1位）。这对于大值来说都是比较高效的代码并且阻止可笑的长Rice编码（最坏的情况，对于一个32位word单个Rice编码可能变成232位或512MB）。&br&如果开端是4，下面是结果编码表：&br&&b&X&/b&&br&&b&bin&/b&&br&&b&Rice&/b&&br&&b&Thresholded&/b&&br&&b&Rice&/b&&br&0&br&00000&br&0&br&0&br&&br&1&br&00001&br&10&br&10&br&&br&2&br&00010&br&110&br&110&br&&br&3&br&00011&br&1110&br&1110&br&&br&4&br&00100&br&11110&br&11110&br&&br&5&br&00101&br&111110&br&111110&br&&br&6&br&00110&br&1111110&br&&br&+1&br&7&br&00111&br&&br&&br&&br&8&br&01000&br&&br&&br&+1&br&9&br&01001&br&&br&&br&&br&10&br&01010&br&&br&&br&-1&br&11&br&01011&br&&br&&br&-2&br&12&br&01100&br&0&br&&br&&br&13&br&01101&br&10&br&&br&-1&br&14&br&01110&br&110&br&&br&-2&br&15&br&01111&br&1110&br&&br&-3&br&16&br&10000&br&11110&br&&br&-4&br&17&br&10001&br&111110&br&&br&-5&br&18&br&10010&br&1111110&br&&br&-6&br&19&br&10011&br&&br&&br&-7&br&20&br&10100&br&&br&00&br&-5&br&就像你看到的一样，在这个实现中使用threshold方法仅仅两个编码导致一个最坏的情况；剩下的编码产生比标准Rice编码还要短的编码。&br& 最坏的情况，输出。&br&&br&--------------------------------------------------------------------------------------------------------------&br& Lempel-Ziv (LZ77)&br&&br&Lempel-Ziv压缩模式有许多不同的变量。基本压缩库有清晰的LZ77算法的实现（Lempel-Ziv，1977），执行的很好，源代码也非常容易理解。&br&LZ编码器能用来通用目标的压缩，特别对于文本执行的很好。&br&它也在RLE和哈夫曼编码器（RLE，LZ，哈夫曼）中使用来大多数情况下获得更多的压缩。这个压缩算法是有版权的。&br&原理在LZ压缩算法的背后是使用RLE算法用先前出现的相同字节序列的引用来替代。&br&简单的讲，LZ算法被认为是字符串匹配的算法。例如：在一段文本中某字符串经常出现，并且可以通过前面文本中出现的字符串指针来表示。当然这个想法的前提是指针应该比字符串本身要短。&br&例如，在上一段短语“字符串”经常出现，可以将除第一个字符串之外的所有用第一个字符串引用来表示从而节省一些空间。&br&一个字符串引用通过下面的方式来表示：&br&1．
唯一的标记&br&2．
偏移数量&br&3.
字符串长度&br&由编码的模式决定引用是一个固定的或变动的长度。后面的情况经常是首选，因为它允许编码器用引用的大小来交换字符串的大小（例如，如果字符串相当长，增加引用的长度可能是值得的）。&br&&br&实现使用LZ77的一个问题是由于算法需要字符串匹配，对于每个输入流的单个字节，每个流中此字节前面的哪个字节都必须被作为字符串的开始从而尽可能的进行字符串匹配，这意味着算法非常慢。&br&另一个问题是为了最优化压缩而调整字符串引用的表示形式并不容易。例如，必须决定是否所有的引用和非压缩字节应该在压缩流中的字节边界发生。&br&基本压缩库使用一个清晰的实现来保证所有的符号和引用是字节对齐的，因此牺牲了压缩比率，并且字符串匹配程序并不是最优化的（没有缓存、历史缓冲区或提高速度的小技巧），这意味着程序非常慢。&br&另一方面，解压缩程序非常简单。&br&一个提高LZ77速度的试验已经进行了，这个试验中使用数组索引来加速字符串匹配的过程。然而，它还是比通常的压缩程序慢。&br&&br&当然静态数据和动态数据的压缩策略是完全不同的。&br&&br&一个压缩文件是不是还可以用其他算法再继续压缩？&br&可以，但没要。压缩文件有极限值存在。高压一遍已经很接近这个值了，再压缩的话基本也就只有一丁点压缩率提升，甚至会增加体积。&br&&img src=&/dd4c444f483cda88a68b9_b.jpg& data-rawwidth=&454& data-rawheight=&340& class=&origin_image zh-lightbox-thumb& width=&454& data-original=&/dd4c444f483cda88a68b9_r.jpg&&随便做的渣绘图。不要在意细节→ → &br&&br&————————————————————————————————————————&br&下面是题外话。&br&那么一般要如何简单实现高压缩？&br&系统文件诸如GAL游戏跟一些纯代码的文档基本能直接用 7Z 进行&b&无损压缩&/b&就可以了。当然，高压缩率也意味着更费时间的压缩跟解压。压缩率小的没必要用 7z，直接打包反而更适合。&br&影音图像文件多数压缩率只能通过再编码有损压缩。比如BMP图像转jpg 吧图片的一些一般人用不到的杂信息去除，APE转MP3之类。基本除了音源文件外其他要对比不太明显。(照片BMP通过7Z压缩后解压其实是有点变化的，这个不细说，一说就没完没了了。)&br&&br&&a href=&///?target=http%3A///html/3319.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/html/2013/0&/span&&span class=&invisible&&305/293319.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&→→至于有的人说我上面附带的极限压缩例子太坑爹，于是再附带一个我做的动画压制1080p BDMV 通过10bit x264再编码压缩成每话90M大小视频。源BDBOX总大小119.16GB。&br&画面的话我【个人主观看法】觉得在 电脑 观看跟源盘 没什么区别。(PS3跟一些高端硬件芯片的解码器播放那是另一回事了)&br&画面控追求的BDMV无损画质也是&b&相对无损&/b&。真正意义上的无损画质输出的影片，渲染体积1分钟视频就超过10G。我个人渲过最大的是18秒44.5G
8k视频。&br&&br&&br&参考资料&br&[1]&a href=&///?target=http%3A//linux.chinaunix.net/techdoc/system//935315.shtml& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&几种压缩算法原理介绍&i class=&icon-external&&&/i&&/a&
简要概述原理：每个文件都由各种不同代码组成，比如01代码。这类文件只有数字0与1组合。压缩原理就是 【通过寻找其中的规律，简化数字的排列】。比如可以简化成5个0,2个1,3个0,10个1的排列可以简化成数学的10^10至于…
来自子话题：
因为从理论上来讲，所有的信息如果想要表达一个特定地，不会有歧义的含义，在数学上都会有一个最小的「信息熵」（信息量）才可以。&br&&br&如果仅仅就理论来举个简单的例子的话，经典的连续数学理论会认为，如果用135胶卷相机拍出来的胶卷能冲洗出一张5寸的照片，而里面的所有细节都可以得到保留，那么我们在太空上对着地球用相机拍下一张胶片，然后想办法尽量将这张胶片放大，就可以看到天安门广场上的行人。&br&&br&你会认为这是玩笑是吗？事实上，用谷歌地球上的数据库，不就拼成了一张这样的照片么？但是其代价，绝不是一张胶片能包含的信息量，而是上百个TB的数据。&br&&br&这意味着什么？意味着信息的本质是离散而不是连续的，如果要想看出「地球是个圆的」，也许巴掌大的照片就够了，但是想要看到地球上更清晰的细节，则没有捷径可走，只有增加照片的信息量——换言之，信息量和能量一样，是守恒的。&br&&br&那么压缩文件的原理是什么？&br&&br&就是利用「&b&一个文件的体积与它的信息量并不相等，而且它的&/b&&b&体积&/b&&b&肯定要大于它的信息量&/b&」的特点，使用算法「&b&将一个文件所包含的同样的信息量用更少的容量来描述&/b&」。&br&&br&举个简单的例子，一张大小为 3x3 的图片是纯黑色的，那么我们用两种方法来描述这张图片：&ol&&li&这张图片是3x3的，且他们的颜色分布为：{纯黑色，纯黑色，纯黑色， 纯黑色，
纯黑色}&/li&&li&这张照片是3x3的，且它们的颜色全部是{纯黑色}&/li&&/ol&可以明显看出，第二种描述的方法比第一种描述的方法占用的空间（容量）要小得多。无损图像压缩算法中的「行程算法」就部分借鉴了这样的思想。&br&&br&再举一个例子，让我们来看看，在英语中为何会出现一种这样情况——使用频率越高的单词，其包含的字母越少，而使用频率越低的单词，其包含字母越多？&br&&br&比如说在 Elvis Costello 的一首歌《she》中（感谢 &a data-hash=&13bec2bfcf5f6b6eb2afc26& href=&///people/13bec2bfcf5f6b6eb2afc26& class=&member_mention& data-tip=&p$b$13bec2bfcf5f6b6eb2afc26&&@姚沛然&/a& 指出错误），我们把英语中的「&b&她&/b&（&b&she&/b&）」统一换成一个长一些的单词，比如说「&b&轻浮的女人&/b&（&b&flibbertigibbet&/b&，仅仅是随意找一个比较长的单词，并非故意「政治不正确」XD）」那么起后果就是这样的：&br&修改前：&blockquote&she may be the face I can't forget , a trace of pleasure I regret, may be my treasure or the price I have to pay she may be the song that Summer sings, may be the chill that autumn brings, may be a hundred different things, within the measure of the day. she may be the beauty or the beast, may be the famine or the feast, may turn each day into heaven or a hell, she may be the mirror of my dream
a smile reflected in a stream, she may not be what she may seem, inside her shell, she who always seems so happy'n proud, who's eyes can be so private and so proud, no one's allowed to see them when they cry, she may be the love that can and hope to last, may come to me from shadows of the past, that I remember till the day I die, she may be the reason I survive, the why and wherefor I'm alive the one I'll care for through the rough and rainy years, me I'll take her laughter and her tears, and make them all my souvenirs, for where she goes I got to be the meaning of my life is she she she &/blockquote&修改后：&blockquote&flibbertigibbet may be the face I can't forget , a trace of pleasure I regret, may be my treasure or the price I have to pay flibbertigibbet may be the song that Summer sings, may be the chill that autumn brings, may be a hundred different things, within the measure of the day. flibbertigibbet may be the beauty or the beast, may be the famine or the feast, may turn each day into heaven or a hell, flibbertigibbet may be the mirror of my dream
a smile reflected in a stream, flibbertigibbet may not be what flibbertigibbet may seem, inside her flibbertigibbetll, flibbertigibbet who always seems so happy'n proud, who's eyes can be so private and so proud, no one's allowed to see them when they cry, flibbertigibbet may be the love that can and hope to last, may come to me from shadows of the past, that I remember till the day I die, flibbertigibbet may be the reason I survive, the why and wherefor I'm alive the one I'll care for through the rough and rainy years, me I'll take her laughter and her tears, and make them all my souvenirs, for where flibbertigibbet goes I got to be the meaning of my life is flibbertigibbet flibbertigibbet flibbertigibbet &/blockquote&修改后与修改前的歌词相比，整整长了一行半。可是这两首歌词要表达的意思是一模一样的啊！那么用更短的字母来描述使用更频繁的含义是不是就意味着，这本书的厚度可以减少？你猜对了，这就是著名的无损压缩算法「霍夫曼编码」的基本原理。&br&&br&说了这么多，就是想解释一下，压缩算法只不过是想将「文件容量大于其所含信息量的那一部分」当成海绵中的水挤出来。但是总不能挤到连海绵都被挤消失的地步。你要问怎样判断一个文件的信息量有多少？一个粗略的解释就是，将所有计算机上的文件都看作是数学上0和1的排序的话，通过数学方法就可以计算出这个数列的有序度。这个有序度就是指不管采用什么办法，能够翻译出这组序列最少最少，需要一个多长的序列，才有实力做到这一点。具体如何计算嘛...略微复杂，有兴趣的同学还是去看看相关的资料叭
XD&br&&br&&b&P.S. @曹梦迪 的答案解释地非常形象到位，强烈推荐。&/b&
因为从理论上来讲，所有的信息如果想要表达一个特定地，不会有歧义的含义，在数学上都会有一个最小的「信息熵」（信息量）才可以。如果仅仅就理论来举个简单的例子的话，经典的连续数学理论会认为，如果用135胶卷相机拍出来的胶卷能冲洗出一张5寸的照片，而…
来自子话题：
如图,转自 @笛子Ocarina &a href=&///?target=http%3A///echohall& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/echohall&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&&br&&img src=&/c1f79fabdafef40c7e0047_b.jpg& data-rawwidth=&430& data-rawheight=&16834& class=&origin_image zh-lightbox-thumb& width=&430& data-original=&/c1f79fabdafef40c7e0047_r.jpg&&
如图,转自 @笛子Ocarina
gzip 只是一个流压缩程序，输入一个流，输出压缩后的数据流。给它一个文件，文件本身自然就是一个流，读入、压缩、输出，还是保存成一个文件，没有问题。然而，如果是一个文件夹、多个文件，该怎么办呢？按什么顺序？怎么存储文件以外的信息？（例如路径、权限。）操作系统没有提供一种可以把若干个文件组织成一个流的 API ，gzip 就无能为力。&br&&br&tar 则相反，它就是一个打包程序。天生就是为了处理打包多个文件的问题，它有专门的 manifest 来存储一些 metadata ，包括包里有什么文件、（相对）路径是什么、在包里的偏移量是什么……不过，它（最早）没有压缩功能。&br&&br&想要打包多个文件，很简单，先 tar 再 gzip ，一个管道就搞定了。后缀名自然而然就是 .tar.gz 了。&br&&br&以上说的都是历史上最早的 UNIX 工具。这些工具的设计很好地体现了 UNIX 一个工具只做一件事情、使用管道组合多个工具的思想。&br&&br&当然，到了后来，大家也都觉得这样很麻烦，而且这个功能太过常用了。所以 GNU 项目在复刻 UNIX tar 的时候，选择了把各种常用的压缩解压都集成进 tar （详见下段），然后提供了一套（丧心病狂的）命令行参数，现在一条命令就可以完成打包加压缩了。解压也是一样，使用 GNU 的 tar 的话，一条命令就可以自动完成压缩加解包，不需要先 gunzip 。&br&&br&关于 tar 调用其他压缩解压程序，之前误以为是链接了 zlib 、 bzip2 等等这些库，然而只需要简单的 ldd `which tar` 或者看各个发行版里 tar 软件包的依赖信息，就可以知道事情并非如此。 tar 的依赖仍然是非常少的。而压缩解压其实仍然是通过管道调用了这些独立的外部程序来实现的。这可以通过看 tar 的源代码、看 tar 二进制里的 strings （有很多常见压缩解压程序的命令名）、或者看压缩解压时的进程来发现。感谢 &a class=&member_mention& href=&///people/bde9fd95b27ab643e42329& data-hash=&bde9fd95b27ab643e42329& data-tip=&p$b$bde9fd95b27ab643e42329&&@王铭烨 Arthur2e5&/a& 指出。&br&&br&最后，其实现代的 GNU tar 是有一套根据扩展名自动识别压缩算法的机制的，免去了手动通过参数指定压缩算法的麻烦。压缩时使用 tar caf ，解压时使用 tar xaf 即可。其中 a 表示自动检测，这个 a 也可以省略，然而个人还是习惯输入——因为如果万一某个地方的 tar 版本不支持自动检测，你至少还能得到一个警告，否则 tar cf 的话最后可能建立了一个 foo.tar.gz 的没有压缩的 tar 包……
gzip 只是一个流压缩程序，输入一个流，输出压缩后的数据流。给它一个文件，文件本身自然就是一个流，读入、压缩、输出，还是保存成一个文件，没有问题。然而，如果是一个文件夹、多个文件，该怎么办呢？按什么顺序？怎么存储文件以外的信息？（例如路径、…
来自子话题：
前几天占楼，现在到了周末终于有时间来更新一番。&br&&br&为了回答楼主的问题，我们先从图像压缩说起。&br&&br&&br&一. 图像压缩肇始：JPEG&br&&br&JPEG处理图片的关键步骤包括：&br&&br&&b&1. 将图片切割成8*8的block；&br&2. 对每一个block做DCT，得到transform之后的系数；&br&3. 对每个系数量化；&br&4. 量化后对每个block zigzag 扫描，得到最终的encoded bit stream。&/b&&br&&br&由于步骤3对JPEG的DCT系数实行的量化，JPEG是有损压缩，同时也因为分块处理，缺乏全局多尺度的考虑，这导致了jpeg压缩后的图像，被暴力压缩时候，容易产生块效应。&br&&br&&b&
二. 小波大法好&/b&&br&&br&考虑到以上问题，人们尝试引入新的正交变换，并以此为基础推出JPEG2000压缩协议。&br&&br&JPEG2000相对于JPEG主要不同是，JPEG2000使用了多尺度&b&Wavelet Transform(小波变换)&/b&进行图像表达。&b&所谓图像表达，就是把二维图像拉成一条以为的vector，再乘以由线性变换系数组成的矩阵，最终得到由图像表达系数（&/b&&b&如DCT系数，小波系数&/b&&b&）组成的vector。&/b&&br&&br&&b&像素到系数这个过程称为图像表达 （Image Representation），系数到像素过程称为图像重建(Image Reconstruction)。&/b&系数到像素过程可以认为是vector乘以逆矩阵之后回到像素空间vector&b&，&/b&当系数数目=像素数目，且能完全重建图像时，称为critically sampled系数，这些系数在线性空间上不存在冗余性，是图像压缩的起点。&br&&br&我们接着讲多尺度变换的好处：&br&&br&1. 多尺度的有点像是用不同焦段的镜头看同一个景色。广角端可以看到big picture, 中焦看到类似人眼的透视效果，长焦端可以看到压缩透视效果的细节。同理，wavelet representation的低频信号可以看到图像的大概，频率越往高走，图像的细节越多。&br&&br&多尺度的实现，是通过图像（像素空间）对不同的小波系数做二维卷积实现的。（通常低频小波系数卷积运算系数多，类比广角画面大；高频小波卷积运算系数少，类比长焦看到的画面小）&br&&br&多尺度的好处是，把鸡蛋（像素）放在多个篮子（频率段/尺度）里面，量化编码的时候，对每个频率段而非整个频率段（如DCT系数）实施量化编码，这样低尺度系数（对应的卷积序列长度&8）量化细致的话，图像最终恢复重建的时候，块效应可以显著减轻。&br&&br&2. 傅里叶分析的basis是三角函数（exp(1j*theta)），它的support是无限的。而自然图像的边缘常常是宽度有限的，大家知道，当傅里叶级数来逼近step function时候，会产生吉布斯效应：能量误差（L2 norm）asmyptotically收敛到0，但是看shape依旧有跳变，这就是为什么我们看微博文字类的照片时，经常在文字边缘能看到像素明暗的波动（振铃现象）。&br&&br&小波的好处在于它的basis很灵活。Daubechies 小波系数在时域上是连续，短支撑，且长得像图像边缘。当一个信号用和它长得很像的basis来逼近时，自然图像表达效率很高，需要的系数也就很少很稀疏，我们管这个现象叫efficient。正是因为efficient representation，小波变换用了较少的系数个数（其他的很多都是0）实现了同样的重建效果。&br&&br&以上两点好处，让JPEG2000实现了相对JPEG15%的进步：节省了15%的压缩空间。&br&&br&&b&
三. DPCM大法好&/b&&br&&br&做完了JPEG2000之后，人们发现，JPEG2000 并没有完全消除图像的空间冗余性。为什么这么说呢？小波变换虽然特别efficient，但是它的support毕竟是很短的，而空间上很长的线条首尾虽然跨度上千像素，我们在视觉上认为它们是一体的，结构近似，存在很多冗余。但是JPEG2000处理此类长边缘，对应的系数其实是独立编码，没有充分利用其冗余性的特点。&br&&br&这个时候，随着互联网的发达，大家对于视频压缩的研究变得火热，大家都在想怎么来去除相关性，想来想去无非有两大源头。&br&&br&1. inter-frame redundancy&br&视频内固定的风景，走动的人，前后帧关联巨大（时间冗余性）。&br&2. intra-frame redundancy &br&每一帧图像内的窗户，瓷砖，蓝天，白云的块之间关联性很大（空间冗余性）。&br&&br&考虑消除1和2后节省bits的巨大好处，大家搞出来了H.264 (Advanced Video Coding)。 这里的1由于和这个问题无关，以后可以找时间细说。&br&&br&处理2的过程是使用相邻block来predict我们要预测的block，这个过程和DPCM的道理是一回事。&b&JPEG2000由于使用小波基不能实现motion compensation被弃用，这里依旧使用JPEG的DCT来压缩。&/b&比如我们要预测8*8 block之内的像素值的大小的话，我们可以利用它左上两个方向的最近边的边长（共17个像素值）来预测。&br&&br&&b&每次编码器都穷举各种mode来找出一种最优最省bits的编码的方法&/b&&b&，记下这种模式的编号和残余误差，我们来对这个误差编好，这个过程会省出很多bits。&/b&&br&&br&具体预测有很多种mode,
H.264了里面大概包括有：&br& 4 x 4 luma blocks -&
9 prediction modes.&br& 8 x 8 luma blocks -&
9 prediction modes.&br&16 x 16 luma blocks -& 4 prediction modes.&br&&br&&b&
四. 如何更科学地DPCM？&/b&&br&&br&H.264 做好了之后，大家还嫌效果不好，怎么办？于是就做了H.265(Highly Efficient Video Coding简称HEVC)。HEVC就是BPG的算法基础。&br&&br&BPG用的算法就是HEVC中对于intra-frame block的编码。HEVC 的intra-frame 编码相对AVC比起来聪明了不少。&br&&br&1. 使用不同size的block来编码，而不是固定size的block。变化平缓的地方可以用32*32大小的block编码，变化剧烈的地方用4*4大小的block编码。这样可以有效减轻块效应。&br&2. mode扫描的方式提高到35种，等于对180°的角度量化成了35个bin，这样使得predection error明显变小。&br&&br&基于以上两大原因，BPG超过了AVC的intra-frame编码。&br&而减少了帧内的相关性，AVC intra-frame 编码能力要强于JPEG2000，JPEG2000编码能力又强于JPEG。&br&&br&&b&
五.总结：&br&&/b&&br&压缩能力比较：&br&&br&&b&
JPEG&JPEG200&AVC Intra-Frame&HEVC Intra-Frame(BPG)&/b&&br&&br&压缩能力提升的主要原因：&br&&br&&b&1. JPEG-&JPEG2000&/b&&br&&b&多尺度分析降低块效应&/b&&br&&b&小波系数更稀疏&/b&&br&&br&&b&2. JPEG2000-&AVC &/b&&b&Intra-Frame&/b&&br&&b&降低空间结构冗余&/b&&br&&br&&b&3. &/b&&b&AVC &/b&&b&Intra-Frame-&BPG&/b&&br&&b&进一步降低空间结构冗余&/b&&br&&br&现在回答题剩下的问题：&br&&br&&b&1. BPG会是终极的图像压缩方法吗？&/b&&br&&br&毋庸置疑，BPG是先进的图像压缩协议。&br&&br&&b&但是BPG使用的DCT作为线性变换本身相对多尺度的线性变换在压缩能力上存在先天弱势。之所以BPG和HEVC仍旧使用DCT来做线性变换的原因是因为一般的多尺度变换做不到在像素空间的block化，从而实现不了高效的block by block的预测。如果想在系数空间内block化，小波系数本身不具有shift-invariant的特性。换言之，像素空间整体移动后，小波系数的形状存在差异，根本不可预测。除非我们实现了shift-invariant且能critically sampled的变换，要不然我们就很难做到block化，就得接着用DCT来做。&/b&&br&&br&&b&另外对于的mode的预测，BPG的在180度空间内平均分成30多个等分一个一个试的方法多少让人觉得这种方法是盲人摸象，相对于前人H.264的编码过程，没有根本上得改进。自然图像，诸如边缘的变化角度明显是连续变化的，如果能实现具有边缘角度预测能力的线性变换的话，那么对于周边block的预测就会更加准确，会节省更多的bits。&/b&&br&&br&&br&&b&2. BPG会像JPEG一样被广泛使用吗？&/b&&br&&br&&b&未必。&/b&&br&&br&不是牛逼的压缩协议就能被大量采用的，JPEG2000就是明显的例子，大家目前日常能看到JPEG2000的地方估计只有Photoshop的保存按钮，选择.jpeg2000。（其他可能用到JPEG2000的场合：军用雷达发回的图像，因为军用设备对带宽极其敏感，把带宽提高一个数量级，价格不知道翻了多少倍）。&br&&br&JPEG2000没有被广泛用的原因是，JPEG2000没有比JPEG好太多（15%）且涉及到专利。&br&&br&说到专利，这里说一个业界的常识&b&，即便是某一个压缩协议源代码公布了，实际上不同公司的具体算法（尤其是硬件层面的算法）会不同，并且只会比公布的源代码效果更好。&/b&这里的原因是，标准委员会的里面的人很多都在例如微软，Google这样的大公司的有职务，他们有不愿告诉别人的更好的压缩想法，打算闷声发大财，但是标准又要公布，所以他们只会在标准里面写表现一般的细节（比如算法较慢，容错率一般）。这样的结果是，各大公司做的算法有好有差，算法差的公司很有可能拿好的公司的算法用，然后做产品卖，然后被发现，打官司要求禁用该算法在该公司产品的使用。连JPEG这么老的协议都有很多公司在为自己拥有这个专利而争执不休，BPG要打破大公司之间的壁垒，而被广泛使用，其实还存在诸多变数。&br&&br&&br&&b&【注】：利益相关，本人目前在从事图像压缩领域的研究。&/b&
前几天占楼，现在到了周末终于有时间来更新一番。为了回答楼主的问题，我们先从图像压缩说起。一. 图像压缩肇始：JPEGJPEG处理图片的关键步骤包括：1. 将图片切割成8*8的block；2. 对每一个block做DCT，得到transform之后的系数；3. 对每个系数量化；4. 量…
&b&这种动画称之为DEMO(demonstration）。它跟一般的影视视频不同，不是直接靠播放器调用视频解码器解析。而是另外执行的EXE文件调用硬件即时演算的。&/b&&br&&img src=&/b9400ebbcbbab923b4163fea1eaa5ca7_b.jpg& data-rawwidth=&200& data-rawheight=&150& class=&content_image& width=&200&&&br&Demo程序是通过直接对显卡进行操作和计算，其中只包含一些关键帧，而中间的实现效果则完全通过算法演算出来，而且，通常情况下，Demo里面的图形都是一些比较规则的多边形，里面的图案组合往往可以重复利用，这样就大大减少了整个程序的体积。 这种影像制作工具用werkkzeug。&br&&br&制作完成后，需要调用UPX (the Ultimate Packer for eXecutables)算法加壳压缩。这个是专门拿来压缩可执行文件的，通常压缩过文件体积缩小50%-70%。（我试过最高压缩率是原体积8%，应该还能更低）&br&&br&这片子采用了使用简单的几何图形（如正方体、立方体、圆柱等）进行组合，通过汇编语言调用M$ DirectX引擎的核心代码库来建立对象架构、三维空间位置、运动轨迹及材质信息。程序在运行时由CPU读出这些信息给DirectX渲染引擎生成三维立体的对象及其动画。它不同于其它的3D动画多采用3D Max、MAYA那些建高面数模型的软件，制作出比较复杂的场景再进行贴图；而是从一开始就注意了“节省”，采用最简单的模型、运用不断优化的算法，组合出最复杂的效果.做纹理并贴图：同制作场景的思 路相同，也尽量采用最简单的方法制作出自己喜欢的纹理，在它的最终版本中，采用了66幅256×256点大小的32位纹理，未压缩前纹理大小为16MB。里面还有一段要是正常输出有159MB的音乐，是使用LOGIC AUDIO制作出来的。音乐包含两个部分，一个是Loading Music，另外一个是Main Music。&br&&br&每年都有一个叫“International Demo Competitions”国际DEMO编程动画大赛的比赛。专门有一些人做这些类似影像的。&br&&br&由于一些神秘的技术技巧我们不可能完全得知，所以要达 到像国外的 SceneDemo 专业团队的水平那也是相当有难度的。&br&&br&有兴趣想做做类影像的可以看看《Texturing and Modeling - A Procedural Approach》这本书。里面详细的介绍了各种过程纹理和造型技术。 介绍的 Metaball 技术就是其中的一种，在早些年的 Demo 中经常能看到 Metaball 技术的展示：几个球或者其它形状的物体互相融合和侵彻， 可以生成极为复杂的新造型。&br&&br&虽然最近几年的 64K Intro 已经几乎不使 用像 Metaball 这样的平民技术了，hacker 似乎总在追寻更强大的 过程纹理造型方法和更酷更眩的渲染技巧。而 07 年的 Best 64K Intro 似乎是完 全在炫耀作者的着色器编写技术。 但是 Metaball 却并不是像雁型阵一样过时了，它甚至在 2D 图形领域也得到了广泛的应用。 &br&&br&Metaball 的原理 Metaball （元球） 技术是由 Blinn 于 1982 年开发一种适用于建立可变形表面的技术。此技术利用 Metaball 建立能量场，然后通过标量域的等势面来建立3D 模型来表现软体或者隐式曲面。 简单的说， 就是在空间里布置一些 Metaball， 每个 Metaball 都有一个能量场，通常用势函数来表示。设空间里均布着无数个点。在其中某一点，它的能量为每个 Metaball 对它的势的叠加。然后在空间的所有点找出势能相同的点，就得到一个由这些点组成的曲面。至于势函数的选择就很多了， 有指数函数， 分段多项式函数等等……算了不细说了，再说又没完没了。&br&&br&这里放出一个97年的Mekka ’97 4K Intro比赛的一等奖作品代码。整个程序全长4095字节，其中包含133字节的自解压程序，未解压的程序长4782字节。三维场景包含144个立方体，367个面，362个点，15个不同的64*64的纹理，还有一段音乐…… 链接&a href=&///?target=http%3A///listpro.asp%3Fid%3D700& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/listpro.asp?&/span&&span class=&invisible&&id=700&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&至于是如何吧rar改成图片。&br&方法1：&br&开始---运行--CMD&br&在光标所在地方输入 copy /b E:2.jpg+E:1.rar E:output.jpg 然后回车。&br&(注意空格与半角全角，建议粘贴复制)&br&然后：会出现：&br&”E:2.jpg&br&E:1.rar&br&已复制 1 个文件。“&br&这样就完成了文件的合并。将jpg文件与rar文件合并起来了。(注意如果图片2格式是jpeg，则需在上述命令输入jpeg，否则会出现找不到指令文件），合并后的文件在E盘，名字为output.jpg&br&我们把这个图片由.jpg改成.rar结尾以后可以发现仍然可以解压缩得到我们的文件，改成jpg依然是一张图片。&br&&br&方法2：&br&1.新建文件夹。&br&2.在文件夹里，新建文本文档&br&3.输入 copy/b 2.jpg+1.rar =output.jpg (注意空格与半角全角，建议粘贴复制)&br&其中图片与压缩包名不能改“output”可改。&br&4.保存,改文件格式 .txt 为 .bat。&br&5.将1.jpg和1.rar都放置在bat文件所在文件夹，运行。&br&6.会在bat文件所在文件夹内生成output.jpg&br&&br&方法3；&br&直接下载 JPG+RAR合并器 这类软件&br&&br&&br&&img src=&/5d7bc80ea0d858b44375c_b.jpg& data-rawwidth=&789& data-rawheight=&411& class=&origin_image zh-lightbox-thumb& width=&789& data-original=&/5d7bc80ea0d858b44375c_r.jpg&&附带一提：电脑游戏能用到类似这种技术么？&br&能，《毁灭杀手》(kkrieger)。95KB。由.theprodukkt小组开发，不过这个主体由C++完成，之间贯穿少量汇编语言。&br&下载地址：&a href=&///?target=http%3A///s/1i3FW2Tf& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/s/1i3FW2T&/span&&span class=&invisible&&f&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&参考资料&br&【1】&a href=&///?target=http%3A//www.theproduct.de/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&.fr-08: .the .product&i class=&icon-external&&&/i&&/a&&br&【2】&a href=&///?target=http%3A///view/7114230.htm%3Ffr%3Daladdin& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/view/71&/span&&span class=&invisible&&14230.htm?fr=aladdin&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&【3】计算机真实感图形的算法基础. 彭群生著
这种动画称之为DEMO(demonstration）。它跟一般的影视视频不同，不是直接靠播放器调用视频解码器解析。而是另外执行的EXE文件调用硬件即时演算的。Demo程序是通过直接对显卡进行操作和计算，其中只包含一些关键帧，而中间的实现效果则完全通过算法演算出来…
这个问题只要一句话就能解释明白：根据香农的信息理论，任何一个文件被无损压缩后的结果不可能小于其 &a href=&///?target=http%3A//zh.wikipedia.org/wiki/%25E4%25BF%25A1%25E6%2581%25AF%25E7%& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&熵 (信息论)&i class=&icon-external&&&/i&&/a& 。&br&&br&换句话说，如果一个文件有20多个G的大小，但是其信息熵只有20多M，则实现一个1000倍的压缩是完全可能的（比如楼主放出的几小时全黑视频）；反过来看，一个文件如果虽然只有100M，但是其信息熵却高达90M，则这样的文件是无论如何也不可能被无损压缩至20M大小的。&br&&br&多说一句，一个文件的信息熵有多少，靠一个公式是完全可以算出来的。所以只要提供任何一个文件，我们都能知道它最小可以被压缩到多少。&br&&br&以上说法仅限于无损压缩，对于有损压缩来说，压缩了多少倍皆有可能。
这个问题只要一句话就能解释明白：根据香农的信息理论，任何一个文件被无损压缩后的结果不可能小于其
。换句话说，如果一个文件有20多个G的大小，但是其信息熵只有20多M，则实现一个1000倍的压缩是完全可能的（比如楼主放出的几小时全黑视频）…
来自子话题：
先吐槽一下，找问题找的好难。。。&br&&br&&b&&u&文章想抱走可以，把ACI字幕组技术部标上。&/u&&/b&&br&&br&&br&&b&&u&此答案同样适用于&/u&&/b&&a href=&/question/& class=&internal&&在封装以AVC H.264视频编码格式时，MKV在封装内容的支持性之外还有哪些优势让他在互联网高清视频的发布中受到更多字幕组和RIP组的欢迎？&/a&&a href=&/question/& class=&internal&&RM、RMVB、MKV、MP4、AVI 等视频格式有哪些区别？各自的优势劣势是什么？&/a&
等问题。&br&&br&&br&ACI字幕组打杂，一直在压制。&br&&br&Oct.5 更新：sina死了，需要更新了。&br&&br&（Aug.16更新：加了3个例子。）&br&&br&（Aug.10：更新3)b)section一处错误，感谢&a class=&member_mention& data-editable=&true& data-title=&@nfs king& data-hash=&dce6a22d477caffbaf9ace7& href=&///people/dce6a22d477caffbaf9ace7& data-tip=&p$b$dce6a22d477caffbaf9ace7&&@nfs king&/a& 的指正。）&br&&br&&b&&u&（Aug.9:答案随题目而更新，放在原答案最后。）&/u&&/b&&br&&br&开始解答：&br&----------&br&0.首先说一句我们的需求：&br&&br&&b&请注意，我们的作品不仅要在各种电脑上（从Xeon到Celeron）看，还要在质量参差不齐的平板、手机上播放。同时，我们还需要准备在线版片源，供在线观看。&/b&&br&&br&&br&&b&我们希望，压出的片子清晰美观，但也不能太大。如果供在线观看，需要保证小水管也可以正常播放，在带宽正常的情况下，不会出现大量缓冲。&/b&&br&&br&以下的选择都服务于上面这些要求。&br&&br&当然某些时候，我们就是要挑战技术极限，那么我们会往死里用一些办法：不指望播放，只要指导作用。&br&------------&br&&br&&i&1.为什么影视组发布一般能用mkv（多音轨多字幕）和rm、rmvb（都是下载后看觉得没必要这个）而不用f4v和flv&/i&&br&&br&1）为什么MKV（图片请看@阿德 的答案。）&br&MKV是个很好的封装，可以封进去很多东西，例如&b&&u&多字幕，多音轨。&/u&&/b&&br&对于某些BD转录自带多声道的片子（例如，我们一直想做的PilotsEye（现在做了）的某些片源，还有需要“副音轨”的片子，例如，《化物语》的副音轨，也叫评论音轨，随便怎么叫了。），或者需要多字幕的片子（例如，CASO的凉宫，正经字幕+吐槽字幕，或者PilotsEye的某些片源自带多语字幕），MKV几乎是唯一的选择，因为&b&只有它能如此封装&/b&。&br&&br&例子是，&a href=&///?target=http%3A//.cn/s/blog_53a236f0010148pn.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Yes,Minister, Yes,Prime Minister （TLF新装）_sennheiser_新浪博客&i class=&icon-external&&&/i&&/a& ，&b&5字幕&/b&。&br&再例如，&a href=&///?target=http%3A///html/3399.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&（修复错误）【TD字幕组】【化物语副音轨】[bakemonogatari comment][848x480][GB][MP4]&i class=&icon-external&&&/i&&/a&
明明是副音轨，但还是要重新把片子下一遍。对于观看没影响，对于收藏来说，略显不便。&i&当然，字幕的版权问题是另一个方面，但是我们这个部分仅作技术讨论。&/i&&br&比较强大的例子是：&a href=&///?target=http%3A//www.tsdm.net/forum.php%3Fmod%3Dviewthread%26tid%3D118343& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&[CASO][凉宫春日的忧郁][BDRIP][MKV][][x264_FLAC_2][1-28][日英双音轨+简繁英字幕][25G]&i class=&icon-external&&&/i&&/a& 注意，&b&双音轨，三字幕&/b&。rm，flv，MP4封装都是没法做到这种效果的。&br&&br&声明：本文所引链接仅出于技术讨论之用。如果涉及版权问题，请私信我进行处理。&br&&br&&br&但是，由于可能需要调整分离器等”复杂“设置，会对&b&非专业&/b&用户造成&b&很大的困扰&/b&。&br&&br&所以，在生产中，MKV一般只用于有特殊需求的时候。The simpler, the better.&br&&br&2）为什么rm，rmvb，以及为什么现在大家不用它们&br&rmvb和rm是一样的东西，”vb“代表可变比特率。（为小白讲一句：这代表，在画面变化不大的情况下，可以适当减少码率，以减小文件大小；在画面变化大的时候，可以增加码率，使视频依然保持清晰，不出现模糊，色块等问题。）&br&&br&rm格式是当年的主打，因为&b&压缩率高，画面可以接受。&/b&&br&&br&但是，问题在于：&br&&br&a)realmedia闭源。这造成很多播放器&b&无法播放&/b&rm，因为需要交授权费。这个问题在机顶盒等嵌入式设备上尤为突出。&br&&br&b）在带宽不那么紧张的今天，rm无法提供更好的画质，以适应播放条件更加宽松的高清需求。具体有很多对比，SOSG做过一个测试，详细的阐述了这个问题，此次不再赘言。结论是：在同样码率（可以理解为文件大小）的情况下，H.264可以提供更好的画质。&br&&br&c）看不到realmedia改进的希望。real公司一直坚持闭源，无视环境变化。没有拿出任何令人兴奋的改进。&br&&br&d）rm对在线视频不甚友好。&br&&br&3）为什么不用f4v或flv&br&&br&a）这节讨论建立在&b&&u&下载版视频&/u&&/b&的基础上。&br&&br&1）观众普遍认为，flv格式”不清晰“，虽然这是不正确的。是否清晰与封装没什么关系。&br&&br&2）f4v过于小众，观众可能会不知道如何播放。&br&&br&囧答案。嗯。&br&&br&b）flv还是有用的&br&&br&目前，flv内封装H264+AAC，这个被所有的视频网站支持，从youtube到sina都在用。&br&&br&所以，我们在发布&b&&u&在线版本视频&/u&&/b&的时候，有时会采用这个格式。&br&(Aug.8 UPDATE:因为我们要达到上传后&b&&u&不被二次转码&/u&&/b&的目的；其他格式上传后，会被各大网站转码成&b&不清晰的渣视频&/b&。所以我们会压flv，但大家是下不到这个版本的，因为我们不会把这个版本提供下载，只会把MP4版本提供下载。）&br&（Oct.5 update：对于土豆等地方会flv，但是出于稳定性，对于letvcloud会使用mp4.）&br&&br&顺便说下，目前业界主流的封装是MP4.因为MP4有着良好的特性，并对HTML5友好。&br&&br&&i&2.封装格式一般都对应的有很多编码格式（见上图），在其他设置一样的情况下（音频视频的采样率，声道，通道都一样）选不同编码器最后大小有什么不同（是&br&不是越后出的标准也先进，越好比如H.264到H.265）？&/i&&br&&br&&br&H264是个很神奇的东西：好的编码器和坏的编码器，质量和码率会天上地下。&br&&br&目前主流的H264编码器是开源的x264，完美的平衡了各种因素。&br&&br&其他的编码器没有太用过，但是，好的制式+编码器可以做出高画质+低码率，坏的反之。&br&&br&在编码时，有大量的参数可以调整。这些参数控制了码率。同时，大多数编码器可以直接自动化控制最终的目标码率，只需要输入预期。&br&&br&&b&理论上&/b&是越后出的越先进，但是，后出的标准，需要编码器跟上。如果没有好的编码器，好的标准也没有用武之地。H264被rm压制了很多年，直到几个很好的编码器横空出世，才奠定了今天的地位。&br&&br&举俩栗子：&br&1）vp8在H264后出现（VP8 2008年，H264 2003年）。事实是，VP8并不优于H264，某些时候甚至劣于H264。&br&&br&2）H265是目前最新的技术。但是，在目前的编码技术下，H265的编码时间是H264的N倍，画质没有明显提升。&br&（大热天的，不找引文了，也不是写论文喵~）&br&&br&ACI字幕组技术部曾经进行过关于VP8，H265的讨论、研究和测试。&br&&br&得出的结论是：我们欢迎新技术的发展，但是，技术的推出，和进入生产，是两回事。&br&&br&以上为一家之言，经验匮乏，才疏学浅，如有问题，敬请赐教！&br&&br&&br&&br&--------Aug.9答案补充------&br&&br&随题目而继续更新。&br&&br&1.说的先有&b&概念&/b&再试验后有&b&一定技术&/b&，大家一起&b&完善标准&/b&，最后还是看&b&推广以及环境的选择 &/b&举个例子ipv6早就有了，至今没有普及，不好么吧 在举个有意思的例子 电力宽带（&a href=&///?target=http%3A///view/34202.htm& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&电力宽带_百度百科&i class=&icon-external&&&/i&&/a&）技术早就有了，可是我也是最近才知道 关于解码器这个我觉得现在不是问题，联网后分分钟的事 我自己一直用迅雷看看 *.csf *.vp6(极品飞车9里电影文件)等其他游戏里罕见视频格式一般都能打开 &b&所以软解都不是问题，在以后智能电视盒子什么普及的时代还是看处理性能&/b&&br&&br&&br&这个问题简直是先有鸡还是先有蛋的问题。。。在计算机上，可以很快的更新&b&软件解码器&/b&，只要配置够用。但是，硬件解码器是无法更新的，就像A卡就是绑上火箭也开不了N卡的CUDA一样。这个问题在移动端将更为严重，因为移动处理器的性能远不及桌面处理器，这在未来不会有太大改变。&br&&br&这种情况导致了，除非有十分大的优势，新格式是很难将旧格式挤出市场的。具体表现在，即使是现在，还是有大量的字幕组在制作rmvb，而不选用H264。技术惰性是一个原因，也可能技术的更新不足以使他们做出改变吧。。。&br&&br&&br&2 关于视频的编码为什么是rmvb我有点感悟不知对不①资源抢先发布时不希望防止别人用自己的东西，我这样压缩进去的话别人用不了（还有加水印），增加了成本你要用自己的先找无字幕视频再做字幕还压缩 而不是直接mkv里字幕改改就行的 至于格式估计只是习惯而已 （ps.故事小女孩问妈妈我们蒸香肠为什么要切三段后放进去？妈妈说不知道，我小时候你奶奶就是这样子，打电话问奶奶才得知原因是以前微波炉比较小装不下。）可见习惯的力量 压制组进去的话估计提供全套的工具和教程 重点就不在压制上而在与快速发布上，除非出的新技术不得不改（我们设想下以后影像是分层的，对于不同画面有针对性压缩） 像比较久的视频主要就是mkv了比如纪录片和经典的东西（宫崎骏的 迪士尼的（这个估计就是正版转的吧 多字幕多音轨））&br&&br&对。十分正确。&br&题主一下子就抓住了问题的关键。&br&但是，作为字幕组成员，我的理解角度和题主的略有不同。&br&在这里，我叙述一下我的看法，与题主共勉。&br&&br&&i&以下的生产环境皆为字幕组。生肉是另一个话题了。&/i&&br&&br&&br&&i&（吐槽：这个问题可以详细展开，能写本小册子。。。）&/i&&br&&br&这段的争论是硬字幕和软字幕的战争，也就是OC和CC的战争。具体到我们这个问题上，是&b&不硬压制入字幕的MKV封装&/b&和&b&必须压制进字幕的rmvb、MP4封装&/b&的战争。&br&&br&对于字幕组而言，他们的资产之一就是这些&b&字幕源文件&/b&。一旦其他人拿到了这些文件，他们可以自己下载生肉，对其进行任意修改，并重新发布。这种行为对于字幕组而言是重大打击；所以，字幕组倾向于保&b&护自己的字幕源文件&/b&，而不是为了知识共享这一高尚的行为而放出源文件。的确，绝大部分字幕组都&b&会公开&/b&自己的字幕文件，但几乎都不是第一时间发布——为了保护自己。&br&在这里，请再次回想一下第0节提到的指导思想：&b&&u&让各种设备，各种程度的观众都能方便快捷地观赏作品。&/u&&/b&&br&&br&在这些思想的前提下，我们分析一下各个格式的利弊：&br&MKV可以封装进章节，各种视频格式与音频格式，封装数条音轨，字幕、字体文件。具体请参考&a class=&member_mention& data-editable=&true& data-title=&@阿德& data-hash=&54f271f7488bfd49cad50da6& href=&///people/54f271f7488bfd49cad50da6& data-tip=&p$b$54f271f7488bfd49cad50da6&&@阿德&/a& 的答案，他对于这个问题有着深入的理解。&br&那么，MKV的好处在于，给观众最大的自由度：可以随便调整最终的输出，达到最佳的观看体验。对于收藏人士、喜欢折腾的人、专业人士（当然和&a class=&member_mention& data-editable=&true& data-title=&@著驿& data-hash=&2f23097eeddfc31c80614e& href=&///people/2f23097eeddfc31c80614e& data-tip=&p$b$2f23097eeddfc31c80614e&&@著驿&/a& 的专业比不了啦~业余级的专业）来说，MKV可以带来最佳体验。&br&但是，这种自由度也带来了很多麻烦：&br&1.对于新手，移动设备来说，MKV的&b&&u&自由度是个灾难&/u&&/b&：各大论坛中充斥了播放的报错，涉及的格式几乎都是MKV。因为，可调节的东西太多，对新手而言，造成播放结果不可控。这是灾难性的。&br&2.&b&&u&字幕文件的流失不可控&/u&&/b&。通过工具，可以很简便地提取出MKV中封装的各种文件，如果字幕组不愿意放出字幕文件，则一定不会使用这种格式——透露自己核心科技了。&br&3.&b&&u&偏见&/u&&/b&。公众抱有偏见，认为MKV一定要清晰。这造成，没有高清片源，字幕组不愿制作MKV.&br&4.&b&&u&技术难度&/u&&/b&。MKV的制作比MP4等格式复杂，不适宜对时间敏感的视频发布，例如新番。&br&&br&简直就是Android和Apple的战争。。。
先吐槽一下，找问题找的好难。。。文章想抱走可以，把ACI字幕组技术部标上。此答案同样适用于
ZIP炸弹。&br&&a class=& external& href=&///?target=http%3A//www.unforgettable.dk/42.zip& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&unforgettable.dk/42.zip&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&&br&42KB 解压变成 4.5PB ，解压密码 42&br&不是GB不是TB，是PB。&br&里面有什么？&br&&blockquote&The
file contains 16 zipped files, which again contains 16 zipped files,
which again contains 16 zipped files, which again contains 16 zipped,
which again contains 16 zipped files, which contain 1 file, with the
size of 4.3GB.&/blockquote&这个压缩文件中包含16个压缩文件，每个压缩文件又包含16个压缩文件，每个压缩文件又包含16个压缩文件，每个压缩文件又包含16个压缩文件，每个压缩文件又包含16个压缩文件，每个文件大小为 4.3GB。&br&16^5 = 1 048 576&br&4.3GB * 1 048 576 = 4 508 876.8GB&br&差不多 4.5PB&br&至于那个 4.3GB 的文件，提取出来后以 16 进制查看，全是 0xAAAA&br&&br&&br&如果这让你觉得疯狂，那下面这个 28KB 压缩文件会让你领略什么叫邪魅 XD&br&&a class=& external& href=&///?target=http%3A///code/useless/zip-file-quine/droste.zip& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/code/useless&/span&&span class=&invisible&&/zip-file-quine/droste.zip&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&这个压缩文件的嵌套压缩层级是无穷大，也就是说它可以不停地解压下去……&br&跟一个算法有关，这个算法可以打印自身代码&a class=& wrap external& href=&///?target=http%3A//en.wikipedia.org/wiki/Quine_%2528computing%2529& target=&_blank& rel=&nofollow noreferrer&& Quine (computing)&i class=&icon-external&&&/i&&/a&&br&&br&&br&来源 &a class=& wrap external& href=&///?target=http%3A///What-is-the-most-compressed-file-ever/answers/Fsrid%3Dn7TG%26share%3D1& target=&_blank& rel=&nofollow noreferrer&&Answer to What is the most compressed file ever?&i class=&icon-external&&&/i&&/a&
ZIP炸弹。42KB 解压变成 4.5PB ，解压密码 42不是GB不是TB，是PB。里面有什么？The
file contains 16 zipped files, which again contains 16 zipped files,
which again contains 16 zipped files, which again contains 16 zipped,…
来自子话题：
7z 能不能换一套好看点的图标……
7z 能不能换一套好看点的图标……
&b&问题本身是错的。&/b&&br&这个问题应该是“为什么在中国大陆RAR格式比ZIP常见”。&br&&b&离开中国大陆，你会发现用RAR的人比说中国话的人还少。&/b&&br&作为独立进化的代表，连日本鬼子都是用ZIP的（当然LZH也很多）&br&&br&&br&关于这件事，有一篇非常好的文章，《压缩大战真相》 （2004.10的《大众软件》，原作者为 广东 GZ）。节选一段：&br&&br&RAR离奇崛起&br&&br&　　不妨先来思考一个问题，为什么舆论不指责WinZip9.0不支持WinACE的ACE格式，不指责它不支持WinIMP的IMP格式……唯独不支持WinRAR的RAR格式就横加指责呢？答案只能是WinZip不得不支持RAR格式。为什么不得不支持RAR格式呢？答案只能是RAR格式已经成为主流，不支持意味着消亡。这真是一个有趣的推论，2002年时中国的IT媒体还将WinRAR归为非主流压缩软件，而不到两年的时间RAR格式就变成了主流格式，简直就是个奇迹！然而这真的是事实吗？&br&&br&　　我们知道ZIP格式成为最主流的原因并不是因为WinZip的出现，而是因为ZIP格式的开放性。ZIP与WinZip之间不过是机缘聚会，即使没有WinZip也必将另外出现类似的“xxZIP”共享软件。ZIP格式的开放从根本上避免了数据压缩世界形成垄断，任何一个消费者总会优先选择免费自由格式的压缩工具，更何况这个免费格式是如此优秀，这使得WinZip之后的任何压缩工具只能先支持ZIP格式站住脚，然后再去推广它不开放编码算法的自有压缩格式。因此最后的结论是不开放的商业压缩格式不可能取代免费ZIP格式成为主流，而RAR同ACE、IMP等一样都是不开放的格式，它也不可能成为主流。这个结论显然会刺激某些人的神经，一定有人会指出事实胜于雄辩，让笔者上网去看看到处的RAR压缩文件。笔者并不否认这是某种事实，不过仍然会坚持RAR不是主流。&br&&br&&b&在任何一个国外知名的下载王者，如&a href=&///?target=http%3A//& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&等，都不可能找到RAR压缩文件，或者去国外任何一家知名商业网站，其下载资源提供的也只有ZIP压缩包。是的，甚至在国外比较规范的个人网站上，都只提供ZIP打包的文件下载，而不会有其他类型的压缩文件。&/b&国内情况会不一样吗？那么去新浪、搜狐、驱动之家这些大的门户网站或正规的商业网站搜索，同样全部是提供ZIP压缩文件的下载，却根本没有RAR文件。并不是这些网站刻意偏爱ZIP，根本原因还是在于免费。发布ZIP压缩文件并不用缴纳任何费用，而如果发布其他商业压缩格式文件，网站就要向其格式拥有者缴纳专利费用，这种企业所需缴纳的费用不是个人注册费用可以相提并论的。由此带来的疑惑是，在中国确实有许多网站只提供RAR压缩文件的下载，那么他们都甘心交钱替WinRAR宣传吗？同样时不开放算法的商业格式，他们为什么不选择压缩率更高功能更加全面的ACE、IMP等格式呢？&br&&br&　　首先笔者不排除这种情况，即可能有特别热爱RAR格式，依法缴费然后再帮着推广的网站，不过可以肯定即使有也为数不多。大多数这样的网站非法发布RAR格式文件，区别仅仅在于自己知道或不知道，不过WinRAR公司难道就坐视不管吗？其实道理很明显，没有比推广压缩格式更容易占据压缩工具市场份额的手段了。2002年WinRAR尚未有中国区代理，不过积极开拓海外市场的WinRAR已经意识到，许多中国网站上也流行着RAR压缩文件，于是一时间突然有许多网站声明，下载资源将由RAR压缩包全部改用ZIP包发布，但在WinRAR中国区代理上任后，短短的几个月这些网站又都恢复发布RAR压缩文件，而且使用RAR格式发布资源的网站日益增多。&b&事实已经清楚，非正规网站提供下载资源的确实都是RAR压缩文件，不过为什么它们都选择RAR而不是其他格式，答案说出来熟悉的朋友马上就会明白——ODAY。&/b&&br&&br&　　年中国的宽带网建设一跃成为世界前列，宽带网的发展使得资源的获取变得极其简单。几乎国内有名的资源站点和论坛都出现在此期间，它们无一例外提供的都是RAR格式资源。那么&b&它们的资源又来自哪里？基本都来自于ODAY，所有宣称RAR格式占据网络主流的人都或刻意或无意地回避了这个事实。ODAY是个完全无影无形的破解组织，但他们发布的资源都有同一个特点，就是统一使用RAR格式打包，如此一来发布这些资源的网站要提供ZIP包下载则必须先解开RAR包，然后再将资源重新压缩为ZIP包，最终选择当然是直接提供RAR压缩包下载了，这就是RAR格式开始流行的根本原因。&/b&于是奇怪的事情出现了：免费开放的压缩格式得到所有正规商业公司的支持，而收费非开放的压缩格式却崛起于自由破解的地下组织。一个微妙的形势摆在WinRAR面前，它再流行也始终不会去控告违法发布者，那其实是它生存的根源。一个尖锐的问题也摆在用户面前，在合法的前提下你会选择哪种压缩格式？其实是根本就没有选择。&br&&br&　　因此不能否认RAR压缩文件在网络上确实到处可见，但既然它来自于江湖，就注定无法真正成为主流压缩格式。
问题本身是错的。这个问题应该是“为什么在中国大陆RAR格式比ZIP常见”。离开中国大陆，你会发现用RAR的人比说中国话的人还少。作为独立进化的代表，连日本鬼子都是用ZIP的（当然LZH也很多）关于这件事，有一篇非常好的文章，《压缩大战真相》 （2004.10的…
来自子话题：
&ul&&li&&b&乱码原因&/b&：Mac OS X 系统自带的压缩程序对 zip 文件名用 UTF-8 编码，但 zip 文件头中没有声明 PKZIP 高版本增加的 Unicode 位。Windows 会认为文件名是 ANSI 编码，结果显示乱码。&/li&&li&&b&解决方法&/b&：用第三方软件。我推荐 Keka，支持格式多，加密、分卷、压缩比调节等功能都有，还支持中文菜单和界面。最重要的：免费。详细介绍在 &a href=&///?target=http%3A//t.cn/hGy98k& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/hGy98k&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&&/li&&/ul&
乱码原因：Mac OS X 系统自带的压缩程序对 zip 文件名用 UTF-8 编码，但 zip 文件头中没有声明 PKZIP 高版本增加的 Unicode 位。Windows 会认为文件名是 ANSI 编码，结果显示乱码。解决方法：用第三方软件。我推荐 Keka，支持格式多，加密、分卷、压缩比调…
来自子话题：
1、现有流行的压缩软件绝大多数情况下已经离最低信息熵不远了。也就是说，绝大多数情况下，即便有一个理想的压缩算法，它并不能使得压缩后文件明显小于ZIP、RAR等算法的结果。&br&（我依稀记得估计的人类文本信息有效信息约15%，而ZIP、RAR等软件已经做到很接近15%了，即便出现一个理想算法也只能缩小压缩包体积不足0.1%。请知道具体数字的指正。）&br&&br&2、由于存储介质单位容量成本的大幅下降和网络带宽的大幅提高，人们对压缩的要求已经从最终的体积转向了压缩的速度。而ZIP、RAR等算法恰恰由于在设计时对运算能力的限制更严重而充分考虑了压缩速度，因此虽然压缩率并不理想但反而更适应现在的市场需求。&br&&br&3、压缩算法的研究方向已经转向特定内容的压缩。例如PNG对图片的无损压缩，MPEG4、MPEG5、WebM对视频和图片的有损压缩，AAC等算法对音频的压缩。这些特定领域压缩算法进步一直很快，也一直在快速更新。
1、现有流行的压缩软件绝大多数情况下已经离最低信息熵不远了。也就是说，绝大多数情况下，即便有一个理想的压缩算法，它并不能使得压缩后文件明显小于ZIP、RAR等算法的结果。（我依稀记得估计的人类文本信息有效信息约15%，而ZIP、RAR等软件已经做到很接近…
来自子话题：
压缩软件不是那种需要经常关注界面的应用，比如你需要压缩一些文件，往往是设置好选项后后面的工作就由压缩软件本身完成，界面还能怎么改进呢？引入流行的所谓Ribbon？加入大量特效？这不是压缩软件的本职工作。老实说界面太花哨的压缩器往往还会让人怀疑其内在（压缩率、性能、文件是否会损坏）。&br&&br&因为要兼容现存的压缩文档，所以对于一个旧的压缩器来说，压缩算法和文件格式部分最稳妥的做法是不要进行大的改动，最好是不改动，压缩器带来的一点点改进无关紧要，损坏了现存压缩包的文件问题就严重了。&br&&br&如果是仅仅是从技术的角度来说，抛开兼容旧文档的压力（比如从头开发一个压缩软件），那么创新点还是很多的，但举几例：&br&&br&文件修复：这个功能其实不算是新功能，但是并没有普及开，仅仅出现在部分压缩器上。&br&&br&并行压缩：现在很多人电脑都具备多核心处理器，那么是不是能针对多核心进行优化以提升性能呢？这个在部分压缩器上已经实现了。&br&&br&云压缩：把一些需要非常大计算能力的超强压缩算法。比如说该算法比一般传统压缩器压缩率提高30%（这不是玩笑，而且很有用，要压缩的数据越大这个30%所占比例越大），但是该算法运行时需要占用128GB内存，或者运行速度很慢，怎么办？做成云服务，由专业的服务提供商购买强大的计算机提供压缩服务。&br&&br&特征自定义：给用户提供比较高的自由度用恰当的方式描述所压缩的数据的类型，这样可以提供比较高的压缩率，这个涉及的知识很多，用户如何描述这个“特征”？用图？用代码？。&br&&br&自描述压缩格式：这里的“自描述”不是“自解压”的意思，而是在压缩文档中内置对压缩算法的描述。这样的做法有什么好处呢？就是每次解压可以通过自我描述的压缩算法来解压压缩包内的数据，直接带来的好处就是，以后压缩格式可以放肆地升级而不用考虑兼容了，反正压缩文档有解压缩该文件所需的信息，以后该压缩器的公司倒闭了或者再也不更新了也不怕。自描述功能目前我还没见到很多压缩器有，该功能的实现依赖对自描述信息的设计问题，假设这个自描述信息是给出一个跨平台的虚拟机标准的字节码（这是我见过的唯一做法），那如何设计这个虚拟机才能在很多平台上获得较高的性能？这涉及对流行计算机体系结构以及未来可能会流行的计算机体系结构的把握。说起来简单，实际做下去能作出什么效果还很难说。我目前还没成功实现过这个功能。&br&&br&应该还有很多点子，如果你有好的主意也请告诉我。
压缩软件不是那种需要经常关注界面的应用，比如你需要压缩一些文件，往往是设置好选项后后面的工作就由压缩软件本身完成，界面还能怎么改进呢？引入流行的所谓Ribbon？加入大量特效？这不是压缩软件的本职工作。老实说界面太花哨的压缩器往往还会让人怀疑其…
几位已有的回答都很不错，但是略微有些跑题了。&br&&br&题主问的是“为什么”WAV格式的文件占用空间如此大？ 鄙人来试着浅答一下。&br&&br&PCM编码的未压缩的WAV文件所占容量是有公式可计算的：&br&&br&所占容量=（采样频率＊采样位数＊声道）＊时间/8（因为1字节=8bit）&br&&br&其中的采样位数，是指每一次采样周期内A/D转换时，转换后的信号所被抽取的位数。&br&&br&而采样频率指的是在A/D转换中，单位时间内对模拟信号采样的次数。&br&&br&立体声WAV格式的采样数据为16位的INT值，高八位代表左声道，低八位代表右声道，所以可以把它看做8＊2。&br&&br&从公式可以看出，PCM编码的未压缩的WAV的大小不随文件本身所含信息量的多少而变化，WAV文件在未压缩的PCM编码下是用波形幅度来表示音频的。&br&&br&不管你是一整段空白音频，还是一整段嘿咻嘿咻 （好像哪里不太对？） ，所含的信息均被一视同仁。&br&&br&可以粗略的说，在定量条件下，WAV格式所占用的空间只与时间有关。&br&&br&而有损压缩格式，则大不相同了。&br&&br&MPEG-1 Audio Layer-3，MPEG-4 AAC等格式均使用了特定的心理声学算法，即扔掉那些人耳不易感受到的信息，并用特殊的表达空信息的方式占位来减少所包含的信息。&br&&br&例如MPEG-1 Audio Layer-3编码时会切除高频并降低时间分辨率，MPEG-4 AAC会使用TNS和PNS算法等等。&br&&br&WAV格式给人的印象是庞大的原始数据，其实这是误解，WAV格式也是有许多的压缩版本的。比如IMA和Microsoft的ADPCM，ITU的各类标准等等。&br&&br&哦，对了，还有你们离不开的电话，GSM 6.10标准，同样是用于WAV的。&br&&br&总的来说，有损格式编码是以丢掉原始信息的方式来获得更小的文件。 &br&&br&由于信息的损失不可逆转，就算它再被以PCM的未压缩的WAV的形式表达，WAV也不会关心其中的音质是否有任何损失，它只关心那几个参数，因此文件又“胖”起来了，但是音质不会有任何提升，换句话说，做的是无用功。&br&&br&先写这么多，有时间再补……&br&&br&（全文手机手打……已然抽风了……）&br&&br&( *?ω?)?╰ひ╯&br&&br&========以上写========&br&&br&以下这段话是对某些知乎用户说的：&br&&br&回答问题请有自己的干货，请尊重他人的回答。&br&&br&我们常说，知其然，知其所以然。回答的问题不光是给提问的人看的，还是给许多来讨论分享知识的人看的。&br&&br&“压缩”他人的答案且振振有词，不但是取巧之途，而且完全不尊重他人的辛劳，真的令人生厌。&br&&br&希望这种情况以后不要再有了。&br&&br&========以上写========
几位已有的回答都很不错，但是略微有些跑题了。题主问的是“为什么”WAV格式的文件占用空间如此大？ 鄙人来试着浅答一下。PCM编码的未压缩的WAV文件所占容量是有公式可计算的：所占容量=（采样频率＊采样位数＊声道）＊时间/8（因为1字节=8bit）其中的采样…
来自子话题：
因为 7-zip 不足够好，他们不知道还有这个软件。我目前没有见过比这个软件更好的压缩软件了。用了这个软件让我感觉自己能有尊严地解压缩。&br&&a class=& wrap external& href=&///?target=http%3A///bandizip/cn/& target=&_blank& rel=&nofollow noreferrer&&Bandizip - All-In-One Free Zip Archiver&i class=&icon-external&&&/i&&/a&&br&用了一下发现以前用过的压缩软件就像煞笔一样，包括 7-zip。&br&7-zip 优秀在算法和开源，易用性 GUI 什么确实比不过国产的那些贴心的萨比软件，不过我一直在捏着鼻子用。&br&----------&br&补充一下 7-zip 的缺点&br&&ul&&li&图标丑（有软件改就是了）&/li&&li&界面丑&/li&&li&解压缩窗口丑&/li&&li&没有只能解压缩（压缩文件里面有多个文件就创建一个文件夹，只有一个文件就直接解压到当前目录）&/li&&li&直接从软件界面拖拽到目录下，7-zip 的逻辑很抽搐，先解压到临时文件夹在移动到目标文件夹，一步到位不好吗？&/li&&/ul&----------&br&&br&知道了这个 Bandizip 以后我立马卸载了 7-zip，在我看来除了不开源以外没什么缺点了。（之前抱怨过默认图标太丑，结果发现有提供好几套图标主题下载。）&br&&br&&img data-rawheight=&601& data-rawwidth=&647& src=&/c85a7bb0ecaff73353e90_b.jpg& class=&origin_image zh-lightbox-thumb& width=&647& data-original=&/c85a7bb0ecaff73353e90_r.jpg&&&img data-rawheight=&478& data-rawwidth=&731& src=&/7ddf396bbabc9c_b.jpg& class=&origin_image zh-lightbox-thumb& width=&731& data-original=&/7ddf396bbabc9c_r.jpg&&还有 OS X 版本哦：&br&&img data-rawheight=&276& data-rawwidth=&424& src=&/7d51d3770caff59e428b_b.jpg& class=&origin_image zh-lightbox-thumb& width=&424& data-original=&/7d51d3770caff59e428b_r.jpg&&&br&----------&br&虽然感觉 &a class=&member_mention& href=&///people/669bd058f817cba36a1a6af80ae6423f& data-hash=&669bd058f817cba36a1a6af80ae6423f& data-tip=&p$b$669bd058f817cba36a1a6af80ae6423f&&@冰海&/a& 的需求有点蛋疼，不过贴张图：&br&&img data-rawheight=&166& data-rawwidth=&164& src=&/5fbbe716dd07ecb724fce41_b.jpg& class=&content_image& width=&164&&
因为 7-zip 不足够好，他们不知道还有这个软件。我目前没有见过比这个软件更好的压缩软件了。用了这个软件让我感觉自己能有尊严地解压缩。用了一下发现以前用过的压缩软件就像煞笔一样，包括 7-zip。7-zip 优秀在算…
...为什么我觉得此小三信息就是各种.torrent的集合体...
...为什么我觉得此小三信息就是各种.torrent的集合体... O_o
来自子话题：
Winrar：财报表示，好像中国没什么人用啊，有空再翻译吧。
Winrar：财报表示，好像中国没什么人用啊，有空再翻译吧。
因为读取速度不够快。&br&&br&要让解压缩时cpu达到100%，目前只有用ram内存做硬盘，其它存储器基本达不到。&br&&br&ssd的读取速度对于解压缩来说还是太慢太慢了，cpu根本喂不饱。&br&&br&实测用ramdisk+7zip可以达到100占用。
因为读取速度不够快。要让解压缩时cpu达到100%，目前只有用ram内存做硬盘，其它存储器基本达不到。ssd的读取速度对于解压缩来说还是太慢太慢了，cpu根本喂不饱。实测用ramdisk+7zip可以达到100占用。
已有帐号？
社交帐号登录
无法登录？
社交帐号登录