ChatGPT解决这个技术问题 Extra ChatGPT

Creating a byte array from a stream

What is the prefered method for creating a byte array from an input stream?

Here is my current solution with .NET 3.5.

Stream s;
byte[] b;

using (BinaryReader br = new BinaryReader(s))
{
    b = br.ReadBytes((int)s.Length);
}

Is it still a better idea to read and write chunks of the stream?

Of course, another question is should you create a byte[] from a stream... for large data, it is preferable to treat the stream as, well, a stream!
Indeed you should probably use a stream instead of a byte[]. But there are some system APIs that don't support streams. For example, you can't create a X509Certificate2 from a stream, you have to give it a byte[] (or a string). In this case it's fine since a x509 certificate is probably not large data.
Doesn't the Binary Reader attach a UTF-8 encoding to the stream? Won't that be a problem if you aren't reading text (like if you're reading an image, etc)? docs.microsoft.com/en-us/dotnet/api/…

J
Jon Skeet

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:

public static byte[] ReadFully(Stream input)
{
    byte[] buffer = new byte[16*1024];
    using (MemoryStream ms = new MemoryStream())
    {
        int read;
        while ((read = input.Read(buffer, 0, buffer.Length)) > 0)
        {
            ms.Write(buffer, 0, read);
        }
        return ms.ToArray();
    }
}

With .NET 4 and above, I'd use Stream.CopyTo, which is basically equivalent to the loop in my code - create the MemoryStream, call stream.CopyTo(ms) and then return ms.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 the MemoryStream 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 the MemoryStream 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 by MemoryStream.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, it may be worth mentioning yoda.arachsys.com/csharp/readbinary.html
@Jeff: We don't really have the context here, but if you've been writing to a stream, then yes you need to "rewind" it before reading. There's just one "cursor" saying where you are within the stream - not one for reading and a separate one for writing.
@Jeff: It's the responsibility of the caller. After all, the stream may not be seekable (e.g. a network stream) or there may simply be no need to rewind it.
Could i ask why 16*1024 specifically?
@just_name: I don't know if this has any significance, but (16*1024) happens to be half of Int16.MaxValue :)
N
Nursnaaz

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 in CopyTo are, in many situations, quite likely and would leave the MemoryStream not disposed.

public static byte[] ReadFully(Stream input)
{
    using (MemoryStream ms = new MemoryStream())
    {
        input.CopyTo(ms);
        return ms.ToArray();
    }
}

What different does it make between your answer and Jon's? Also I must do this input.Position=0 for the CopyTo to work.
@nathan , readig a file from web client (filizesize=1mb) - the iis will have to load the whole 1mb to its memory right ?
@Jeff, my answer will only work on .Net 4 or above, Jons will work on lower versions by rewriting functionality provided to us in the later version. You're correct that CopyTo will only copy from the current position, if you have a Seekable stream and you want to copy from the beginning then you can move to the beginning using your code or input.Seek(0, SeekOrigin.Begin), though in many cases your stream may not be Seekable.
it might be worth checking if input is already a MemorySteam and short circuiting. I know it would be stupid of the caller to pass a MemoryStream but ...
@Jodrell, Exactly so. If you're copying millions of small streams into memory and one of them is a MemoryStream then whether the optimisation makes sense in your context is the comparison of the time taken to do millions of type conversions against the time taken to copy the one that's a MemoryStream into another MemoryStream.
m
meJustAndrew

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:

public static byte[] StreamToByteArray(Stream stream)
{
    if (stream is MemoryStream)
    {
        return ((MemoryStream)stream).ToArray();                
    }
    else
    {
        // Jon Skeet's accepted answer 
        return ReadFully(stream);
    }
}

Huh, what are all the upvotes for? Even with the most generous assumptions, this only works for streams that are already MemoryStreams. Of course the example is also obviously incomplete, in how it's using an uninitialized variable.
That's right, thanks for pointing that out. The point still stands for MemoryStream though, so I fixed it to reflect that.
Just mention that for MemoryStream another possibility is MemoryStream.GetBuffer(), although there are some gotchas involved. See stackoverflow.com/questions/1646193/… and krishnabhargav.blogspot.dk/2009/06/…
This actually introduces a bug into Skeet's code; If you call stream.Seek(1L, SeekOrigin.Begin), before you invoke readfully, if the stream is a memory stream you will get 1 more byte than if it is any other stream. If the caller expects to read from where the current position is to the end of the stream then you must not use CopyTo or ToArray(); In most cases this will not be an issue, but if the caller doesn't know about this quirky behavior they will be confused.
S
Sandip Patel
MemoryStream ms = new MemoryStream();
file.PostedFile.InputStream.CopyTo(ms);
var byts = ms.ToArray();
ms.Dispose();

MemoryStream should be created with "new MemoryStream(file.PostedFile.ContentLength)" to avoid memory fragmentation.
M
Mr. Pumpkin

just my couple cents... the practice that I often use is to organize the methods like this as a custom helper

public static class StreamHelpers
{
    public static byte[] ReadFully(this Stream input)
    {
        using (MemoryStream ms = new MemoryStream())
        {
            input.CopyTo(ms);
            return ms.ToArray();
        }
    }
}

add namespace to the config file and use it anywhere you wish


Note that this will not work in .NET 3.5 and below as CopyTo wasn't available on Stream until 4.0.
N
Nilesh Kumar

You can simply use ToArray() method of MemoryStream class, for ex-

MemoryStream ms = (MemoryStream)dataInStream;
byte[] imageBytes = ms.ToArray();

this will only work if dataInStream is already a MemoryStream
M
Michal T

You can even make it fancier with extensions:

namespace Foo
{
    public static class Extensions
    {
        public static byte[] ToByteArray(this Stream stream)
        {
            using (stream)
            {
                using (MemoryStream memStream = new MemoryStream())
                {
                     stream.CopyTo(memStream);
                     return memStream.ToArray();
                }
            }
        }
    }
}

And then call it as a regular method:

byte[] arr = someStream.ToByteArray()

I think it's a bad idea to put the input stream in a using block. That responsibility should rest with the calling procedure.
B
Brian Hinchey

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:

Stream s;
byte[] b;

if (s.Length > int.MaxValue) {
  throw new Exception("This stream is larger than the conversion algorithm can currently handle.");
}

using (var br = new BinaryReader(s)) {
  b = br.ReadBytes((int)s.Length);
}

S
SensorSmith

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.

public static class StreamHelpers
{
    public static byte[] ReadFully(this Stream input)
    {
        var ms = new MemoryStream();
        input.CopyTo(ms);
        return ms.ToArray();
    }
}

N
NothinRandom

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: '

using System;
using System.IO;

        private static byte[] ReadFully(string input)
        {
            FileStream sourceFile = new FileStream(input, FileMode.Open); //Open streamer
            BinaryReader binReader = new BinaryReader(sourceFile);
            byte[] output = new byte[sourceFile.Length]; //create byte array of size file
            for (long i = 0; i < sourceFile.Length; i++)
                output[i] = binReader.ReadByte(); //read until done
            sourceFile.Close(); //dispose streamer
            binReader.Close(); //dispose reader
            return output;
        }'

I don't see where this code avoids data corruption. Can you explain it?
Let's say that you have a picture and you want to send it via SMTP. You'll probably use base64 encoding. For some reason, the file gets corrupted if you break it up as bytes. However, using a binary reader will allow the file to be successfully sent.
Somewhat old, but I felt this bears mentioning - the implementation @NothinRandom provides works with strings, not streams. It would probably be simplest to just use File.ReadAllBytes in this case, though.
Downvote because of dangerous code style (no automatic Dispose/using).
Sadly only -1 allowed, nothing to do with the question, file name parameter named input, not disposing, no reading buffer, no filemode, and binary reader to read byte by byte why?
D
Draken

Create a helper class and reference it anywhere you wish to use it.

public static class StreamHelpers
{
    public static byte[] ReadFully(this Stream input)
    {
        using (MemoryStream ms = new MemoryStream())
        {
            input.CopyTo(ms);
            return ms.ToArray();
        }
    }
}

W
Wieslaw Olborski

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.

using RestSharp.Extensions;
var byteArray = inputStream.ReadAsBytes();

F
Fred.S

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.

    public static byte[] StreamToByteArray(Stream input)
    {
        if (input == null)
            return null;
        byte[] buffer = new byte[16 * 1024];
        input.Position = 0;
        using (MemoryStream ms = new MemoryStream())
        {
            int read;
            while ((read = input.Read(buffer, 0, buffer.Length)) > 0)
            {
                ms.Write(buffer, 0, read);
            }
            byte[] temp = ms.ToArray();

            return temp;
        }
    }

a
adsamcik

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 the Length property, it will throw NotSupportedException exception.

It is also worth noting that arrays cannot be bigger than int.MaxValue.

public static async Task<byte[]> ToArrayAsync(this Stream stream)
{
    var array = new byte[stream.Length];
    await stream.ReadAsync(array, 0, (int)stream.Length);
    return array;
}

Complete code which switches between both versions based on whether the stream supports seeking or not.

/// <summary>
/// Converts stream to byte array.
/// </summary>
/// <param name="stream">Stream</param>
/// <returns>Binary data from stream in an array</returns>
public static async Task<byte[]> ToArrayAsync(this Stream stream)
{
    if (!stream.CanRead)
    {
        throw new AccessViolationException("Stream cannot be read");
    }

    if (stream.CanSeek)
    {
        return await ToArrayAsyncDirect(stream);
    }
    else
    {
        return await ToArrayAsyncGeneral(stream);
    }
}

private static async Task<byte[]> ToArrayAsyncGeneral(Stream stream)
{
    using (var memoryStream = new MemoryStream())
    {
        await stream.CopyToAsync(memoryStream);
        return memoryStream.ToArray();
    }
}

private static async Task<byte[]> ToArrayAsyncDirect(Stream stream)
{
    var array = new byte[stream.Length];
    await stream.ReadAsync(array, 0, (int)stream.Length);
    return array;
}

O
Orace

You can use this extension method.

public static class StreamExtensions
{
    public static byte[] ToByteArray(this Stream stream)
    {
        var bytes = new List<byte>();

        int b;

        // -1 is a special value that mark the end of the stream
        while ((b = stream.ReadByte()) != -1)
            bytes.Add((byte)b);

        return bytes.ToArray();
    }
}

K
Kirk Woll

Since there's no modern (i.e. async) version of this answer, this is the extension method I use for this purpose:

public static async Task<byte[]> ReadAsByteArrayAsync(this Stream source)
{
    // Optimization
    if (source is MemoryStream memorySource)
        return memorySource.ToArray();

    using var memoryStream = new MemoryStream();
    await source.CopyToAsync(memoryStream);
    return memoryStream.ToArray();
}

The optimization is based on the fact the source code for ToArray calls some internal methods.


M
Mikael Dúi Bolinder

Combinig two of the most up-voted answers into an extension method:

public static byte[] ToByteArray(this Stream stream)
{
    if (stream is MemoryStream)
        return ((MemoryStream)stream).ToArray();
    else
    {
        using MemoryStream ms = new();
        stream.CopyTo(ms);
        return ms.ToArray();
    }            
}

When you add a code, also describe your proposed solution shortly.
C
Community

i was able to make it work on a single line:

byte [] byteArr= ((MemoryStream)localStream).ToArray();

as clarified by johnnyRose, Above code will only work for MemoryStream


What if localStream isn't a MemoryStream? This code will fail.
localStream has to be a stream based object. more about stream based object here stackoverflow.com/questions/8156896/…
What I was trying to suggest is, if you try to cast localStream to a MemoryStream, but localStream is not a MemoryStream, it will fail. This code will compile fine, but it could fail at runtime, depending on the actual type of localStream. You can't always arbitrarily cast a base type to a child type; read more here. This is another good example which explains why you can't always do this.
To elaborate on my above comment: all MemoryStreams are Streams, but not all Streams are MemoryStreams.
That is just wrong. Simple example: a FileStream can't be casted to a MemoryStream, and will fail with this error: "Unable to cast object of type 'System.IO.FileStream' to type 'System.IO.MemoryStream'." Example: using (Stream fs = new FileStream(@"C:\pathtofile.txt", FileMode.Open)) { var memoryStream = (MemoryStream)fs; } This won't compile if you simply use var, because it will implicitly type to a MemoryStream. Typing it with Stream as above creates a runtime exception as I explained previously. Try it and see for yourself.