这里说msdn.microsoft.com/en-us/library/system.io.stream.read.aspx Stream.Read
和Stream.Write
方法都自动推进流中的位置/偏移量,那么为什么这里的例子http://msdn.microsoft.com/en-us/library/system.io.stream.read.aspx和http://msdn.microsoft.com/en-us/library/system.io.filestream.read.aspx手动更改偏移量呢?
是否只在知道流大小的情况下设置循环中的偏移量,而在不知道流大小和使用缓冲区的情况下将其设置为0 ?
// Now read s into a byte buffer.
byte[] bytes = new byte[s.Length];
int numBytesToRead = (int) s.Length;
int numBytesRead = 0;
while (numBytesToRead > 0)
{
// Read may return anything from 0 to 10.
int n = s.Read(bytes, numBytesRead, 10);
// The end of the file is reached.
if (n == 0)
{
break;
}
numBytesRead += n;
numBytesToRead -= n;
}
和
using (GZipStream stream = new GZipStream(new MemoryStream(gzip), CompressionMode.Decompress))
{
const int size = 4096;
byte[] buffer = new byte[size];
using (MemoryStream memory = new MemoryStream())
{
int count = 0;
do
{
count = stream.Read(buffer, 0, size);
if (count > 0)
{
memory.Write(buffer, 0, count);
}
}
while (count > 0);
return memory.ToArray();
}
}
实际上是缓冲区的偏移量,而不是流的偏移量。
Edit(对已编辑的问题):
在您粘贴到问题中的所有代码片段中,我都没有看到设置了任何流偏移量。
我认为你错误地计算了要读取的字节数和接收的字节数。这个协议可能看起来很有趣(为什么你收到的字节比请求的少?),但是当你考虑到你可能从一个高延迟的面向数据包的源(想想:网络套接字)中读取时,它是有意义的。
您可能在一次突发中接收6个字符(来自TCP数据包),并且在下一次读取(当下一个数据包到达时)仅接收剩余的4个字符。
编辑回应你从评论链接的例子:
using (GZipStream stream = new GZipStream(new MemoryStream(gzip), CompressionMode.Decompress))
{
// ... snip
count = stream.Read(buffer, 0, size);
if (count > 0)
{
memory.Write(buffer, 0, count);
}
似乎编码人员使用了关于底层流实现的先验知识,即该流。Read将始终返回0 或请求的大小。在我看来,这是一个冒险的赌注。但如果GZipStream
的医生确实说明了这一点,那就没事了。但是,由于MSDN示例使用通用的Stream
变量,因此检查读取的确切字节数(方式)更正确。
第一个链接的例子以写和读的方式使用MemoryStream。位置在中间重置,因此先写入的数据将被读取:
Stream s = new MemoryStream();
for (int i = 0; i < 100; i++)
{
s.WriteByte((byte)i);
}
s.Position = 0;
链接的第二个示例没有设置流位置。如果它这样做,您通常会看到对Seek
的调用。你可能会混淆偏移到数据缓冲区与流的位置?