如何将 GZipStream 与 System.IO.MemoryStream 结合使用?
我在使用这个测试函数时遇到问题,我在内存中获取字符串,压缩它,然后解压缩它。压缩效果很好,但我似乎无法让解压发挥作用。
//Compress
System.IO.MemoryStream outStream = new System.IO.MemoryStream();
GZipStream tinyStream = new GZipStream(outStream, CompressionMode.Compress);
mStream.Position = 0;
mStream.CopyTo(tinyStream);
//Decompress
outStream.Position = 0;
GZipStream bigStream = new GZipStream(outStream, CompressionMode.Decompress);
System.IO.MemoryStream bigStreamOut = new System.IO.MemoryStream();
bigStream.CopyTo(bigStreamOut);
//Results:
//bigStreamOut.Length == 0
//outStream.Position == the end of the stream.
我相信 bigStream out 至少应该有数据,特别是如果我的源流 (outStream) 正在被读取。这是 MSFT 的错误还是我的错误?
I am having an issue with this test function where I take an in memory string, compress it, and decompress it. The compression works great, but I can't seem to get the decompression to work.
//Compress
System.IO.MemoryStream outStream = new System.IO.MemoryStream();
GZipStream tinyStream = new GZipStream(outStream, CompressionMode.Compress);
mStream.Position = 0;
mStream.CopyTo(tinyStream);
//Decompress
outStream.Position = 0;
GZipStream bigStream = new GZipStream(outStream, CompressionMode.Decompress);
System.IO.MemoryStream bigStreamOut = new System.IO.MemoryStream();
bigStream.CopyTo(bigStreamOut);
//Results:
//bigStreamOut.Length == 0
//outStream.Position == the end of the stream.
I believe that bigStream out should at least have data in it, especially if my source stream (outStream) is being read. is this a MSFT bug or mine?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(10)
您的代码中发生的情况是您不断打开流,但从未关闭它们。
在第 2 行中,您创建一个
GZipStream
。该流不会向底层流写入任何内容,直到它认为时机成熟。您可以通过关闭它来告诉它。但是,如果您关闭它,它也会关闭底层流 (
outStream
)。因此,您不能对其使用mStream.Position = 0
。您应该始终使用
using
来确保所有流都关闭。这是您的代码的一个变体,可以工作。What happens in your code is that you keep opening streams, but you never close them.
In line 2, you create a
GZipStream
. This stream will not write anything to the underlying stream until it feels it’s the right time. You can tell it to by closing it.However, if you close it, it will close the underlying stream (
outStream
) too. Therefore you can’t usemStream.Position = 0
on it.You should always use
using
to ensure that all your streams get closed. Here is a variation on your code that works.这是一个已知问题:http://blogs.msdn .com/b/bclteam/archive/2006/05/10/592551.aspx
我对你的代码做了一些更改,所以这个可以工作:
This is a known issue: http://blogs.msdn.com/b/bclteam/archive/2006/05/10/592551.aspx
I have changed your code a bit so this one works:
与
MemoryStream
进行压缩和解压缩的方法是:这使得压缩/解压缩的流保持打开状态,因此在创建后即可使用。
The way to compress and decompress to and from a
MemoryStream
is:This leaves the compressed / decompressed stream open and as such usable after creating it.
另一种实现,在 VB.NET 中:
Another implementation, in VB.NET:
如果您尝试使用 MemoryStream(例如将其传递到另一个函数)但收到异常“无法访问关闭的流”。然后还有另一个 GZipStream 构造函数可以帮助您。
通过向leaveOpen参数传递true,您可以指示GZipStream在处理自身后使流保持打开状态,默认情况下它会关闭目标流(这是我没想到的)。 https://msdn.microsoft.com/en-我们/library/27ck2z1y(v=vs.110).aspx
If you are attempting to use the MemoryStream (e.g. passing it into another function) but receiving the Exception "Cannot access a closed Stream." then there is another GZipStream constructor you can use that will help you.
By passing in a true to the leaveOpen parameter, you can instruct GZipStream to leave the stream open after disposing of itself, by default it closes the target stream (which I didn't expect). https://msdn.microsoft.com/en-us/library/27ck2z1y(v=vs.110).aspx
我遇到一个问题,
*.CopyTo(stream)*
最终会得到byte[0]
结果。解决方案是在调用
.CopyTo(stream)
之前添加.Position=0
在这里回答
我还使用
BinaryFormatter
如果在反序列化之前未将位置设置为 0,则会抛出“解析完成之前遇到流结束”异常。在这里回答
这是对我有用的代码。
I had an issue where
*.CopyTo(stream)*
would end up with abyte[0]
result.The solution was to add
.Position=0
before calling.CopyTo(stream)
Answered here
I also use a
BinaryFormatter
that would throw an 'End of stream encountered before parsing was completed' exception if position was not set to 0 before deserialization.Answered here
This is the code that worked for me.
我想我会与有兴趣在 PowerShell 上重现此问题的任何人分享这个答案,该代码主要灵感来自 Timwi 的有用答案,然而不幸的是,到目前为止,还没有实现 using 语句 就像在 PowerShell 的 C# 上一样,因此需要在输出之前手动处理流。
以下功能需要 PowerShell 5.0+。
使用
语句和-Encoding
参数的ArgumentCompleter
。这两个函数的改进版本以及从文件路径压缩和从文件路径扩展可以在此存储库 以及 PowerShell 库中。
对于 长度 的小比较,查询 Loripsum API:
I thought I would share this answer for anyone interested in reproducing this on PowerShell, the code is mostly inspired from Timwi's helpful answer, however unfortunately as of now there is no implementation for the using statement like on C# for PowerShell, hence the need to manually dispose the streams before output.
Functions below requires PowerShell 5.0+.
using
statements andArgumentCompleter
for-Encoding
Parameter.Improved versions of these 2 functions as well as Compression From File Path and Expansion from File Path can be found in this repo as well as in the PowerShell Gallery.
And for the little Length comparison, querying the Loripsum API:
如果您仍然需要它,您可以使用带有布尔参数的 GZipStream 构造函数(有两个这样的构造函数)并在那里传递 true 值:
在这种情况下,当您关闭 tynyStream 时,您的输出流仍将打开。不要忘记复制数据:
现在你已经有了带有压缩数据的内存流 outStream
错误和亲吻祝你
好运
If you still need it, you can use GZipStream constructor wit boolean argument (there are two such constructors) and pass true value there:
In that case, when you close your tynyStream, your out stream will be still opened. Don't forget to copy data:
Now you've got memory stream outStream with zipped data
Bugs and kisses for U
Good luck
请参考下面的链接,避免使用双MemoryStream。
https://stackoverflow.com/a/53644256/1979406
Please refer to below link, It is avoid to use double MemoryStream.
https://stackoverflow.com/a/53644256/1979406