Tableau byte[] en Stream en C# : 4 méthodes de conversion qui sauveront votre projet en 2025
\n\nImaginez : vous développez une application de traitement d'images, vous chargez un fichier via une requête HTTP, vous recevez un tableau d'octets — et soudain, vous réalisez que votre bibliothèque PDF préférée attend un Stream en entrée. Cela vous parle ? Si vous travaillez avec C# et .NET, tôt ou tard, vous serez confronté à cette question : "Comment convertir un byte[] en Stream ?".
Cette question sur Stack Overflow a rassemblé des milliers de vues, et pour cause. Rien de plus simple en apparence, mais le diable se cache dans les détails : une conversion incorrecte peut entraîner des fuites mémoire, une baisse de performance ou, pire encore, des flux non fermés.
\n\nDans cet article, nous allons détailler 4 méthodes optimales pour convertir byte[] en Stream en C#, toujours d'actualité en 2025. Vous apprendrez non seulement "comment faire", mais aussi "pourquoi faire ainsi", et vous repartirez avec des extraits de code prêts à l'emploi.
\n\nPourquoi la conversion byte[] en Stream ne se résume-t-elle pas à "new MemoryStream(bytes)" ?
\n\nÀ première vue, la solution semble évidente : MemoryStream est un flux basé sur un tableau d'octets. Mais creusons un peu. Dans les applications .NET modernes (notamment en programmation asynchrone et avec de gros volumes de données), un mauvais choix peut vous coûter de précieuses millisecondes, voire provoquer une OutOfMemoryException.
Voici les scénarios principaux où cette conversion est nécessaire :
\n- \n
- Gestion de fichiers : Vous avez lu un fichier dans un
byte[](viaFile.ReadAllBytespar exemple), mais l'API de la bibliothèque exige unStream. \n - Opérations réseau : Vous recevez un tableau d'octets depuis une réponse HTTP, un WebSocket ou une socket TCP. \n
- Cryptographie : Les méthodes de chiffrement/déchiffrement manipulent souvent des flux, alors que vous avez déjà un tableau prêt. \n
- Sérialisation : Vous avez désérialisé un objet en
byte[]et devez maintenant le passer à une méthode qui attend unStream. \n
Méthode 1 : MemoryStream classique (niveau débutant)
\n\nLa méthode la plus simple et intuitive consiste à créer une nouvelle instance de MemoryStream en passant le tableau d'octets au constructeur.
byte[] data = { 0x48, 0x65, 0x6C, 0x6C, 0x6F }; // "Hello" en ASCII\nusing (MemoryStream stream = new MemoryStream(data))\n{\n // Le flux est maintenant prêt à être utilisé\n // Il sera automatiquement fermé à la sortie du bloc using\n Console.WriteLine($"Longueur du flux : {stream.Length} octets");\n}\n\n\nAvantages : Simplicité, code lisible, gestion automatique de la mémoire via using.
Inconvénients : Crée-t-il une copie des données ? Non ! Détail important : le constructeur MemoryStream(byte[]) ne copie pas le tableau, mais crée un flux qui ne supporte pas le redimensionnement. Le flux travaille directement sur votre tableau d'origine. C'est rapide, mais si vous tentez accidentellement d'agrandir le flux (via SetLength par exemple), vous obtiendrez une exception NotSupportedException.
Quand l'utiliser : Lorsque vous avez uniquement besoin de lire les données ou de travailler avec une taille fixe. Idéal pour passer des données à des méthodes qui acceptent un Stream en lecture seule (ex : Image.FromStream).
Méthode 2 : MemoryStream avec accès en écriture (niveau avancé)
\n\nSi vous devez non seulement lire le flux, mais aussi y ajouter des données, utilisez la surcharge du constructeur avec le paramètre writable.
byte[] data = { 0x41, 0x42, 0x43 }; // "ABC"\nbool writable = true;\nusing (MemoryStream stream = new MemoryStream(data, 0, data.Length, writable))\n{\n // Vous pouvez maintenant lire ET écrire dans le flux