|
[書籍導讀]
Java 網路程式設計 第二版
本書譯自 Elliote Rusty Harold 的經典之作，《Java Network Programming
, 2nd Edition》，原文篇幅 710 頁，分 19 章，以 Java 2（J2SE 1.2、1.3）為開發環境基礎，主題涵蓋網路基本概念、Java
的基本網路機制（Socket、URL、Protocol/Content Handler）、基本網路服務（DNS、TCP、UDP）、網路程式的相關設計技巧（thread、I/O）、用戶端、伺服端、Socket、RMI、以及
Java Mail API。
除了大主題「網路程式設計」之外，本書另一個可觀之處在於範例程式。作者的高明之處，不在於寫出能闡述 Java
API 用法的程式，而在於若隱若現的程式美感。誠如作者對自己的期許：『寫出能當成「典範」（pattern）的範例』，隨著翻譯工作的進行，我逐漸感受到作者的用心。有許多範例，我誠摯建議讀者自己動手鍵入程式碼，那樣會比直接從網路下載現成版本更有學習效果。如果讀者手邊有一本四人幫寫的《Design
Pattern》，不妨在測試本書範例程式後，試著改寫原版程式碼，或許試著增加新功能、或改用不同的 design pattern、或是想辦法改寫成可再利用的元件、或是思考如何程式重整（refactoring），唯有這樣，才能真正享受這本書帶來的樂趣。
本書能帶給讀者的另一項收穫，是閱讀 Java API doc 的能力。Java API doc 的權威無庸置疑，但是其枯燥乏味與缺少範例的特性也是出了名。當你遇到不熟悉的類別時，Java
API doc 是首先會被想到的參考資料，但是許多人常有這樣的經驗：找不到所要的功能性，或是沒有具體範例可以參考，或是搞不清楚 API
的設計理念，或是牽涉太廣、太龐雜，而找不到頭緒。在本書，你可以看到作者是如何從 class 或 method 的宣告形式（signature）看出它們的用法，以及如何摸索線索。當你學會了作者的思考方式，你就有自己學習新事物的能力。在本書第八章，作者就示範了如何在
Java Swing API 中挖寶，示範如何發掘、使用 Java 不為人知的 HTML 分析能力。
作者在寫作這本書時，是假設讀者已經具備最基本的 Java 程式設計能力，並且熟悉 Java 的物件導向術語，像是
class、method、interface、field、subcalssing、superclass、overload、override
... 等等。本書的範例都很「物件導向」，如果讀者對 OO 的概念還不熟悉，閱讀本書會很吃力，建議你先打好 Java 的基礎，然後才看本書，否則本書帶給你的可能不是成就感，而是挫折感。
翻譯原則
關於本書的章節編排，作者已經在原序交代清楚了，甚至連閱讀順序都事先為讀者設想好了，所以在此不再贅述。我想交代的是關於譯詞與譯文的取決原則：
- 避免同一個詞同時出現中英文。例如：以「POP server」代替「POP 伺服器」，以「client
socket」代替「用戶端 socket」，以「協定處理器」或「protocol handler」代替「協定 handler」。
- 譯詞盡量簡短達意。例如：stream 有兩種常見譯詞，分別為「資料流」與「串流」，我採用後者，這不僅是因為「串流」比較簡潔，也因為它比較達意，更重要的是，並非所有
stream 都一定是「資料」。
- 無公認譯詞者，以原文出現。例如：stub 與 skeleton。這類術語往往使得相關的形容詞或副詞也必須以原文出現，例如：client
stub、stub class，儘管 class 和 client 都有公認的中譯詞，但是為了強調術語的完整性，所以直接以原文出現。
- 動詞不採用原文。例如：『subclassing SpecificSuperClass 』，我會改寫成『繼承
SpecificSuperClass』或『寫出 SpecificSuperClass 的子類別』。
- 譯意不譯字。有許多文句很難直譯成中文，或是直譯成中文後讓人啼笑皆非，這樣的例子太多，多到我不知如何舉例說明。我只能說，我會將所有關鍵詞句都譯出來，但是整個句構可能與原文大異其趣，甚至多了一些原文沒有的句子，用以連貫前後文。
- 盡量先因後果。英文的作文風格是先果後因，也就是先告訴你答案，後解釋原因。但是中文的行文習慣剛好相友，我個人習慣先說前因，後說結果。不過，有許多需要大費周章解釋的事情，我會依照作者的鋪陳順序。
- 譯詞盡量一致。
以上所述原則並非一成不變，因為即使是原則也總有例外（像這句話就已經違反第六項「先因後果」的原則），尤其是第七項原則。譯詞難以保持一致的原因很多，我個人才學不足是原因之一，現有譯詞不理想也是原因；舉例來說，「superclass」一般是翻譯成「父類別」、「母類別」、「超類別」、「親代類別」等等，但是我個人最偏好的譯詞是「廣義類別」，因為此詞最達意，而且其相對詞－「subclass」－
剛好可翻譯成「狹義類別」。但是在強調類別之間的從屬關係時，這種譯法給人的感覺反而不如「父類別」與「子類別」強烈，在用字上也不夠簡潔。因此我有時會採用「廣義類別」，但有時又會不自覺地採用「父類別」。關於這點，還請讀者見諒。
中文版與英文版的差異
本書修正了 2001 年十月之前在原文書找到的所有錯誤。此外，由於原文書出版時，當時最新的 JDK 版本是
Java 1.3beta，所以作者也只提到 Java 1.3 而已。然而，在本書中文版的編譯過程中，Sun 已經正式發表了 J2SE 1.4，為此，我特地取得作者同意，在適當章節安插
J2SE 1.4 新增功能的說明。比方說，Java 1.4 為了支援 IPv6，將 InetAddress 再細分（subclassing）成
Inet4Address 與 Inet6Address；為了將 IP address 與 port 整合在一起，Java 1.4 新增了
SocketAddress 類別；URLEncoder 類別的 encode(String) 方法被棄置（deprecated），改以
encode(String s, String enc) 方法代替。在遇到這些與 Java 1.4 變革的相關議題時，我會額外添加說明篇幅。不過，這本書畢竟不是我的創作，而我也沒有喧賓奪主的才學，所以我的增補僅是為了讓本書題材更齊全，能跟上最新
Java 版本而已，而不能像作者那樣作全面性的完整說明。事實上，Java 1.4 在網路方面的著墨相當深刻，所作的改變幅度相當大，我認為光是描述
Java 1.4 的變革，就值得另外寫出一本書了。因此，在本書封面，我們只能標榜『本書涵蓋 Java 1.2、1.3』，而不能說本書涵蓋了
Java 1.4，雖然我確實增添了不少關於 Java 1.4 的篇幅，而且所有範例程式也都在 Java 1.4.1 測試過了。
Java 1.4 新增的 New I/O 對網路程式設計的影響不可謂不大，不管是在程式寫作技巧方面，或是在程式運作效能方面。然而，New
I/O 這項題材實在太過龐大，我實在無法在本書增闢關於 New I/O 的章節，為了彌補本書的不足，我建議讀者參考 Ron Hitchens
所著的《Java NIO》（http://www.oreilly.com/catalog/javanio/）。
本書範例
本書所有範例程式皆可從 O'Reilly 與作者的個人網站下載：
O'Reilly 美國總公司：
http://www.oreilly.com/catalog/javanp2/
O'Reilly 台灣分公司：http://www.oreilly.com.tw/chinese/java/javanet2.html
作者個人網站：http://www.ibiblio.org/javafaq/
作者個人網站與 O'Reilly 美國總公司網站所提供的版本，是作者提供的測試版，有些範例並不完全正確。我放在
O'Reilly 台灣分公司的是經過修正的版本，全部都經過 Java 1.4 測試。
在測試本書範例程式時，我建議讀者最好至少準備兩台電腦，如果可能，我強烈建議讀者至少準備一部 Linux
系統當伺服平台，因為有些範例需要搭配 Linux 系統內建的 server，像是 whois、chargen、time 等等，而這些 server
都是 Windows 伺服平台不提供的。不過，即使沒有 Linux server 配合，讀者其實也可以順利測試這些範例，那就是自己動手寫出
Java server － 相信我，這絕對不難，因為作者已經提供了寫出這些 server 的必備知識與工具，甚至有雛型程式可供摹擬。換個角度想，這不正就是本書的主題嗎？讀者剛好可藉此驗證自己的學習成果。
批評指教
事實上，中英文版之間，其實還有一項差異，那就是中文版內容本身的錯誤。儘管我花了很多功夫確保本書的翻譯品質，不過，不管再怎麼嚴謹的校閱程序，我仍不敢保證本書絕無錯誤。如果讀者認為本書譯文有任何模稜兩可或交代不清之處，或是有任何錯誤（漏字、錯字、贅字、技術描述
...），或是您有任何能使本書更好的建議，我非常歡迎讀者提供批評指教。
台灣歐萊禮公司特地設置 bookquestions@oreilly.com.tw
信箱，我很珍惜每一位讀者的任何指教與意見。對於讀者提出的任何糾正，在經過查證之後，我會公佈在本書中文網頁（http://www.oreilly.com.tw/chinese/java/javanet2.html）的勘誤表，並於下一刷時改正。如果您對本書的內容有疑問，在您回報錯誤之前，請先查閱本書中文網頁上的勘誤表，看看是不是已經有人發現了。
林長毅 僅識
lin@oreilly.com
2001 年 11 月 12 日於三重 |
