io輸入輸出外文翻譯

1、<p>　　Java I/O系統(tǒng)</p><p>　　對(duì)于語言的設(shè)計(jì)者來說，創(chuàng)建一個(gè)好的輸入/輸出(I/O)系統(tǒng)是一項(xiàng)更艱難的任務(wù)。</p><p>　　現(xiàn)有的大量不同方案已經(jīng)說明了這一點(diǎn)。挑戰(zhàn)似乎來自于要涵蓋所有的可能性。不僅存在各種用于通信的 I/O 源端和接收端（文件、控制臺(tái)、網(wǎng)絡(luò)鏈接等），而且還需要以多種不同的方式與它們進(jìn)行通信（順序、隨機(jī)存取、緩沖、二進(jìn)制、按字符、按行

2、、按字等）。</p><p>　　Java 類庫的設(shè)計(jì)者是通過創(chuàng)建大量的類來解決這個(gè)難題的。一開始，可能會(huì)對(duì) Java I/O系統(tǒng)提供了如此多的類而感到不知所措（具有諷刺意味的是，Java I/O 設(shè)計(jì)的初衷是為了避免過多的類）。自從 Java 1.0 版本以來，Java 的 I/O 類庫發(fā)生了明顯改變，在原來面向字節(jié)的類中添加了面向字符和基于 Unicode 的類。在 JDK1.4 中，添加了 nio 類（對(duì)于

3、“新 I/O”這個(gè)稱呼，從現(xiàn)在這個(gè)名字我們?nèi)詫⒁萌舾赡辏┯糜诟倪M(jìn)性能及功能。因此，在充分理解 java I/O 系統(tǒng)以便正確地運(yùn)用之前，我們需要學(xué)習(xí)相當(dāng)數(shù)量的類。另外，很有必要理解 I/O 類庫的演化過程，即使我們的第一反應(yīng)是“不要用歷史打擾我，只需要告訴我怎</p><p>　　么用?！眴栴}是，如果缺乏歷史的眼光，很快我們就會(huì)對(duì)什么時(shí)候該使用某些類，什么時(shí)候不該使用它們而感到迷惑。</p>&l

4、t;p><b>　　輸入和輸出</b></p><p>　　I/O 類庫中通常使用“流（stream）”這個(gè)抽象概念，它代表任何有能力產(chǎn)出數(shù)據(jù)的數(shù)據(jù)源對(duì)象或者是有能力接收數(shù)據(jù)的接收端對(duì)象?！傲鳌逼帘瘟藢?shí)際的 I/O 設(shè)備中處理數(shù)據(jù)的細(xì)節(jié)。</p><p>　　Java 類庫中的 I/O 類分成輸入和輸出兩部分，可以在 JDK 文檔里的類層次結(jié)構(gòu)中查看到。通過繼承

5、，任何自 Inputstream 或 Reader 衍生而來的類都含有名為 read（）的基本方法，用于讀取單個(gè)字節(jié)或者字節(jié)數(shù)組。同樣地，任何自 OutputStream 或 Writer 衍生而來的類都含有名為 write（）的基本方法，用于寫單個(gè)字節(jié)或者字節(jié)數(shù)組。但是，我們通常不會(huì)用到這些方法，它們存在是因?yàn)閯e的類可以使用它們，以便提供更有用的接口。因此，我們很少使用一個(gè)單一的類來創(chuàng)建流對(duì)象，相反我們會(huì)通過疊合多個(gè)對(duì)象來提供所期望的

6、功能。實(shí)際上，Java 中“流”類庫讓人迷惑的主要原因就在于：創(chuàng)建一個(gè)單一的結(jié)果流，卻需要?jiǎng)?chuàng)建多個(gè)對(duì)象。</p><p>　　有必要按照這些類的功能對(duì)它們進(jìn)行分類。在 Java1.0 中，類庫的設(shè)計(jì)者首先限定與輸入有關(guān)的所有類都應(yīng)該從 InputStream 繼承，而與輸出有關(guān)的所有類都應(yīng)該從OutputStream 繼承。</p><p>　　InputStream類型</p>

7、;<p>　　InputStream 的作用是用來表示那些從不同數(shù)據(jù)源產(chǎn)生輸入的類。這些數(shù)據(jù)源包括：</p><p><b>　　字節(jié)數(shù)組</b></p><p><b>　　Sring對(duì)象</b></p><p><b>　　文件</b></p><p>　　“

8、管道”，工作方式與實(shí)際管道相似：從一段輸入，從另一端輸出。</p><p>　　一個(gè)由其他種類的流組成的序列，以便我們可以將它們收集合并到某一單一的流內(nèi)。</p><p>　　其他數(shù)據(jù)源，如Internet連接等。</p><p>　　每一種數(shù)據(jù)源都有相應(yīng)的InputStream子類。另外，F(xiàn)ilterInputStream也屬于一種InputStream，為“de

9、corator”類提供基類，其中“decorator”類可以把屬性或者有用的借口與輸入流連接在一起。</p><p>　　OutputStream類型</p><p>　　這部分包含的類決定了我們要輸出到什么地方：字節(jié)數(shù)組（非字符串，并假設(shè)我們可以用字節(jié)數(shù)組創(chuàng)建一個(gè)）、文件或管道。</p><p>　　另外，F(xiàn)ilterOutputStream 為“修飾器（deco

10、rtor）”類提供了一個(gè)基類，“修飾器”類把屬性或者有用的接口與輸出流連接了起來。</p><p>　　添加屬性和有用的接口</p><p>　　利用層疊的數(shù)個(gè)對(duì)象為單個(gè)對(duì)象動(dòng)態(tài)地和透明地添加職責(zé)的方式，稱作“修飾器”模式。（模式 1是Thinking in Patterns（用java）中討論的主題，見www.BruceEckel.com）。修飾器模式規(guī)定所有封裝于初始對(duì)象內(nèi)部的對(duì)象具有

11、相同的接口。這使得修飾器的基本應(yīng)用具有透明性——我們可以向修飾過或沒有修飾過的對(duì)象發(fā)送相同的消息。這正是Java I/O類庫里存在“filter”類的原因所在：抽象類“filter”是所有修飾類的基類。 修飾器必須具有和它所修飾的對(duì)象相同的接口，但是修飾器也可以擴(kuò)展接口，這種情況發(fā)生在幾種“filter”類中）。</p><p>　　在直接使用擴(kuò)展子類的方法時(shí)，如果導(dǎo)致產(chǎn)生了大量的、用以滿足所需的各種可能性組合的

12、子類，這時(shí)通常就會(huì)使用修飾器——處理太多的子類已不太實(shí)際。Java I/O類庫需要多種不同性質(zhì)的組合，這正是使用修飾器模式的理由所在2。但是，修飾器模式也有一個(gè)缺點(diǎn)：在我們編寫程序時(shí)，它給我們提供了相當(dāng)多的靈活性（因?yàn)槲覀兛梢院苋菀椎鼗旌虾推ヅ鋵傩裕?，但是它同時(shí)也增加了我們代碼的復(fù)雜性。Java IO類庫操作不便的原因在于：我們必須創(chuàng)建許多類——“核心”IO類型加上所有的修飾器——才能得到我們所希望的單個(gè)IO對(duì)象。</p>

13、<p>　　FilterInputStream 和 FilterOutputStream 是提供給修飾接口用于控制特定輸入流（InputStream）和輸出流（OutputStream）的兩個(gè)類，它們的名字并不是很直觀。FilterInputStream 和 FilterOutputStream 自 I/O 類庫中的基類——輸入流（InputStream）和輸出流（OutputStream）衍生而來，這兩個(gè)類是修飾器的必要條

14、件（以便能為所有正在被修飾的對(duì)象提供通用接口）。</p><p><b>　　讀和寫</b></p><p>　　Java1.1 對(duì)基本的 I/O“流”類庫進(jìn)行了重大的修改。當(dāng)我們初次看見 Reader 和 Writer 類時(shí)，可能會(huì)以為這是兩個(gè)用來替代 InputStream 和 OutputStreamt 的類。但實(shí)際上并不是這樣。盡管一些原始的“流”類庫不再被使

15、用（如果使用它們，則會(huì)收到編譯器的警告信息），但是 InputStream 和 OutputStreamt 在以面向字節(jié)形式的 I/O 中仍可以提供極有價(jià)值的功能，Reader 和 Writer 則提供兼容 Unicode 與面向字符的 I/O 的功能。另外：</p><p>　　1. Java1.1 向 InputStream 和 OutputStreamt 繼承層次結(jié)構(gòu)中添加了一些新類，所以很明顯在這些層次

16、結(jié)構(gòu)中的類是不會(huì)被取代的。</p><p>　　2. 有時(shí)我們必須把來自于“字節(jié)”層次結(jié)構(gòu)中的類和“字符”層次結(jié)構(gòu)中的類結(jié)合起來使用。為了實(shí)現(xiàn)這個(gè)目的，要用到“適配器（adapter）”類：InputStreamReader可以把 InputStream 轉(zhuǎn)換為 Reader，OutputStreamWriter 可以把OutputStream 轉(zhuǎn)換為 Writer。</p><p>　

17、　設(shè)計(jì) Reader 和 Writer 繼承層次結(jié)構(gòu)主要是為了國(guó)際化。老的 I/O 流繼承層次結(jié)構(gòu)僅支持8 位字節(jié)流，并且不能很好地處理 16 位的 Unicode 字符。既然 Unicode 是用來國(guó)際化的（Java 本身的 char 也是 16 位的 Unicode），因此添加 Reader 和 Writer 繼承層次結(jié)構(gòu)就是為了在所有的 I/O 操作中都支持 Unicode。另外，新類庫的設(shè)計(jì)使得它的操作比舊類庫更快。</p

18、><p><b>　　標(biāo)準(zhǔn)I/O</b></p><p>　　“標(biāo)準(zhǔn) I/O”這個(gè)術(shù)語參考的是 Unix 中“程序所使用的單一信息流”這個(gè)概念（在 windows和其他許多操作系統(tǒng)中，也有相似形式的實(shí)現(xiàn)）。程序的所有輸入都可以來自于“標(biāo)準(zhǔn)輸入”，它的所有輸出也都可以發(fā)送到“標(biāo)準(zhǔn)輸出”，以及所有的錯(cuò)誤信息都可以發(fā)送到“標(biāo)準(zhǔn)錯(cuò)誤”。標(biāo)準(zhǔn) I/O 的意義在于：我們可以很容易地把

19、程序串聯(lián)起來，一個(gè)程序的標(biāo)準(zhǔn)輸出可以成為另一程序的標(biāo)準(zhǔn)輸入。這真是一個(gè)強(qiáng)大的工具。</p><p><b>　　從標(biāo)準(zhǔn)輸入讀取</b></p><p>　　按照標(biāo)準(zhǔn) I/O 模型，Java 提供了 System.in，System.out 和 System.err。在整本書里，我們已經(jīng)看到了怎樣用 System.out 將數(shù)據(jù)寫出到標(biāo)準(zhǔn)輸出，其中 System.out

20、 已經(jīng)事先被包裝成了 printStream 對(duì)象。System.err 同樣也是 PrintStream，但 System.in 卻是一個(gè)沒有被包裝的未經(jīng)加工的 InputStream。這意味盡管我們可以立即使用System.out 和 System.err，但是在讀取System.in 之前必須對(duì)其進(jìn)行包裝。</p><p>　　通常我們會(huì)用 readLine()一次一行地讀取輸入，因此我們會(huì)將 System

21、.in 包裝成BufferedReader 來使用。為此，我們必須用 InputStreamReader 把 System.in 轉(zhuǎn)換成Reader。</p><p><b>　　標(biāo)準(zhǔn)I/O重定向</b></p><p>　　Java 的 System 類提供一些簡(jiǎn)單的靜態(tài)方法調(diào)用，允許我們對(duì)標(biāo)準(zhǔn)輸入、輸出和錯(cuò)誤 I/O流進(jìn)行重定向：</p><p

22、>　　setIn(InputStream)</p><p>　　setOut(PrintStream)</p><p>　　setErr(PrintStream)</p><p>　　如果我們突然開始在顯示器上創(chuàng)建大量輸出，而這些輸出滾動(dòng)的如此之快以至于無法閱讀時(shí)，重定向輸出就顯得極為有用4。對(duì)于“我們想重復(fù)測(cè)試特定用戶的輸入序列”的命令行程序來說，重定向輸入

23、就很有價(jià)值。</p><p><b>　　新I/O</b></p><p>　　JDK1.4 的java.nio.*包中引入了Java新的I/O類庫，其目的在于提高速度。實(shí)際上，舊的I/O包已經(jīng)使用nio重新實(shí)現(xiàn)過，以便充分利用這種速度提高，因此，即使我們不顯式地用nio編寫代碼，也能從中受益。速度的提高在文件I/O和網(wǎng)絡(luò)I/O中都有可能發(fā)生，我們?cè)谶@里只研究前者 5

24、，對(duì)于后者，將會(huì)在Thinking in Enterprise Java中涉及到。</p><p>　　速度的提高來自于所使用的結(jié)構(gòu)更接近于操作系統(tǒng)執(zhí)行 I/O 的方式：通道和緩沖器。我們可以把它想象成一個(gè)煤礦；通道是一個(gè)包含煤層（數(shù)據(jù)）的礦藏，而緩沖器則我們派送到礦藏的卡車?？ㄜ囕d滿煤炭而歸，我們?cè)購(gòu)目ㄜ嚿汐@得煤炭。也就是說，我們并沒有直接和通道交互；我們只是和緩沖器交互，并把緩沖器派送到通道。通道要么從緩沖器

25、獲得數(shù)據(jù)，要么向緩沖器發(fā)送數(shù)據(jù)。</p><p>　　唯一直接與通道交互的緩沖器是 ByteBuffer——也就是說，可以存儲(chǔ)未加工字節(jié)的緩沖器。當(dāng)我們查詢 JDK 文檔中的 java.nio.ByteBuffer 時(shí)，會(huì)發(fā)現(xiàn)它是相當(dāng)基礎(chǔ)的類：通過告知分配多少存儲(chǔ)空間來創(chuàng)建一個(gè) ByteBuffer 對(duì)象，并且還有一個(gè)方法選擇的集用于以未加工的字節(jié)形式或原始的數(shù)據(jù)類型輸出和讀取數(shù)據(jù)。但是，沒辦法輸出或讀取對(duì)象，即

26、使是字符串對(duì)象也不行。這種處理雖然是低水平但卻正好，因?yàn)檫@是大多數(shù)操作系統(tǒng)中更有效的映射方式。</p><p>　　舊 I/O 類庫中有三個(gè)類被改進(jìn)了，用以產(chǎn)生 FileChannel，它們是： FileInputStream，F(xiàn)ileOutputStream 以及用于既讀又寫的 RandomAccessFile。注意這些是字節(jié)操縱流，與低層的 nio 特性一致。Reader 和 Writer 的字符模式類不能用

27、于產(chǎn)生通道，但是java.nio.channels.Channels 類能提供實(shí)用方法在通道中產(chǎn)生 Reader 和 Writer。</p><p>　　原文出處《Thinking in Java 4th》，作者：Bruce Eckel</p><p>　　Java I/O System</p><p>　　Creating a good input/output

28、(I/O) system is one of the more difficult tasks for a language designer. This is evidenced by the number of different approaches. </p><p>　　The challenge seems to be in covering all possibilities. Not only a

29、re there different sources and sinks of I/O that you want to communicate with (files, the console, network connections, etc.), but you need to talk to them in a wide variety of ways (sequential, random-access, buffered,

30、binary, character, by lines, by words, etc.). The Java library designers attacked this problem by creating lots of classes. In fact, there are so many classes for Java’s I/O system that it can be intimidating at f</p&

31、gt;<p>　　Input and Output </p><p>　　Programming language I/O libraries often use the abstraction of a stream, which represents any data source or sink as an object capable of producing or receiving pi

32、eces of data. The stream hides the details of what happens to the data inside the actual I/O device. </p><p>　　The Java library classes for I/O are divided by input and output, as you can see by looking at t

33、he class hierarchy in the JDK documentation. Through inheritance, everything derived from the InputStream or Reader classes has basic methods called read( ) for reading a single byte or an array of bytes. Likewise, every

34、thing derived from OutputStream or Writer classes has basic methods called write( ) for writing a single byte or an array of bytes. However, you won’t generally use these methods; they</p><p>　　It’s helpful

35、to categorize the classes by their functionality. In Java l.o, the library designers started by deciding that all classes that had anything to do with input would be inherited from InputStream, and all classes that were

36、associated with output would be inherited from OutputStream.</p><p>　　Type of InputStream</p><p>　　InputStream’s job is to represent classes that produce input from different sources. These sour

37、ces can be:</p><p>　　1. An array of bytes. </p><p>　　2. A String obj ect. </p><p>　　3. A file. </p><p>　　4. A "pipe," which works like a physical pipe: Yo

38、u put things in at one end and they come out the other.</p><p>　　5. A sequence of other streams, so you can collect them together into a single stream. </p><p>　　6. Other sources, such as an I

39、nternet connection. </p><p>　　Each of these has an associated subclass of InputStream. In addition, the FilterInputStream is also a type of InputStream, to provide a base class for "decorator" clas

40、ses that attach attributes or useful interfaces to input streams.</p><p>　　Types of OutputStream</p><p>　　This category includes the classes that decide where your output will go: an array of by

41、tes (but not a String—presumably, you can create one using the array of bytes), a file, or a "pipe." </p><p>　　In addition, the FilterOutputStream provides a base class for "decorator" cl

42、asses that attach attributes or useful interfaces to output streams. This is discussed later.</p><p>　　Adding attributes and useful interfaces</p><p>　　Decorators were introduced in the Generics

43、 chapter, on page 717. The Java I/O library requires many different combinations of features, and this is the justification for using the Decorator design pattern.1 The reason for the existence of the "filter"

44、classes in the Java I/O library is that the abstract "filter" class is the base class for all the decorators. A decorator must have the same interface as the object it decorates, but the decorator can also exte

45、nd the interface, which occurs in seve</p><p>　　There is a drawback to Decorator, however. Decorators give you much more flexibility while you’re writing a program (since you can easily mix and match attribu

46、tes), but they add complexity to your code. The reason that the Java I/O library is awkward to use is that you must create many classes—the "core" I/O type plus all the decorators—in order to get the single I/O

47、 object that you want. </p><p>　　The classes that provide the decorator interface to control a particular InputStream or OutputStream are the FilterlnputStream and FilterOutputStream, which don’t have very i

48、ntuitive names. FilterlnputStream and FilterOutputStream are derived from the base classes of the I/O library, InputStream and OutputStream, which is a key requirement of the decorator (so that it provides the common int

49、erface to all the objects that are being decorated).</p><p>　　Readers & Writers</p><p>　　Java 1.1 made significant modifications to the fundamental I/O stream library. When you see the Reade

50、r and Writer classes, your first thought (like mine) might be that these were meant to replace the InputStream and OutputStream classes. But that’s not the case. Although some aspects of the original streams library are

51、deprecated (if you use them you will receive a warning from the compiler), the InputStream and OutputStream classes still provide valuable functionality in the form of byte-orient</p><p>　　1. Java 1.1 added

52、 new classes into the InputStream and OutputStream hierarchy, so it’s obvious those hierarchies weren’t being replaced. </p><p>　　2. There are times when you must use classes from the "byte" hiera

53、rchy in combination with classes in the "character" hierarchy. To accomplish this, there are "adapter" classes: InputStreamReader converts an InputStream to a Reader, and OutputStreamWriter converts a

54、n OutputStream to a Writer. </p><p>　　The most important reason for the Reader and Writer hierarchies is for internationalization. The old I/O stream hierarchy supports only 8-bit byte streams and doesn’t ha

55、ndle the 16-bit Unicode characters well. Since Unicode is used for internationalization (and Java’s native char is 16-bit Unicode), the Reader and Writer hierarchies were added to support Unicode in all I/O operations. I

56、n addition, the new libraries are designed for faster operations than the old.</p><p>　　Standard I/O</p><p>　　The term standard I/O refers to the Unix concept of a single stream of information t

57、hat is used by a program (this idea is reproduced in some form in Windows and many other operating systems). All of the program’s input can come from standard input, all of its output can go to standard output, and all o

58、f its error messages can be sent to standard error. The value of standard I/O is that programs can easily be chained together, and one program’s standard output can become the standard input for a</p><p>　　R

59、eading from standard input</p><p>　　Following the standard I/O model, Java has System.in, System.out, and System.err. Throughout this book, you’ve seen how to write to standard output using System.out, which

60、 is already pre-wrapped as a PrintStream object. System.err is likewise a PrintStream, but System.in is a raw InputStream with no wrapping. This means that although you can use System.out and System.err right away, Syste

61、m.in must be wrapped before you can read from it.</p><p>　　You’ll typically read input a line at a time using readLine( ). To do this, wrap System.in in a BufferedReader, which requires you to convert System

62、.in to a Reader using InputStreamReader.</p><p>　　Redirecting</p><p>　　The Java System class allows you to redirect the standard input, output, and error I/O streams using simple static method c

63、alls:</p><p>　　setIn(InputStream) </p><p>　　setOut(PrintStream) </p><p>　　setErr(PrintStream)</p><p>　　Redirecting output is especially useful if you suddenly start cre

64、ating a large amount of output on your screen, and it’s scrolling past faster than you can read it.4 Redirecting input is valuable for a command-line program in which you want to test a particular user-input sequence rep

65、eatedly.</p><p><b>　　New I/O</b></p><p>　　The Java "new" I/O library, introduced in JDK 1.4 in the java.nio.* packages, has one goal: speed. In fact, the "old" I/

66、O packages have been reimplemented using nio in order to take advantage of this speed increase, so you will benefit even if you don’t explicitly write code with nio. The speed increase occurs both in file I/O, which is e

67、xplored here, and in network I/O, which is covered in Thinking in Enterprise Java. </p><p>　　The speed comes from using structures that are closer to the operating system’s way of performing I/O: channels an

68、d buffers. You could think of it as a coal mine; the channel is the mine containing the seam of coal (the data), and the buffer is the cart that you send into the mine. The cart comes back full of coal, and you get the c

69、oal from the cart. That is, you don’t interact directly with the channel; you interact with the buffer and send the buffer into the channel. The channel either pulls </p><p>　　The only kind of buffer that co

70、mmunicates directly with a channel is a ByteBuffer—that is, a buffer that holds raw bytes. If you look at the JDK documentation for java.nio.ByteBuffer, you’ll see that it’s fairly basic: You create one by telling it how

71、 much storage to allocate, and there are methods to put and get data, in either raw byte form or as primitive data types. But there’s no way to put or get an object, or even a String. It’s fairly low-level, precisely bec

72、ause this makes a more effici</p><p>　　Three of the classes in the "old" I/O have been modified so that they produce a FileChannel: FileInputStream, FileOutputStream, and, for both reading and writ

73、ing, RandomAccessFile. Notice that these are the byte manipulation streams, in keeping with the low-level nature of nio. The Reader and Writer character-mode classes do not produce channels, but the java.nio.channels.Cha