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

Question

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

我对此没有意见，但我不满意的是 GZipStream/DeflateStream.Write() 的计数参数的记录行为:“要写入的最大压缩字节数。”通常的做法(除非按 block 压缩)是传入输入数据的长度:

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 语句不会写出整个压缩数据流，只写出它的第一个 data.Length 字节。我可以将缓冲区大小加倍，但对于大型数据集来说有点浪费，而且我不喜欢猜测。

有更好的方法吗？

Answer 1

我很确定这是文档中的一个错误。早期版本中的文档显示为“压缩的字节数。”，这与所有其他流的工作方式一致。

对 Read 方法的文档进行了相同的更改，这是有意义的，但我认为更改是错误地对 Write 的文档进行的> 方法。有人更正了 Read 方法的文档，并认为同样的更正也适用于 Write 方法。

流的 Read 方法的正常行为是它返回的数据少于请求的数据，并且该方法返回缓冲区中实际放置的字节数。另一方面，Write 方法总是写入所有指定的数据。在任何实现中写入较少数据的方法都没有任何意义。由于该方法没有返回值，因此无法返回写入的字节数。

指定的计数不是输出的大小，而是您发送到方法中的数据的大小。如果输出大于输入，它仍然会全部写入流。

编辑:

我在 MSDN Library 中的方法文档的社区内容中添加了关于此的评论。让我们看看微软是否会跟进......