<br>
10.7.1 數據的發起與接收<br>
Java 1.0的幾乎所有IO流類都有對應的Java 1.1類，用于提供內建的Unicode管理。似乎最容易的事情就是“全部使用新類，再也不要用舊的”，但實際情況并沒有這么簡單。有些時候，由于受到庫設計的一些限制，我們不得不使用Java 
1.0的IO流類。特別要指出的是，在舊流庫的基礎上新加了java.util.zip庫，它們依賴舊的流組件。所以最明智的做法是“嘗試性”地使用Reader和Writer類。若代碼不能通過編譯，便知道必須換回老式庫。<br>
下面這張表格分舊庫與新庫分別總結了信息發起與接收之間的對應關系。<br>
<br>
發起＆接收：Java 1.0類 對應的Java 1.1類<br>
<br>
474頁表中內容略<br>
<br>
我們發現即使不完全一致，但舊庫組件中的接口與新接口通常也是類似的。<br>
<br>
10.7.2 修改數據流的行為<br>
在Java 1.0中，數據流通過FilterInputStream和FilterOutputStream的“裝飾器”（Decorator）子類適應特定的需求。Java 
1.1的IO流沿用了這一思想，但沒有繼續采用所有裝飾器都從相同“filter”（過濾器）基礎類中衍生這一做法。若通過觀察類的層次結構來理解它，這可能令人出現少許的困惑。<br>
在下面這張表格中，對應關系比上一張表要粗糙一些。之所以會出現這個差別，是由類的組織造成的：盡管BufferedOutputStream是FilterOutputStream的一個子類，但是BufferedWriter并不是FilterWriter的子類（對后者來說，盡管它是一個抽象類，但沒有自己的子類或者近似子類的東西，也沒有一個“占位符”可用，所以不必費心地尋找）。然而，兩個類的接口是非常相似的，而且不管在什么情況下，顯然應該盡可能地使用新版本，而不應考慮舊版本（也就是說，除非在一些類中必須生成一個Stream，不可生成Reader或者Writer）。<br>
<br>
過濾器：Java 1.0類 對應的Java 1.1類<br>
<br>
FilterInputStream FilterReader<br>
FilterOutputStream FilterWriter（沒有子類的抽象類）<br>
BufferedInputStream BufferedReader（也有readLine()）<br>
BufferedOutputStream BufferedWriter<br>
DataInputStream 使用DataInputStream（除非要使用readLine()，那時需要使用一個BufferedReader）<br>
PrintStream PrintWriter<br>
LineNumberInputStream LineNumberReader<br>
StreamTokenizer StreamTokenizer（用構建器取代Reader）<br>
PushBackInputStream PushBackReader<br>
<br>
有一條規律是顯然的：若想使用readLine()，就不要再用一個DataInputStream來實現（否則會在編譯期得到一條出錯消息），而應使用一個BufferedReader。但除這種情況以外，DataInputStream仍是Java 
1.1 IO庫的“首選”成員。<br>
為了將向PrintWriter的過渡變得更加自然，它提供了能采用任何OutputStream對象的構建器。PrintWriter提供的格式化支持沒有PrintStream那么多；但接口幾乎是相同的。<br>
<br>
10.7.3 未改變的類<br>
顯然，Java庫的設計人員覺得以前的一些類毫無問題，所以沒有對它們作任何修改，可象以前那樣繼續使用它們：<br>
<br>
沒有對應Java 1.1類的Java 1.0類<br>
<br>
DataOutputStream<br>
File<br>
RandomAccessFile<br>
SequenceInputStream<br>
<br>
特別未加改動的是DataOutputStream，所以為了用一種可轉移的格式保存和獲取數據，必須沿用InputStream和OutputStream層次結構。<br>
<br>
10.7.4 一個例子<br>
為體驗新類的效果，下面讓我們看看如何修改IOStreamDemo.java示例的相應區域，以便使用Reader和Writer類：<br>
<br>
476-478頁程序<br>
<br>
大家一般看見的是轉換過程非常直觀，代碼看起來也頗相似。但這些都不是重要的區別。最重要的是，由于隨機訪問文件已經改變，所以第6節未再重復。<br>
第1節收縮了一點兒，因為假如要做的全部事情就是讀取行輸入，那么只需要將一個FileReader封裝到BufferedReader之內即可。第1b節展示了封裝System.in，以便讀取控制臺輸入的新方法。這里的代碼量增多了一些，因為System.in是一個DataInputStream，而且BufferedReader需要一個Reader參數，所以要用InputStreamReader來進行轉換。<br>
在2節，可以看到如果有一個字串，而且想從中讀取數據，只需用一個StringReader替換StringBufferInputStream，剩下的代碼是完全相同的。<br>
第3節揭示了新IO流庫設計中的一個錯誤。如果有一個字串，而且想從中讀取數據，那么不能再以任何形式使用StringBufferInputStream。若編譯一個涉及StringBufferInputStream的代碼，會得到一條“反對”消息，告訴我們不要用它。此時最好換用一個StringReader。但是，假如要象第3節這樣進行格式化的內存輸入，就必須使用DataInputStream——沒有什么“DataReader”可以代替它——而DataInputStream很不幸地要求用到一個InputStream參數。所以我們沒有選擇的余地，只好使用編譯器不贊成的StringBufferInputStream類。編譯器同樣會發出反對信息，但我們對此束手無策（注釋②）。<br>
StringReader替換StringBufferInputStream，剩下的代碼是完全相同的。<br>
<br>
②：到你現在正式使用的時候，這個錯誤可能已經修正。<br>
<br>
第4節明顯是從老式數據流到新數據流的一個直接轉換，沒有需要特別指出的。在第5節中，我們被強迫使用所有的老式數據流，因為DataOutputStream和DataInputStream要求用到它們，而且沒有可供替換的東西。然而，編譯期間不會產生任何“反對”信息。若不贊成一種數據流，通常是由于它的構建器產生了一條反對消息，禁止我們使用整個類。但在DataInputStream的情況下，只有readLine()是不贊成使用的，因為我們最好為readLine()使用一個BufferedReader（但為其他所有格式化輸入都使用一個DataInputStream）。<br>
若比較第5節和IOStreamDemo.java中的那一小節，會注意到在這個版本中，數據是在文本之前寫入的。那是由于Java 
1.1本身存在一個錯誤，如下述代碼所示：<br>
<br>
479-480頁程序<br>
<br>
看起來，我們在對一個writeBytes()的調用之后寫入的任何東西都不是能夠恢復的。這是一個十分有限的錯誤，希望在你讀到本書的時候已獲得改正。為檢測是否改正，請運行上述程序。若沒有得到一個違例，而且值都能正確打印出來，就表明已經改正。<br>
<br>
10.7.5 重導向標準IO<br>
Java 1.1在System類中添加了特殊的方法，允許我們重新定向標準輸入、輸出以及錯誤IO流。此時要用到下述簡單的靜態方法調用：<br>
setIn(InputStream)<br>
setOut(PrintStream)<br>
setErr(PrintStream)<br>
如果突然要在屏幕上生成大量輸出，而且滾動的速度快于人們的閱讀速度，輸出的重定向就顯得特別有用。在一個命令行程序中，如果想重復測試一個特定的用戶輸入序列，輸入的重定向也顯得特別有價值。下面這個簡單的例子展示了這些方法的使用：<br>
<br>
481頁程序<br>
<br>
這個程序的作用是將標準輸入同一個文件連接起來，并將標準輸出和錯誤重定向至另一個文件。<br>
這是不可避免會遇到“反對”消息的另一個例子。用-deprecation標志編譯時得到的消息如下：<br>
<br>
Note:The constructor java.io.PrintStream(java.io.OutputStream) has been deprecated.<br>
注意：不推薦使用構建器java.io.PrintStream（java.io.OutputStream）。<br>
<br>
然而，無論System.setOut()還是System.setErr()都要求用一個PrintStream作為參數使用，所以必須調用PrintStream構建器。所以大家可能會覺得奇怪，既然Java 
1.1通過反對構建器而反對了整個PrintStream，為什么庫的設計人員在添加這個反對的同時，依然為System添加了新方法，且指明要求用PrintStream，而不是用PrintWriter呢？畢竟，后者是一個嶄新和首選的替換措施呀？這真令人費解。<br>
<br>
10.8 壓縮<br>
Java 1.1也添加一個類，用以支持對壓縮格式的數據流的讀寫。它們封裝到現成的IO類中，以提供壓縮功能。<br>
此時Java 1.1的一個問題顯得非常突出：它們不是從新的Reader和Writer類衍生出來的，而是屬于InputStream和OutputStream層次結構的一部分。所以有時不得不混合使用兩種類型的數據流（注意可用InputStreamReader和OutputStreamWriter在不同的類型間方便地進行轉換）。<br>
<br>
Java 1.1壓縮類 功能<br>
<br>
CheckedInputStream GetCheckSum()為任何InputStream產生校驗和（不僅是解壓）<br>
CheckedOutputStream GetCheckSum()為任何OutputStream產生校驗和（不僅是解壓）<br>
DeflaterOutputStream 用于壓縮類的基礎類<br>
ZipOutputStream 一個DeflaterOutputStream，將數據壓縮成Zip文件格式<br>
GZIPOutputStream 一個DeflaterOutputStream，將數據壓縮成GZIP文件格式<br>
InflaterInputStream 用于解壓類的基礎類<br>
ZipInputStream 一個DeflaterInputStream，解壓用Zip文件格式保存的數據<br>
GZIPInputStream 一個DeflaterInputStream，解壓用GZIP文件格式保存的數據<br>
<br>
盡管存在許多種壓縮算法，但是Zip和GZIP可能最常用的。所以能夠很方便地用多種現成的工具來讀寫這些格式的壓縮數據。<br>
<br>
10.8.1 用GZIP進行簡單壓縮<br>
GZIP接口非常簡單，所以如果只有單個數據流需要壓縮（而不是一系列不同的數據），那么它就可能是最適當選擇。下面是對單個文件進行壓縮的例子：<br>