<br>
483-484頁程序<br>
<br>
壓縮類的用法非常直觀——只需將輸出流封裝到一個GZIPOutputStream或者ZipOutputStream內，并將輸入流封裝到GZIPInputStream或者ZipInputStream內即可。剩余的全部操作就是標準的IO讀寫。然而，這是一個很典型的例子，我們不得不混合使用新舊IO流：數據的輸入使用Reader類，而GZIPOutputStream的構建器只能接收一個OutputStream對象，不能接收Writer對象。<br>
<br>
10.8.2 用Zip進行多文件保存<br>
提供了Zip支持的Java 1.1庫顯得更加全面。利用它可以方便地保存多個文件。甚至有一個獨立的類來簡化對Zip文件的讀操作。這個庫采采用的是標準Zip格式，所以能與當前因特網上使用的大量壓縮、解壓工具很好地協作。下面這個例子采取了與前例相同的形式，但能根據我們需要控制任意數量的命令行參數。除此之外，它展示了如何用Checksum類來計算和校驗文件的“校驗和”（Checksum）?？蛇x用兩種類型的Checksum：Adler32（速度要快一些）和CRC32（慢一些，但更準確）。<br>
<br>
484－486頁程序<br>
<br>
對于要加入壓縮檔的每一個文件，都必須調用putNextEntry()，并將其傳遞給一個ZipEntry對象。ZipEntry對象包含了一個功能全面的接口，利用它可以獲取和設置Zip文件內那個特定的Entry（入口）上能夠接受的所有數據：名字、壓縮后和壓縮前的長度、日期、CRC校驗和、額外字段的數據、注釋、壓縮方法以及它是否一個目錄入口等等。然而，雖然Zip格式提供了設置密碼的方法，但Java的Zip庫沒有提供這方面的支持。而且盡管CheckedInputStream和CheckedOutputStream同時提供了對Adler32和CRC32校驗和的支持，但是ZipEntry只支持CRC的接口。這雖然屬于基層Zip格式的限制，但卻限制了我們使用速度更快的Adler32。<br>
為解壓文件，ZipInputStream提供了一個getNextEntry()方法，能在有的前提下返回下一個ZipEntry。作為一個更簡潔的方法，可以用ZipFile對象讀取文件。該對象有一個entries()方法，可以為ZipEntry返回一個Enumeration（枚舉）。<br>
為讀取校驗和，必須多少擁有對關聯的Checksum對象的訪問權限。在這里保留了指向CheckedOutputStream和CheckedInputStream對象的一個句柄。但是，也可以只占有指向Checksum對象的一個句柄。<br>
Zip流中一個令人困惑的方法是setComment()。正如前面展示的那樣，我們可在寫一個文件時設置注釋內容，但卻沒有辦法取出ZipInputStream內的注釋?？雌饋?，似乎只能通過ZipEntry逐個入口地提供對注釋的完全支持。<br>
當然，使用GZIP或Zip庫時并不僅僅限于文件——可以壓縮任何東西，包括要通過網絡連接發送的數據。<br>
<br>
10.8.3 Java歸檔（jar）實用程序<br>
Zip格式亦在Java 1.1的JAR（Java ARchive）文件格式中得到了采用。這種文件格式的作用是將一系列文件合并到單個壓縮文件里，就象Zip那樣。然而，同Java中其他任何東西一樣，JAR文件是跨平臺的，所以不必關心涉及具體平臺的問題。除了可以包括聲音和圖像文件以外，也可以在其中包括類文件。<br>
涉及因特網應用時，JAR文件顯得特別有用。在JAR文件之前，Web瀏覽器必須重復多次請求Web服務器，以便下載完構成一個“程序片”（Applet）的所有文件。除此以外，每個文件都是未經壓縮的。但在將所有這些文件合并到一個JAR文件里以后，只需向遠程服務器發出一次請求即可。同時，由于采用了壓縮技術，所以可在更短的時間里獲得全部數據。另外，JAR文件里的每個入口（條目）都可以加上數字化簽名（詳情參考Java用戶文檔）。<br>
一個JAR文件由一系列采用Zip壓縮格式的文件構成，同時還有一張“詳情單”，對所有這些文件進行了描述（可創建自己的詳情單文件；否則，jar程序會為我們代勞）。在聯機用戶文檔中，可以找到與JAR詳情單更多的資料（詳情單的英語是“Manifest”）。<br>
jar實用程序已與Sun的JDK配套提供，可以按我們的選擇自動壓縮文件。請在命令行調用它：<br>
<br>
jar [選項] 說明 [詳情單] 輸入文件<br>
<br>
其中，“選項”用一系列字母表示（不必輸入連字號或其他任何指示符）。如下所示：<br>
<br>
487頁表<br>
<br>
c 創建新的或空的壓縮檔<br>
t 列出目錄表<br>
x 解壓所有文件<br>
x file 解壓指定文件<br>
f 指出“我準備向你提供文件名”。若省略此參數，jar會假定它的輸入來自標準輸入；或者在它創建文件時，輸出會進入標準輸出內<br>
m 指出第一個參數將是用戶自建的詳情表文件的名字<br>
v 產生詳細輸出，對jar做的工作進行巨細無遺的描述<br>
O 只保存文件；不壓縮文件（用于創建一個JAR文件，以便我們將其置入自己的類路徑中）<br>
M 不自動生成詳情表文件<br>
<br>
在準備進入JAR文件的文件中，若包括了一個子目錄，那個子目錄會自動添加，其中包括它自己的所有子目錄，以此類推。路徑信息也會得到保留。<br>
下面是調用jar的一些典型方法：<br>
<br>
jar cf myJarFile.jar *.class<br>
用于創建一個名為myJarFile.jar的JAR文件，其中包含了當前目錄中的所有類文件，同時還有自動產生的詳情表文件。<br>
<br>
jar cmf myJarFile.jar myManifestFile.mf *.class<br>
與前例類似，但添加了一個名為myManifestFile.mf的用戶自建詳情表文件。<br>
<br>
jar tf myJarFile.jar<br>
生成myJarFile.jar內所有文件的一個目錄表。<br>
<br>
jar tvf myJarFile.jar<br>
添加“verbose”（詳盡）標志，提供與myJarFile.jar中的文件有關的、更詳細的資料。<br>
<br>
jar cvf myApp.jar audio classes image<br>
假定audio，classes和image是子目錄，這樣便將所有子目錄合并到文件myApp.jar中。其中也包括了“verbose”標志，可在jar程序工作時反饋更詳盡的信息。<br>
<br>
如果用O選項創建了一個JAR文件，那個文件就可置入自己的類路徑（CLASSPATH）中：<br>
CLASSPATH=&quot;lib1.jar;lib2.jar;&quot;<br>
Java能在lib1.jar和lib2.jar中搜索目標類文件。<br>
<br>
jar工具的功能沒有zip工具那么豐富。例如，不能夠添加或更新一個現成JAR文件中的文件，只能從頭開始新建一個JAR文件。此外，不能將文件移入一個JAR文件，并在移動后將它們刪除。然而，在一種平臺上創建的JAR文件可在其他任何平臺上由jar工具毫無阻礙地讀出（這個問題有時會困擾zip工具）。<br>
正如大家在第13章會看到的那樣，我們也用JAR為Java Beans打包。<br>
<br>
10.9 對象序列化<br>
Java 1.1增添了一種有趣的特性，名為“對象序列化”（Object 
Serialization）。它面向那些實現了Serializable接口的對象，可將它們轉換成一系列字節，并可在以后完全恢復回原來的樣子。這一過程亦可通過網絡進行。這意味著序列化機制能自動補償操作系統間的差異。換句話說，可以先在Windows機器上創建一個對象，對其序列化，然后通過網絡發給一臺Unix機器，然后在那里準確無誤地重新“裝配”。不必關心數據在不同機器上如何表示，也不必關心字節的順序或者其他任何細節。<br>
就其本身來說，對象的序列化是非常有趣的，因為利用它可以實現“有限持久化”。請記住“持久化”意味著對象的“生存時間”并不取決于程序是否正在執行——它存在或“生存”于程序的每一次調用之間。通過序列化一個對象，將其寫入磁盤，以后在程序重新調用時重新恢復那個對象，就能圓滿實現一種“持久”效果。之所以稱其為“有限”，是因為不能用某種“persistent”（持久）關鍵字簡單地地定義一個對象，并讓系統自動照看其他所有細節問題（盡管將來可能成為現實）。相反，必須在自己的程序中明確地序列化和組裝對象。<br>
語言里增加了對象序列化的概念后，可提供對兩種主要特性的支持。Java 
1.1的“遠程方法調用”（RMI）使本來存在于其他機器的對象可以表現出好象就在本地機器上的行為。將消息發給遠程對象時，需要通過對象序列化來傳輸參數和返回值。RMI將在第15章作具體討論。<br>
對象的序列化也是Java Beans必需的，后者由Java 1.1引入。使用一個Bean時，它的狀態信息通常在設計期間配置好。程序啟動以后，這種狀態信息必須保存下來，以便程序啟動以后恢復；具體工作由對象序列化完成。<br>
對象的序列化處理非常簡單，只需對象實現了Serializable接口即可（該接口僅是一個標記，沒有方法）。在Java 
1.1中，許多標準庫類都發生了改變，以便能夠序列化——其中包括用于基本數據類型的全部封裝器、所有集合類以及其他許多東西。甚至Class對象也可以序列化（第11章講述了具體實現過程）。<br>
為序列化一個對象，首先要創建某些OutputStream對象，然后將其封裝到ObjectOutputStream對象內。此時，只需調用writeObject()即可完成對象的序列化，并將其發送給OutputStream。相反的過程是將一個InputStream封裝到ObjectInputStream內，然后調用readObject()。和往常一樣，我們最后獲得的是指向一個上溯造型Object的句柄，所以必須下溯造型，以便能夠直接設置。<br>
對象序列化特別“聰明”的一個地方是它不僅保存了對象的“全景圖”，而且能追蹤對象內包含的所有句柄并保存那些對象；接著又能對每個對象內包含的句柄進行追蹤；以此類推。我們有時將這種情況稱為“對象網”，單個對象可與之建立連接。而且它還包含了對象的句柄數組以及成員對象。若必須自行操縱一套對象序列化機制，那么在代碼里追蹤所有這些鏈接時可能會顯得非常麻煩。在另一方面，由于Java對象的序列化似乎找不出什么缺點，所以請盡量不要自己動手，讓它用優化的算法自動維護整個對象網。下面這個例子對序列化機制進行了測試。它建立了許多鏈接對象的一個“Worm”（蠕蟲），每個對象都與Worm中的下一段鏈接，同時又與屬于不同類（Data）的對象句柄數組鏈接：<br>
<br>
490-492頁程序<br>
<br>
更有趣的是，Worm內的Data對象數組是用隨機數字初始化的（這樣便不用懷疑編譯器保留了某種原始信息）。每個Worm段都用一個Char標記。這個Char是在重復生成鏈接的Worm列表時自動產生的。創建一個Worm時，需告訴構建器希望它有多長。為產生下一個句柄（next），它總是用減去1的長度來調用Worm構建器。最后一個next句柄則保持為null（空），表示已抵達Worm的尾部。<br>
上面的所有操作都是為了加深事情的復雜程度，加大對象序列化的難度。然而，真正的序列化過程卻是非常簡單的。一旦從另外某個流里創建了ObjectOutputStream，writeObject()就會序列化對象。注意也可以為一個String調用writeObject()。亦可使用與DataOutputStream相同的方法寫入所有基本數據類型（它們有相同的接口）。<br>
有兩個單獨的try塊看起來是類似的。第一個讀寫的是文件，而另一個讀寫的是一個ByteArray（字節數組）?？衫脤θ魏蜠ataInputStream或者DataOutputStream的序列化來讀寫特定的對象；正如在關于連網的那一章會講到的那樣，這些對象甚至包括網絡。一次循環后的輸出結果如下：<br>
<br>
492-493頁程序<br>
<br>
可以看出，裝配回原狀的對象確實包含了原來那個對象里包含的所有鏈接。<br>
注意在對一個Serializable（可序列化）對象進行重新裝配的過程中，不會調用任何構建器（甚至默認構建器）。整個對象都是通過從InputStream中取得數據恢復的。<br>
作為Java 1.1特性的一種，我們注意到對象的序列化并不屬于新的Reader和Writer層次結構的一部分，而是沿用老式的InputStream和OutputStream結構。所以在一些特殊的場合下，不得不混合使用兩種類型的層次結構。<br>
<br>
10.9.1 尋找類<br>
讀者或許會奇怪為什么需要一個對象從它的序列化狀態中恢復。舉個例子來說，假定我們序列化一個對象，并通過網絡將其作為文件傳送給另一臺機器。此時，位于另一臺機器的程序可以只用文件目錄來重新構造這個對象嗎？<br>
回答這個問題的最好方法就是做一個實驗。下面這個文件位于本章的子目錄下：<br>
<br>
493頁中程序<br>
<br>
用于創建和序列化一個Alien對象的文件位于相同的目錄下：<br>
<br>
493-494頁程序<br>
<br>
該程序并不是捕獲和控制違例，而是將違例簡單、直接地傳遞到main()外部，這樣便能在命令行報告它們。<br>
程序編譯并運行后，將結果產生的file.x復制到名為xfiles的子目錄，代碼如下：<br>
<br>
494頁中程序<br>
<br>
該程序能打開文件，并成功讀取mystery對象中的內容。然而，一旦嘗試查找與對象有關的