以前寫了一篇C#裝飾模式的文章提到了.NET Core的Stream, 因此這裏儘可能把Stream介紹全點. (都是書上的內容)程序員
首先須要知道, System.IO命名空間是低級I/O功能的大本營.算法
.NET Core裏面的Stream主要是三個概念: 存儲(backing stores 我不知道怎麼翻譯比較好), 裝飾器, 適配器.windows
backing stores是讓輸入和輸出發揮做用的端點, 例如文件或者網絡鏈接. 就是下面任意一點或兩點:設計模式
程序員能夠經過Stream類來發揮backing store的做用. Stream類有一套方法, 能夠進行讀取, 寫入, 定位等操做. 個數組不一樣的是, 數組是把全部的數據都一同放在了內存裏, 而stream則是順序的/連續的處理數據, 要麼是一次處理一個字節, 要麼是一次處理特定大小(不能太大, 可管理的範圍內)的數據.數組
因而, stream能夠用比較小的固定大小的內存來處理不管多大的backing store.緩存
中間的那部分就是裝飾器Stream. 它符合裝飾模式.安全
從圖中能夠看到, Stream又分爲兩部分:服務器
裝飾器Stream有以下結構性的優勢(參考裝飾模式):網絡
backing store和裝飾器stream都是按字節進行處理的. 儘管這很靈活和高效, 可是程序通常仍是採用更高級別的處理方式例如文字或者xml.app
適配器經過使用特殊化的方法把類裏面的stream進行包裝成特殊的格式. 這就彌合了上述的間隔.
例如 text reader有一個ReadLine方法, XML writer又WriteAttributes方法.
注意: 適配器包裝了stream, 這點和裝飾器同樣, 可是不同的是, 適配器自己並非stream, 它通常會把全部針對字節的方法都隱藏起來. 因此本文就不介紹適配器了.
總結一下:
backing store stream 提供原始數據, 裝飾器stream提供透明的轉換(例如加密); 適配器提供方法來處理高級別的類型例如字符串和xml.
想要連成串的話, 秩序把對象傳遞到另外一個對象的構造函數裏.
Stream抽象類是全部Stream的基類.
它的方法和屬性主要分三類基本操做: 讀, 寫, 尋址(Seek); 和管理操做: 關閉(close), 衝(flush)和設定超時:
這些方法都有異步的版本, 加async, 返回Task便可.
一個例子:
using System; using System.IO; namespace Test { class Program { static void Main(string[] args) { // 在當前目錄建立按一個 test.txt 文件 using (Stream s = new FileStream("test.txt", FileMode.Create)) { Console.WriteLine(s.CanRead); // True Console.WriteLine(s.CanWrite); // True Console.WriteLine(s.CanSeek); // True s.WriteByte(101); s.WriteByte(102); byte[] block = { 1, 2, 3, 4, 5 }; s.Write(block, 0, block.Length); // 寫 5 字節 Console.WriteLine(s.Length); // 7 Console.WriteLine(s.Position); // 7 s.Position = 0; // 回到開頭位置 Console.WriteLine(s.ReadByte()); // 101 Console.WriteLine(s.ReadByte()); // 102 // 從block數組開始的地方開始read: Console.WriteLine(s.Read(block, 0, block.Length)); // 5 // 假設最後一次read返回 5, 那就是在文件結尾, 因此read會返回0: Console.WriteLine(s.Read(block, 0, block.Length)); // 0 } } } }
運行結果:
異步例子:
using System; using System.IO; using System.Threading.Tasks; namespace Test { class Program { static void Main(string[] args) { Task.Run(AsyncDemo).GetAwaiter().GetResult(); } async static Task AsyncDemo() { using (Stream s = new FileStream("test.txt", FileMode.Create)) { byte[] block = { 1, 2, 3, 4, 5 }; await s.WriteAsync(block, 0, block.Length); s.Position = 0; Console.WriteLine(await s.ReadAsync(block, 0, block.Length)); } } } }
異步版本比較適合慢的stream, 例如網絡的stream.
CanRead和CanWrite屬性能夠判斷Stream是否能夠讀寫.
Read方法把stream的一塊數據寫入到數組, 返回接受到的字節數, 它老是小於等於count這個參數. 若是它小於count, 就說明要麼是已經讀取到stream的結尾了, 要麼stream給的數據塊過小了(網絡stream常常這樣).
一個讀取1000字節stream的例子:
// 假設s是某個stream byte[] data = new byte[1000]; // bytesRead 的結束位置確定是1000, 除非stream的長度不足1000 int bytesRead = 0; int chunkSize = 1; while (bytesRead < data.Length && chunkSize > 0) bytesRead += chunkSize = s.Read(data, bytesRead, data.Length - bytesRead);
ReadByte方法更簡單一些, 一次就讀一個字節, 若是返回-1表示讀取到stream的結尾了. 返回類型是int.
Write和WriteByte就是相應的寫入方法了. 若是沒法寫入某個字節, 那就會拋出異常.
上面方法簽名裏的offset參數, 表示的是緩衝數組開始讀取或寫入的位置, 而不是指stream裏面的位置.
CanSeek爲true的話, Stream就能夠被尋址. 能夠查詢和修改可尋址的stream(例如文件stream)的長度, 也能夠隨時修改讀取和寫入的位置.
Position屬性就是所須要的, 它是相對於stream開始位置的.
Seek方法就容許你移動到當前位置或者stream的尾部.
注意改變FileStream的Position會花去幾微秒. 若是是在大規模循環裏面作這個操做的話, 建議使用MemoryMappedFile類.
對於不可尋址的Stream(例如加密Stream), 想知道它的長度只能是把它讀完. 並且你要是想讀取前一部分的話必須關閉stream, 而後再開始一個全新的stream才能夠.
Stream用完以後必須被處理掉(dispose)來釋放底層資源例如文件和socket處理. 一般使用using來實現.
關閉裝飾器stream的時候會同時關閉裝飾器和它的backing store stream.
針對一連串的裝飾器裝飾的stream, 關閉最外層的裝飾器就會關閉全部.
有些stream從backing store讀取/寫入的時候有一個緩存機制, 這就減小了實際到backing store的往返次數以達到提升性能的目的(例如FileStream).
這就意味着你寫入數據到stream的時候可能不會當即寫入到backing store; 它會有延遲, 直到緩衝被填滿.
Flush方法會強制內部緩衝的數據被當即的寫入. Flush會在stream關閉的時候自動被調用. 因此你不須要這樣寫: s.Flush(); s.Close();
若是CanTimeout屬性爲true的話, 那麼該stream就能夠設定讀或寫的超時.
網絡stream支持超時, 而文件和內存stream則不支持.
支持超時的stream, 經過ReadTimeout和WriteTimeout屬性能夠設定超時, 單位毫秒. 0表示無超時.
Read和Write方法經過拋出異常的方式來表示超時已經發生了.
stream並非線程安全的, 也就是說兩個線程同時讀或寫一個stream的時候就會報錯.
Stream經過Synchronized方法來解決這個問題. 該方法接受stream爲參數, 返回一個線程安全的包裝結果.
這個包裝結果在每次讀, 寫, 尋址的時候會得到一個獨立鎖/排他鎖, 因此同一時刻只有一個線程能夠執行操做.
實際上, 這容許多個線程同時爲同一個數據追加數據, 而其餘類型的操做(例如同讀)則須要額外的鎖來保證每一個線程能夠訪問到stream相應的部分.
文件流
構建一個FileStream:
FileStream fs1 = File.OpenRead("readme.bin"); // Read-only FileStream fs2 = File.OpenWrite(@"c:\temp\writeme.tmp"); // Write-only FileStream fs3 = File.Create(@"c:\temp\writeme.tmp"); // Read/write
OpenWrite和Create對於已經存在的文件來講, 它的行爲是不一樣的.
Create會把現有文件的內容清理掉, 寫入的時候從頭開寫.
OpenWrite則是完整的保存着現有的內容, 而stream的位置定位在0. 若是寫入的內容比原來的內容少, 那麼OpenWrite打開並寫完以後的內容是原內容和新寫入內容的混合體.
直接構建FileStream:
var fs = new FileStream ("readwrite.tmp", FileMode.Open); // Read/write
其構造函數裏面還能夠傳入其餘參數, 具體請看文檔.
File類的快捷方法:
下面這些靜態方法會一次性把整個文件讀進內存:
下面的方法直接寫入整個文件:
還有一個靜態方法叫File.ReadLines: 它有點想ReadAllLines, 可是它返回的是一個懶加載的IEnumerable<string>. 這個實際上效率更高一些, 由於沒必要一次性把整個文件都加載到內存裏. LINQ很是適合處理這個結果. 例如:
int longLines = File.ReadLines ("filePath").Count (l => l.Length > 80);
指定的文件名:
能夠是絕對路徑也能夠是相對路徑.
可已修改靜態屬性Environment.CurrentDirectory的值來改變當前的路徑. (注意: 默認的當前路徑不必定是exe所在的目錄)
AppDomain.CurrentDomain.BaseDirectory會返回應用的基目錄, 它一般是包含exe的目錄.
指定相對於這個目錄的地址最好使用Path.Combine方法:
string baseFolder = AppDomain.CurrentDomain.BaseDirectory; string logoPath = Path.Combine(baseFolder, "logo.jpg"); Console.WriteLine(File.Exists(logoPath));
經過網絡對文件讀寫要使用UNC路徑:
例如: \\JoesPC\PicShare \pic.jpg 或者 \\10.1.1.2\PicShare\pic.jpg.
FileMode:
全部的FileStream的構造器都會接收一個文件名和一個FileMode枚舉做爲參數. 若是選擇FileMode請看下圖:
其餘特性仍是須要看文檔.
MemoryStream在隨機訪問不可尋址的stream時就有用了.
若是你知道源stream的大小能夠接受, 你就能夠直接把它複製到MemoryStream裏:
var ms = new MemoryStream(); sourceStream.CopyTo(ms);
能夠經過ToArray方法把MemoryStream轉化成數組.
GetBuffer方法也是一樣的功能, 可是由於它是直接把底層的存儲數組的引用直接返回了, 因此會更有效率. 不過不幸的是, 這個數組一般比stream的真實長度要長.
注意: Close和Flush 一個MemoryStream是可選的. 若是關閉了MemoryStream, 你就不再能對它讀寫了, 可是仍然能夠調用ToArray方法來獲取其底層的數據.
Flush則對MemoryStream毫無用處.
PipeStream經過Windows Pipe 協議, 容許一個進程(process)和另外一個進程通訊.
分兩種:
pipe很適合一個電腦上的進程間交互(IPC), 它並不依賴於網絡傳輸, 這也意味着沒有網絡開銷, 也不在意防火牆.
注意: pipe是基於Stream的, 一個進程等待接受一串字符的同時另外一個進程發送它們.
PipeStream是抽象類.
具體的實現類有4個:
匿名pipe:
命名Pipe:
命名Pipe
命名pipe的雙方經過同名的pipe進行通訊. 協議規定了兩個角色: 服務器和客戶端. 按照下述方式進行通訊:
而後雙方就能夠讀寫stream來進行通訊了.
例子:
using System; using System.IO; using System.IO.Pipes; using System.Threading.Tasks; namespace Test { class Program { static void Main(string[] args) { Console.WriteLine(DateTime.Now.ToString()); using (var s = new NamedPipeServerStream("pipedream")) { s.WaitForConnection(); s.WriteByte(100); // Send the value 100. Console.WriteLine(s.ReadByte()); } Console.WriteLine(DateTime.Now.ToString()); } } }
using System; using System.IO.Pipes; namespace Test2 { class Program { static void Main(string[] args) { Console.WriteLine(DateTime.Now.ToString()); using (var s = new NamedPipeClientStream("pipedream")) { s.Connect(); Console.WriteLine(s.ReadByte()); s.WriteByte(200); // Send the value 200 back. } Console.WriteLine(DateTime.Now.ToString()); } } }
命名的PipeStream默認狀況下是雙向的, 因此任意一方均可以進行讀寫操做, 這也意味着服務器和客戶端必須達成某種協議來協調它們的操做, 避免同時進行發送和接收.
還須要協定好每次傳輸的長度.
在處理長度大於一字節的信息的時候, pipe提供了一個信息傳輸的模式, 若是這個啓用了, 一方在調用read的時候能夠經過檢查IsMessageComplete屬性來知道消息何時結束.
例子:
static byte[] ReadMessage(PipeStream s) { MemoryStream ms = new MemoryStream(); byte[] buffer = new byte[0x1000]; // Read in 4 KB blocks do { ms.Write(buffer, 0, s.Read(buffer, 0, buffer.Length)); } while (!s.IsMessageComplete); return ms.ToArray(); }
注意: 針對PipeStream不能夠經過Read返回值是0的方式來它是否已經完成讀取消息了. 這是由於它和其餘的Stream不一樣, pipe stream和network stream沒有肯定的終點. 在兩個信息傳送動做之間, 它們就乾等着.
這樣啓用信息傳輸模式, 服務器端 :
using (var s = new NamedPipeServerStream("pipedream", PipeDirection.InOut, 1, PipeTransmissionMode.Message)) { s.WaitForConnection(); byte[] msg = Encoding.UTF8.GetBytes("Hello"); s.Write(msg, 0, msg.Length); Console.WriteLine(Encoding.UTF8.GetString(ReadMessage(s))); }
客戶端:
using (var s = new NamedPipeClientStream("pipedream")) { s.Connect(); s.ReadMode = PipeTransmissionMode.Message; Console.WriteLine(Encoding.UTF8.GetString(ReadMessage(s))); byte[] msg = Encoding.UTF8.GetBytes("Hello right back!"); s.Write(msg, 0, msg.Length); }
匿名pipe:
匿名pipe提供父子進程間的單向通訊. 流程以下:
由於匿名pipe是單向的, 因此服務器必須建立兩份pipe來進行雙向通訊
例子:
server:
using System; using System.Diagnostics; using System.IO; using System.IO.Pipes; using System.Text; using System.Threading.Tasks; namespace Test { class Program { static void Main(string[] args) { string clientExe = @"D:\Projects\Test2\bin\Debug\netcoreapp2.0\win10-x64\publish\Test2.exe"; HandleInheritability inherit = HandleInheritability.Inheritable; using (var tx = new AnonymousPipeServerStream(PipeDirection.Out, inherit)) using (var rx = new AnonymousPipeServerStream(PipeDirection.In, inherit)) { string txID = tx.GetClientHandleAsString(); string rxID = rx.GetClientHandleAsString(); var startInfo = new ProcessStartInfo(clientExe, txID + " " + rxID); startInfo.UseShellExecute = false; // Required for child process Process p = Process.Start(startInfo); tx.DisposeLocalCopyOfClientHandle(); // Release unmanaged rx.DisposeLocalCopyOfClientHandle(); // handle resources. tx.WriteByte(100); Console.WriteLine("Server received: " + rx.ReadByte()); p.WaitForExit(); } } } }
client:
using System; using System.IO.Pipes; namespace Test2 { class Program { static void Main(string[] args) { string rxID = args[0]; // Note we're reversing the string txID = args[1]; // receive and transmit roles. using (var rx = new AnonymousPipeClientStream(PipeDirection.In, rxID)) using (var tx = new AnonymousPipeClientStream(PipeDirection.Out, txID)) { Console.WriteLine("Client received: " + rx.ReadByte()); tx.WriteByte(200); } } } }
最好發佈一下client成爲獨立運行的exe:
dotnet publish --self-contained --runtime win10-x64
運行結果:
匿名pipe不支持消息模式, 因此你必須本身來爲傳輸的長度制定協議. 有一種作法是: 在每次傳輸的前4個字節裏存放一個整數表示消息的長度, 可使用BitConverter類來對整型和長度爲4的字節數組進行轉換.
BufferedStream對另外一個stream進行裝飾或者說包裝, 讓它擁有緩衝的能力.它也是衆多裝飾stream類型中的一個.
緩衝確定會經過減小往返backing store的次數來提高性能.
下面這個例子是把一個FileStream裝飾成20k的緩衝stream:
// Write 100K to a file: File.WriteAllBytes("myFile.bin", new byte[100000]); using (FileStream fs = File.OpenRead("myFile.bin")) using (BufferedStream bs = new BufferedStream(fs, 20000)) //20K buffer { bs.ReadByte(); Console.WriteLine(fs.Position); // 20000 } }
經過預讀緩衝, 底層的stream會在讀取1字節後, 直接預讀了20000字節, 這樣咱們在另外調用ReadByte 19999次以後, 纔會再次訪問到FileStream.
這個例子是把BufferedStream和FileStream耦合到一塊兒, 實際上這個例子裏面的緩衝做用有限, 由於FileStream有一個內置的緩衝. 這個例子也只能擴大一下緩衝而已.
關閉BufferedStream就會關閉底層的backing store stream..
Stream只按字節處理, 對string, 整型, xml等都是經過字節進行讀寫的, 因此必須插入一個適配器.
.NET Core提供了這些文字適配器:
二進制適配器(適用於原始類型例如int bool string float等):
XML適配器:
這些適配器的關係圖:
TextReader 和 TextWriter是文字適配器的基類. 它倆分別對應兩套實現:
TextReader:
Peek方法會返回下一個字符而不改變當前(能夠看做是索引)的位置.
在Stream讀取到結束點的時候Peek和無參數的Read方法都會返回-1, 不然它們會返回一個能夠被轉換成字符的整型.
Read的重載方法(接受char[]緩衝參數)在功能上和ReadBlock方法是同樣的.
ReadLine方法會一直讀取直到遇到了CR或LF或CR+LF對(之後再介紹), 而後會放回字符串, 可是不包含CR/LF等字符.
注意: C#應該使用"\r\n"來還行, 順序寫反了可能會不換行患者換兩行.
TextWriter:
方法與TextReader相似.
Write和WriteLine有幾個重載方法能夠接受全部的原始類型, 還有object類型. 這些方法會調用被傳入參數的ToString方法. 另外也能夠在構造函數或者調用方法的時候經過IFormatProvider進行指定.
WriteLine會在給定的文字後邊加上CR+LF, 您能夠經過修改NewLine屬性來改變這個行爲(尤爲是與UNIX文件格式交互的時候).
上面講的這些方法, 都有異步版本的
StreamReader和StreamWriter
直接看例子便可:
using (FileStream fs = File.Create("test.txt")) using (TextWriter writer = new StreamWriter(fs)) { writer.WriteLine("Line 1"); writer.WriteLine("Line 2"); } using (FileStream fs = File.OpenRead("test.txt")) using (TextReader reader = new StreamReader(fs)) { Console.WriteLine(reader.ReadLine()); Console.WriteLine(reader.ReadLine()); }
因爲文字適配器常常要處理文件, 因此File類提供了一些靜態方法例如: CreateText, AppendText, OpenText來作快捷操做:
上面的例子能夠寫成:
using (TextWriter writer = File.CreateText("test.txt")) { writer.WriteLine("Line1"); writer.WriteLine("Line2"); } using (TextWriter writer = File.AppendText("test.txt")) writer.WriteLine("Line3"); using (TextReader reader = File.OpenText("test.txt")) while (reader.Peek() > -1) Console.WriteLine(reader.ReadLine());
代碼中能夠看到, 如何知道是否讀取到了文件的結尾(經過reader.Peek()). 另外一個方法是使用reader.ReadLine方法讀取直到返回null.
也能夠讀取其餘的類型, 例如int(由於TextWriter會調用ToString方法), 可是讀取的時候想要變成原來的類型就得進行解析字符串操做了.
字符串編碼
TextReader和TextWriter是抽象類, 跟sream或者backing store沒有鏈接. StreamReader和StreamWriter則鏈接着一個底層的字節流, 因此它們必須對字符串和字節進行轉換. 它們經過System.Text.Encoding類來作這些工做, 也就是構建StreamReader或StreamWriter的時候選擇一個Encoding. 若是你沒選那麼就是UTF-8了.
注意: 若是你明確指定了一個編碼, 那麼StreamWriter默認會在流的前邊加一個前綴, 這個前綴是用來識別編碼的. 若是你不想這樣作的話, 那麼能夠這樣作:
var encoding = new UTF8Encoding( encoderShouldEmitUTF8Identifier: false, throwOnInvalidBytes: true );
第二個參數是告訴StreamWriter, 若是遇到了本編碼下的非法字符串, 那就拋出一個異常. 若是不指定編碼的狀況下, 也是這樣的.
最簡單的編碼是ASCII, 每個字符經過一個字節來表示. ASCII對Unicode的前127個字符進行了映射, 包含了US鍵盤上面全部的鍵. 而其餘的字符, 例如特殊字符和非英語字符等沒法被表達的字符則會顯示成□. 默認的UTF-8編碼影射了全部的Unicode字符, 可是它更復雜. 前127個字節使用單字節, 這是爲了和ASCII兼容; 而剩下的字節編碼成了不定長的字節數(一般是2或者3字節).
UTF-8處理西方語言的文字還不錯, 可是在stream裏面搜索/尋址就會遇到麻煩了, 這時可使用UTF-16這個候選(Encoding類裏面叫Unicode).
UTF-16針對每一個字符使用2個或4個字節, 可是因爲C#的char類型是16bit的, 因此針對.NET的char, UTF-16正好使用兩個字節. 這樣在stream裏面找到特定字符的索引就方便多了.
UTF-16會使用一個2字節長的前綴, 來識別字節對是按little-endian仍是big-endian的順序存儲的. windows系統默認使用little-endian.
StringReader和StringWriter
這兩個適配器根本不包裝stream; 它們使用String或StringBuilder做爲數據源, 因此不須要字節轉換.
實際上這兩個類存在的主要優點就是: 它們和StreamReader/StreamWriter具備同一個父類.
例若有一個含有xml的字符串, 我想把它用XmlReader進行解析, XmlReader.Create方法能夠接受下列參數:
由於StringReader是TextReader的子類, 因此我就能夠這樣作:
XmlReader reader = XmlReader.Create(new StringReader("...xml string..."));
BinaryReader和BinaryWriter能夠讀取/寫入下列類型: bool, byte, char, decimal, float, double, short, int, long, sbyte, ushort, uint, ulong 以及string和由原始類型組成的數組.
和StreamReader/StreamWriter不一樣的是, 二進制適配器對原始數據類型的存儲效率是很是高的, 由於都是在內存裏.
int使用4個字節, double 8個字節......
string則是經過文字編碼(就像StreamReader和StreamWriter), 可是長度是固定的, 以即可以對string回讀, 而不須要使用分隔符.
舉個例子:
public class Person { public string Name; public int Age; public double Height; public void SaveData(Stream s) { var w = new BinaryWriter(s); w.Write(Name); w.Write(Age); w.Write(Height); w.Flush(); } public void LoadData(Stream s) { var r = new BinaryReader(s); Name = r.ReadString(); Age = r.ReadInt32(); Height = r.ReadDouble(); } }
這個例子裏, Person類使用SaveData和LoadData兩個方法把它的數據寫入到Stream/從Stream讀取出來, 裏面用的是二進制適配器.
因爲BinaryReader能夠讀取到字節數組, 因此能夠把要讀取的內容轉化成可尋址的stream:
byte[] data = new BinaryReader(s).ReadBytes((int)sbyte.Length);
有四種作法能夠把stream適配器清理掉:
注意: Close和Dispose對於適配器來講功能是同樣的, 這點對Stream也同樣.
上面的前兩種寫法其實是同樣的, 由於關閉適配器的話會自動關閉底層的Stream. 當嵌套使用using的時候, 就是隱式的使用方法2:
using (FileStream fs = File.Create("test.txt")) using (TextWriter writer = new StreamWriter(fs)) { writer.WriteLine("Line"); }
這是由於嵌套的dispose是從內而外的, 適配器先關閉, 而後是Stream. 此外, 若是在適配器的構造函數裏發生異常了, 這個Stream仍然會關閉, 嵌套使用using是很難出錯的.
注意: 不要在關閉或flush stream的適配器writer以前去關閉stream, 那會截斷在適配器緩衝的數據.
第3, 4中方法之因此可行, 是由於適配器是比較另類的, 它們是可選disposable的對象. 看下面的例子:
using (FileStream fs = new FileStream("test.txt", FileMode.Create)) { StreamWriter writer = new StreamWriter(fs); writer.WriteLine("Hello"); writer.Flush(); fs.Position = 0; Console.WriteLine(fs.ReadByte()); }
這裏, 我對一個文件進行了寫入動做, 而後重定位stream, 讀取第一個字節. 我想把Stream開着, 由於之後還要用到.
這時, 若是我dispose了StreamWriter, 那麼FileStream就被關閉了, 之後就沒法操做它了. 因此沒有調用writer的dispose或close方法.
可是這裏須要flush一下, 以確保StreamWriter的緩存的內容都寫入到了底層的stream裏.
注意: 鑑於適配器的dispose是可選的, 因此再也不使用的適配器就能夠躲開GC的清理操做.
.net 4.5之後, StreamReader/StreamWriter有了一個新的構造函數, 它能夠接受一個參數, 來指定在dispose以後是否讓Stream保持開放:
using (var fs = new FileStream("test.txt", FileMode.Create)) { using (var writer = new StreamWriter(fs, new UTF8Encoding(false, true), 0x400, true)) writer.WriteLine("Hello"); fs.Position = 0; Console.WriteLine(fs.ReadByte()); Console.WriteLine(fs.Length); }
在System.IO.Compression下有兩個壓縮Stream: DeflateStream和GZipStream. 它們都使用了一個相似於ZIP格式的壓縮算法. 不一樣的是GZipStream會在開頭和結尾寫入額外的協議--包括CRC錯誤校驗.GZipStream也符合其餘軟件的標準.
這兩種Stream在讀寫的時候有這兩個條件:
DeflateStream和GZipStream都是裝飾器(參考裝飾設計模式); 它們會壓縮/解壓縮從構造函數傳遞進來的Stream. 例如:
using (Stream s = File.Create("compressed.bin")) using (Stream ds = new DeflateStream(s, CompressionMode.Compress)) for (byte i = 0; i < 100; i++) ds.WriteByte(i); using (Stream s = File.OpenRead("compressed.bin")) using (Stream ds = new DeflateStream(s, CompressionMode.Decompress)) for (byte i = 0; i < 100; i++) Console.WriteLine(ds.ReadByte()); // Writes 0 to 99
上面這個例子裏, 即便是壓縮的比較小的, 文件在壓縮後也有241字節長, 比原來的兩倍還多....這是由於, 壓縮算法對於這種"稠密"的非重複的二進制數據處理的很很差(加密的數據更完), 可是它對文本類的文件仍是處理的很好的.
Task.Run(async () => { string[] words = "The quick brown fox jumps over the lazy dog".Split(); Random rand = new Random(); using (Stream s = File.Create("compressed.bin")) using (Stream ds = new DeflateStream(s, CompressionMode.Compress)) using (TextWriter w = new StreamWriter(ds)) for (int i = 0; i < 1000; i++) await w.WriteAsync(words[rand.Next(words.Length)] + " "); Console.WriteLine(new FileInfo("compressed.bin").Length); using (Stream s = File.OpenRead("compressed.bin")) using (Stream ds = new DeflateStream(s, CompressionMode.Decompress)) using (TextReader r = new StreamReader(ds)) Console.Write(await r.ReadToEndAsync()); }).GetAwaiter().GetResult();
壓縮後的長度是856!
有時候須要把整個壓縮都放在內存裏, 這就要用到MemoryStream:
byte[] data = new byte[1000]; // 對於空數組, 咱們能夠期待一個很好的壓縮比率! var ms = new MemoryStream(); using (Stream ds = new DeflateStream(ms, CompressionMode.Compress)) ds.Write(data, 0, data.Length); byte[] compressed = ms.ToArray(); Console.WriteLine(compressed.Length); // 14 // 解壓回數組: ms = new MemoryStream(compressed); using (Stream ds = new DeflateStream(ms, CompressionMode.Decompress)) for (int i = 0; i < 1000; i += ds.Read(data, i, 1000 - i)) ;
這裏第一個using走完的時候MemoryStream會被關閉, 因此只能使用ToArray方法來提取它的數據.
下面是另一種異步的作法, 能夠避免關閉MemoryStream:
Task.Run(async () => { byte[] data = new byte[1000]; MemoryStream ms = new MemoryStream(); using (Stream ds = new DeflateStream(ms, CompressionMode.Compress, true)) await ds.WriteAsync(data, 0, data.Length); Console.WriteLine(ms.Length); ms.Position = 0; using (Stream ds = new DeflateStream(ms, CompressionMode.Decompress)) for (int i = 0; i < 1000; i += await ds.ReadAsync(data, i, 1000 - i)) ; }).GetAwaiter().GetResult();
注意DeflateStream的最後一個參數.
.NET 4.5以後, 經過新引入的ZpiArchive和ZipFile類(System.IO.Compression下, Assembly是System.IO.Compression.FileSytem.dll), 咱們就能夠直接操做zip文件了.
zip格式相對於DelfateStream和GZipStream的優點是, 它能夠做爲多個文件的容器.
ZipArchive配合Stream進行工做, 而ZipFile則是更多的和文件打交道.(ZipFile是ZipArchive的一個Helper類).
ZipFIle的CreateFromDirectory方法會把指定目錄下的全部文件打包成zip文件:
ZipFile.CreateFromDirectory (@"d:\MyFolder", @"d:\compressed.zip");
而ExtractToDirectory則是作相反的工做:
ZipFile.ExtractToDirectory (@"d:\compressed.zip", @"d:\MyFolder");
壓縮的時候, 能夠指定是否對文件的大小, 壓縮速度進行優化, 也能夠指定壓縮後是否包含源目錄.
ZipFile的Open方法能夠用來讀寫單獨的條目, 它會返回一個ZipArchive對象(你也能夠經過使用Stream對象初始化ZipArchive對象獲得). 調用Open方法的時候, 你能夠指定文件名和指定想要進行的動做: 讀, 寫, 更新. 你能夠經過Entries屬性遍歷全部的條目, 想找到特定的條目可使用GetEntry方法:
using (ZipArchive zip = ZipFile.Open (@"d:\zz.zip", ZipArchiveMode.Read)) foreach (ZipArchiveEntry entry in zip.Entries) Console.WriteLine (entry.FullName + " " + entry.Length);
ZipArchiveEntry還有一個Delete方法和一個ExtractToFile(這個實際上是ZipFIleExtensions裏面的extension方法)方法, 還有個Open方法返回可讀寫的Stream. 你能夠經過調用CreateEntry方法(或者CreateEntryFromFile這個extension方法)在ZipArchive上建立新的條目.
例子:
byte[] data = File.ReadAllBytes (@"d:\foo.dll"); using (ZipArchive zip = ZipFile.Open (@"d:\zz.zip", ZipArchiveMode.Update)) zip.CreateEntry (@"bin\X64\foo.dll").Open().Write (data, 0, data.Length);
上面例子裏的操做徹底能夠在內存中實現, 使用MemoryStream便可.