blocks|key|3425431|text|有可能您试图压缩的数据实际上是不可压缩的(或者您一开始就没有很多数据要压缩)。当数据中存在重复时，压缩效果最好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3425432|它可能更大，因为压缩方案添加了用于解密流的元数据，但由于数据不可压缩或没有大量数据可供压缩生效，这实际上会使情况变得更糟。|3425433|如果你做了像zip这样的事情，你会发现解压并不总是使事情变得更小。|3425434|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It's possible that the data you are trying to compress is not actually compressible (or you do not have a lot of data to compress to begin with). Compression works best when there are repetitions in the data.

It's probably bigger because the compression scheme is adding metadata used to decrypt the stream, but because the data is not compressible or there is not a lot of data for compression to take effect, it is actually making it worse.

If you did something like zip a zip file, you would find that decompression does not always make things smaller.

blocks|key|1903536|text|难道不应该是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1903537|using+(var+ms+=+new+DeflateStream(ms2,+CompressionMode.Compress,+true))|code-block|syntax|javascript|1903538|而不是|1903539|using+(var+ms+=+new+DeflateStream(ms,+CompressionMode.Compress,+true))|1903540|如果你想用DeflateStream装饰你的MemoryStream，它应该是这样的。|1903541|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Shouldn't it be

<pre><code>using (var ms = new DeflateStream(ms2, CompressionMode.Compress, true))
</code></pre>

instead of

<pre><code>using (var ms = new DeflateStream(ms, CompressionMode.Compress, true))
</code></pre>

If you want to decorate your MemoryStream with a DeflateStream, it should be this way arround.

blocks|key|1700300|text|小的数据块通常最终会变得更大，因为压缩算法使用了添加到输出中的代码表，或者需要更大的样本来找到足够的样本来处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1700301|你没做错什么。|1700302|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Small blocks of data often end up larger because the compression algorithm uses a code table that gets added to the output or it needs a bigger sample to find enough to work with.

You're not doing anything wrong.

blocks|key|1903564|text|数据扩展的程度是DeflateStream类中的一个错误。该错误也存在于GZipStream类中。请看我对这个问题的描述：Why+does+my+C#+gzip+produce+a+larger+file+than+Fiddler+or+PHP?。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1903565|不要使用微软提供的DeflateStream类。请改用DotNetZip，它提供了替换类。|1903566|当您尝试压缩不可压缩数据时，它将略微扩展，但仅扩展很小的量。来自正确写入的放气压缩器的最大扩展是5个字节加上百分之一的一小部分。zlib对不可压缩数据的扩展(默认设置为raw+deflate)是5字节%2B输入大小的0.03%25。如果您的304字节是不可压缩的，则应该从原始deflate压缩器(如DeflateStream+)中输出309字节。长度超过5或6字节的数据扩展1.9倍是一个错误。|1903567|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/11435200/why-does-my-c-sharp-gzip-produce-a-larger-file-than-fiddler-or-php/11435898#11435898|1|http://dotnetzip.codeplex.com/|2|http://zlib.net/^0|1P|1Q|0|0|R|9|1|0|1S|4|2|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|H|3|-4|5|6|7|15|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]|R|$5|K|L|M|C|$N|S]]]]

The degree to which your data is expanding is a bug in the DeflateStream class. The bug also exists in the GZipStream class. See my description of this problem here: <a href="https://stackoverflow.com/questions/11435200/why-does-my-c-sharp-gzip-produce-a-larger-file-than-fiddler-or-php/11435898#11435898">Why does my C# gzip produce a larger file than Fiddler or PHP?</a>.

Do not use the DeflateStream class provided by Microsoft. Use <a href="http://dotnetzip.codeplex.com/" rel="nofollow noreferrer">DotNetZip</a> instead, which provides replacement classes.

Incompressible data will expand slightly when you try to compress it, but only by a small amount. The maximum expansion from a properly written deflate compressor is five bytes plus a small fraction of a percent. <a href="http://zlib.net/" rel="nofollow noreferrer">zlib</a>'s expansion of incompressible data (with the default settings for raw deflate) is 5 bytes + 0.03% of the input size. Your 304 bytes, if incompressible, should come out as 309 bytes from a raw deflate compressor like DeflateStream. A factor of 1.9 expansion on something more than five or six bytes in length is a bug.

blocks|key|1903583|text|你在评论中回答了自己的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1903584|1903585|我不知道我更改了什么，但每次运行时数据都是随机生成的|blockquote|1903586|1903587|1903588|随机数据很难压缩。通常，当数据中有许多模式(如字典或网站中的文本)时，它可以很好地压缩。但对于压缩算法来说，最糟糕的情况是面对随机数据。真正的随机数据中没有任何模式；那么压缩算法如何能够压缩它呢？|1903589|下一件要考虑的事情是，某些压缩算法在存储数据的方式上有开销。它们通常有一些报头比特，后面跟着一些符号数据。对于随机数据，几乎不可能将数据压缩成其他形式，最终在数据之间散布着大量的头比特，除了说“下面的数据是这样表示的”之外，这些头比特没有任何用途。|1903590|根据压缩格式的不同，开销占总文件大小的百分比可能相对较小，也可能较大。不管是哪种情况，你都会有一些开销，这会使你的新文件比旧文件更大。|1903591|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|R|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|W|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|O|$]]

You answered your own question in your comment:

<blockquote>
 i dont know what i changed but the data is randomly made in every run
</blockquote>

Random data is hard to compress. In general, when data has many patterns within it (like the text from a dictionary or a website) then it compresses well. But the worse case for a compression algorithm is when you're faced with random data. Truly random data does not have any patterns in it; how then can a compression algorithm expect to be able to compress it?

The next thing to take into account is the fact that certain compression algorithms have overhead in how they store data. They usually have some header bits followed by some symbol data. With random data, it's almost impossible to compress the data into some other form and you end up with tons of header bits interspersed in between your data which serve no purpose other than to say "the following data is represented as such."

Depending on your compression format, the overhead as a percentage of the total file size can either be relatively small or large. In either case though, you will have overhead that will make your new file larger than your old one.

blocks|key|3337815|text|我没有留下评论的名声，但是压缩性能比你预期的更差的原因并不是由于本身的错误，而是明显的专利问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3337816|3337817|压缩级别不如其他应用程序的原因是，市场上最有效的压缩算法都是受专利保护的。另一方面，.net使用的是一种非专利技术。|blockquote|3337818|3337819|3337820|和|3337821|嗯，当我问到同样的问题时，我得到的解释(从MS的某个人那里)是，这与微软不能使用GZip算法而不修改它有关；由于专利/许可问题。|3337822|3337823|http://social.msdn.microsoft.com/Forums/fr-FR/c5f0b53c-a2d5-4407-b43b-9da8d39c01df/why-do-gzipstream-compression-ratio-so-bad?forum=netfxbcl|offset|length|3337824|最初，我怀疑微软的|3337825|实现；我知道他们实现了Deflate算法，它不是最有效的，但没有专利。|3337826|3337827|3337828|http://challenge-me.ws/post/2010/11/05/Do-Not-Take-Microsofts-Code-for-Granted.aspx|3337829|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|0|0|0|0|0|0|0|0|3W|0|0|0|0|0|0|0|2B|1|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|18|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1B|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1C|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1E|8|@]|9|@$O|1F|P|1G|1|1H]]|A|$]]|$1|Q|3|R|5|6|7|1I|8|@]|9|@]|A|$]]|$1|S|3|T|5|E|7|1J|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1M|8|@]|9|@$O|1N|P|1O|1|1P]]|A|$]]|$1|Y|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]]|Z|$10|$5|11|12|13|A|$14|N]]|15|$5|11|12|13|A|$14|X]]]]

I don't have the reputation to leave a comment, however the reason why compression performance is worse than you would expect is not due to a bug per se, but apparently a patent one:

<blockquote>
 The reason for the compression level not being as good as with some other applications is that the most efficient compression algorithms on the market are all patent-protected. .net on the other hand uses a non-patented one.
</blockquote>

and

<blockquote>
 Well, the explanation I got (from someone at MS), when I asked the same thing, was that it had to do with Microsoft not being able to use the GZip algorithm without modifying it; due to patent/licensing issues. 
</blockquote>

<a href="http://social.msdn.microsoft.com/Forums/fr-FR/c5f0b53c-a2d5-4407-b43b-9da8d39c01df/why-do-gzipstream-compression-ratio-so-bad?forum=netfxbcl" rel="nofollow">http://social.msdn.microsoft.com/Forums/fr-FR/c5f0b53c-a2d5-4407-b43b-9da8d39c01df/why-do-gzipstream-compression-ratio-so-bad?forum=netfxbcl</a>

<blockquote>
 Initial I suspected Microsoft’s gzip implementation; I knew that they implemented the Deflate algorithm which isn’t the most effective but is free of patents.
</blockquote>

<a href="http://challenge-me.ws/post/2010/11/05/Do-Not-Take-Microsofts-Code-for-Granted.aspx" rel="nofollow">http://challenge-me.ws/post/2010/11/05/Do-Not-Take-Microsofts-Code-for-Granted.aspx</a>

I wanted to compress some data so i thought i'd run the stream by deflate

It went from 304 bytes to 578. Thats 1.9x larger. I was trying to compress it.....
What am i doing wrong here?

<pre><code>using (MemoryStream ms2 = new MemoryStream())
using (var ms = new DeflateStream(ms2, CompressionMode.Compress, true))
{
 ms.WriteByte(1);
 ms.WriteShort((short)txtbuf.Length);
 ms.Write(txtbuf, 0, txtbuf.Length);
 ms.WriteShort((short)buf2.Length);
 ms.Write(buf2, 0, buf2.Length);
 ms.WriteShort((short)buf3.Length);
 ms.Write(buf3, 0, buf3.Length);
 ms.Flush();
 result_buf = ms2.ToArray();
}
</code></pre>

Why is deflate making my data BIGGER?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我想压缩一些数据，所以我想我应该通过deflate来运行流它从304字节增加到578字节。这是1.9倍大。我在试着压缩它……我在这里做错了什么？using (MemoryStream ms2 = new MemoryStream())using (var ms = new DeflateStream(ms2, Comp...

问为什么deflate让我的数据变得更大？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么deflate让我的数据变得更大？EN