.net - 如果用GZipStream或DeflateStream压缩的数据长于原始数据怎么办？

我不是格式方面的专家，但我猜测由于格式化开销，某些用于压缩数据的输入数据实际上可能更长。

我可以接受，但是我不能接受的是GZipStream / DeflateStream.Write（）的count参数的已记录行为：“要写入的最大压缩字节数”。通常的做法（除非分块压缩）是传入输入数据的长度：

public static byte[] Compress(byte[] data)
{
    using (var compressed = new IO.MemoryStream(data.Length))
    {
        using (var compressor = new IO.Compression.DeflateStream(compressed, IO.Compression.CompressionMode.Compress))
            compressor.Write(data, 0, data.Length);
        return compressed.ToArray();
    }
}

在我所谈论的边缘情况下，write语句不会写出整个压缩数据流，而只是写出第一个数据。我可以将缓冲区大小增加一倍，但是对于大型数据集来说有点浪费，而且无论如何我都不喜欢猜测。

有一个更好的方法吗？

最佳答案

我很确定这是文档中的错误。早期版本中的文档显示为“已压缩字节数。”，这与所有其他流的工作方式一致。
对Read方法的文档进行了相同的更改，这很有意义，但我认为更改是对Write方法的文档错误地进行的。有人更正了Read方法的文档，并认为相同的更正也将应用于Write方法。
流的Read方法的正常行为是它返回的数据少于请求的数据，并且该方法返回实际放置在缓冲区中的字节数。另一方面，Write方法始终写入指定的所有数据。该方法在任何实现中写入更少的数据都没有任何意义。由于该方法没有返回值，因此无法返回写入的字节数。
指定的计数不是输出的大小，而是您发送到方法中的数据的大小。如果输出大于输入，则仍将全部写入流中。
编辑：
我在MSDN Library中的方法文档的社区内容中添加了对此的评论。让我们看看微软是否会跟进...

关于.net - 如果用GZipStream或DeflateStream压缩的数据长于原始数据怎么办？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4799632/