从流创建字节数组
从输入流创建字节数组的首选方法是什么?
这是我当前使用 .NET 3.5 的解决方案。
Stream s;
byte[] b;
using (BinaryReader br = new BinaryReader(s))
{
b = br.ReadBytes((int)s.Length);
}
读取和写入流块仍然是一个更好的主意吗?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(19)
这实际上取决于您是否可以信任
s.Length
。 对于许多流,您只是不知道会有多少数据。 在这种情况下 - 在 .NET 4 之前 - 我会使用这样的代码:对于 .NET 4 及更高版本,我会使用
Stream.CopyTo
,这基本上相当于我代码中的循环 - 创建MemoryStream
,调用stream.CopyTo(ms)
,然后返回ms.ToArray()
。 任务完成。我也许应该解释一下为什么我的答案比其他人更长。
Stream.Read
不保证它会读取它所要求的所有内容。 例如,如果您正在从网络流中读取数据,它可能会读取一个数据包的值然后返回,即使很快就会有更多数据。BinaryReader.Read
将一直持续到流结束或指定的大小,但您仍然必须知道开始的大小。上述方法将继续读取(并复制到 MemoryStream 中),直到用完数据。 然后,它要求 MemoryStream 返回数组中数据的副本。 如果您知道起始大小 - 或者认为您知道大小,但不确定 - 您可以将
MemoryStream
构造为起始大小。 同样,您可以在末尾进行检查,看看流的长度是否与缓冲区的大小相同(由MemoryStream.GetBuffer
) 那么你可以只返回缓冲区。 所以上面的代码并没有完全优化,但至少是正确的。 它不承担关闭流的任何责任 - 调用者应该这样做。请参阅本文了解更多信息(以及替代实现)。
It really depends on whether or not you can trust
s.Length
. For many streams, you just don't know how much data there will be. In such cases - and before .NET 4 - I'd use code like this:With .NET 4 and above, I'd use
Stream.CopyTo
, which is basically equivalent to the loop in my code - create theMemoryStream
, callstream.CopyTo(ms)
and then returnms.ToArray()
. Job done.I should perhaps explain why my answer is longer than the others.
Stream.Read
doesn't guarantee that it will read everything it's asked for. If you're reading from a network stream, for example, it may read one packet's worth and then return, even if there will be more data soon.BinaryReader.Read
will keep going until the end of the stream or your specified size, but you still have to know the size to start with.The above method will keep reading (and copying into a
MemoryStream
) until it runs out of data. It then asks theMemoryStream
to return a copy of the data in an array. If you know the size to start with - or think you know the size, without being sure - you can construct theMemoryStream
to be that size to start with. Likewise you can put a check at the end, and if the length of the stream is the same size as the buffer (returned byMemoryStream.GetBuffer
) then you can just return the buffer. So the above code isn't quite optimised, but will at least be correct. It doesn't assume any responsibility for closing the stream - the caller should do that.See this article for more info (and an alternative implementation).
虽然 Jon 的答案是正确的,但他正在重写
CopyTo
中已存在的代码。 因此,对于 .Net 4,请使用 Sandip 的解决方案,但对于以前版本的 .Net,请使用 Jon 的答案。 Sandip 的代码可以通过使用“using”进行改进,因为在许多情况下,CopyTo
中的异常很可能会发生,并且会使MemoryStream
未被释放。While Jon's answer is correct, he is rewriting code that already exists in
CopyTo
. So for .Net 4 use Sandip's solution, but for previous version of .Net use Jon's answer. Sandip's code would be improved by use of "using" as exceptions inCopyTo
are, in many situations, quite likely and would leave theMemoryStream
not disposed.只是想指出,如果您有 MemoryStream,则您已经拥有了 Memorystream.ToArray() 。
此外,如果您正在处理未知或不同子类型的流,并且可以收到 MemoryStream,则可以针对这些情况中继所述方法,并仍然对其他情况使用接受的答案,如下所示:
Just want to point out that in case you have a MemoryStream you already have
memorystream.ToArray()
for that.Also, if you are dealing with streams of unknown or different subtypes and you can receive a
MemoryStream
, you can relay on said method for those cases and still use the accepted answer for the others, like this:只是我的几美分...我经常使用的做法是将这样的方法组织为自定义帮助程序,
将命名空间添加到配置文件并在您希望的任何地方使用它
just my couple cents... the practice that I often use is to organize the methods like this as a custom helper
add namespace to the config file and use it anywhere you wish
您可以简单地使用 MemoryStream 类的 ToArray() 方法,例如
You can simply use ToArray() method of MemoryStream class, for ex-
您甚至可以通过扩展使其更加精美:
然后将其作为常规方法调用:
You can even make it fancier with extensions:
And then call it as a regular method:
我收到 Bob(即提问者)代码的编译时错误。 Stream.Length 是一个 long 值,而 BinaryReader.ReadBytes 则采用一个整数参数。 就我而言,我不希望处理足够大的流以需要长精度,因此我使用以下内容:
I get a compile time error with Bob's (i.e. the questioner's) code. Stream.Length is a long whereas BinaryReader.ReadBytes takes an integer parameter. In my case, I do not expect to be dealing with Streams large enough to require long precision, so I use the following:
将两个得票最高的答案合并到一个扩展方法中:
Combinig two of the most up-voted answers into an extension method:
如果有人喜欢它,这里是一个仅 .NET 4+ 的解决方案,它形成为扩展方法,无需对 MemoryStream 进行不必要的 Dispose 调用。 这是一个无可救药的微不足道的优化,但值得注意的是,未能处理 MemoryStream 并不是真正的失败。
In case anyone likes it, here is a .NET 4+ only solution formed as an extension method without the needless Dispose call on the MemoryStream. This is a hopelessly trivial optimization, but it is worth noting that failing to Dispose a MemoryStream is not a real failure.
如果流支持Length属性,则可以直接创建字节数组。 优点是
MemoryStream.ToArray
创建数组两次。 另外,缓冲区中可能有一些未使用的额外字节。 该解决方案分配所需的确切数组。 如果流不支持Length
属性,它将抛出NotSupportedException
异常。还值得注意的是,数组不能大于 int.MaxValue。
根据流是否支持查找在两个版本之间切换的完整代码。 它包括对
位置
和不可靠的长度
的检查。 这可能会稍微降低速度。 在我的测试中,ToArrayAsyncDirect
的速度比ToArrayAsyncGeneral
快大约 3 倍。If a stream supports the Length property, a byte array can be directly created. The advantage is that
MemoryStream.ToArray
creates the array twice. Plus, probably some unused extra bytes in the buffer. This solution allocates the exact array needed. If the stream does not support theLength
property, it will throwNotSupportedException
exception.It is also worth noting that arrays cannot be bigger than int.MaxValue.
Complete code which switches between both versions based on whether the stream supports seeking or not. It includes checks for
Position
and unreliableLength
. That might slightly reduce speed. In my testsToArrayAsyncDirect
is about 3 times faster compared toToArrayAsyncGeneral
.上面的方法没问题……但是当您通过 SMTP 发送内容时(如果需要的话),您会遇到数据损坏的情况。 我已经更改为其他内容,这将有助于正确地逐字节发送:
'
The one above is ok...but you will encounter data corruption when you send stuff over SMTP (if you need to). I've altered to something else that will help to correctly send byte for byte:
'
创建一个辅助类并在您希望使用它的任何地方引用它。
Create a helper class and reference it anywhere you wish to use it.
这是我正在使用、测试并且运行良好的功能。
请记住,“input”不应为空,“input.position”应在读取之前重置为“0”,否则会破坏读取循环,并且不会读取任何内容以转换为数组。
This is the function which I am using, tested and worked well.
please bear in mind that 'input' should not be null and 'input.position' should reset to '0' before reading otherwise it will break the read loop and nothing will read to convert to array.
在命名空间 RestSharp.Extensions 中有一个方法 ReadAsBytes。 此方法内部使用 MemoryStream,并且与本页上的一些示例中的代码相同,但当您使用 RestSharp 时,这是最简单的方法。
In namespace RestSharp.Extensions there is method ReadAsBytes. Inside this method is used MemoryStream and there is the same code like in some examples on this page but when you are using RestSharp this is easiest way.
由于此答案没有现代(即异步)版本,因此这是我用于此目的的扩展方法:
优化基于
ToArray
的源代码调用一些内部方法。Since there's no modern (i.e. async) version of this answer, this is the extension method I use for this purpose:
The optimization is based on the fact the source code for
ToArray
calls some internal methods.您可以使用此扩展方法。
You can use this extension method.
我能够让它在一行上工作:
正如 johnnyRose 所澄清的,上面的代码仅适用于 MemoryStream
i was able to make it work on a single line:
as clarified by johnnyRose, Above code will only work for MemoryStream