IO输入输出外文翻译.doc

13中原工学院信息商务学院毕业设计（论文）译文专用纸java i/o系统对于语言的设计者来说，创建一个好的输入/输出(i/o)系统是一项更艰难的任务。现有的大量不同方案已经说明了这一点。挑战似乎来自于要涵盖所有的可能性。不仅存在各种用于通信的 i/o 源端和接收端（文件、控制台、网络链接等），而且还需要以多种不同的方式与它们进行通信（顺序、随机存取、缓冲、二进制、按字符、按行、按字等）。java 类库的设计者是通过创建大量的类来解决这个难题的。一开始，可能会对 java i/o系统提供了如此多的类而感到不知所措（具有讽刺意味的是，java i/o 设计的初衷是为了避免过多的类）。自从 java 1.0 版本以来，java 的 i/o 类库发生了明显改变，在原来面向字节的类中添加了面向字符和基于 unicode 的类。在 jdk1.4 中，添加了 nio 类（对于“新 i/o”这个称呼，从现在这个名字我们仍将要用若干年）用于改进性能及功能。因此，在充分理解 java i/o 系统以便正确地运用之前，我们需要学习相当数量的类。另外，很有必要理解 i/o 类库的演化过程，即使我们的第一反应是“不要用历史打扰我，只需要告诉我怎么用。”问题是，如果缺乏历史的眼光，很快我们就会对什么时候该使用某些类，什么时候不该使用它们而感到迷惑。输入和输出i/o 类库中通常使用“流（stream）”这个抽象概念，它代表任何有能力产出数据的数据源对象或者是有能力接收数据的接收端对象。“流”屏蔽了实际的 i/o 设备中处理数据的细节。java 类库中的 i/o 类分成输入和输出两部分，可以在 jdk 文档里的类层次结构中查看到。通过继承，任何自 inputstream 或 reader 衍生而来的类都含有名为 read（）的基本方法，用于读取单个字节或者字节数组。同样地，任何自 outputstream 或 writer 衍生而来的类都含有名为 write（）的基本方法，用于写单个字节或者字节数组。但是，我们通常不会用到这些方法，它们存在是因为别的类可以使用它们，以便提供更有用的接口。因此，我们很少使用一个单一的类来创建流对象，相反我们会通过叠合多个对象来提供所期望的功能。实际上，java 中“流”类库让人迷惑的主要原因就在于：创建一个单一的结果流，却需要创建多个对象。有必要按照这些类的功能对它们进行分类。在 java1.0 中，类库的设计者首先限定与输入有关的所有类都应该从 inputstream 继承，而与输出有关的所有类都应该从outputstream 继承。inputstream类型inputstream 的作用是用来表示那些从不同数据源产生输入的类。这些数据源包括：1. 字节数组2. sring对象3. 文件4. “管道”，工作方式与实际管道相似：从一段输入，从另一端输出。5. 一个由其他种类的流组成的序列，以便我们可以将它们收集合并到某一单一的流内。6. 其他数据源，如internet连接等。每一种数据源都有相应的inputstream子类。另外，filterinputstream也属于一种inputstream，为“decorator”类提供基类，其中“decorator”类可以把属性或者有用的借口与输入流连接在一起。outputstream类型这部分包含的类决定了我们要输出到什么地方：字节数组（非字符串，并假设我们可以用字节数组创建一个）、文件或管道。另外，filteroutputstream 为“修饰器（decortor）”类提供了一个基类，“修饰器”类把属性或者有用的接口与输出流连接了起来。添加属性和有用的接口利用层叠的数个对象为单个对象动态地和透明地添加职责的方式，称作“修饰器”模式。（模式 1是thinking in patterns（用java）中讨论的主题，见www.brucee）。修饰器模式规定所有封装于初始对象内部的对象具有相同的接口。这使得修饰器的基本应用具有透明性我们可以向修饰过或没有修饰过的对象发送相同的消息。这正是java i/o类库里存在“filter”类的原因所在：抽象类“filter”是所有修饰类的基类。 修饰器必须具有和它所修饰的对象相同的接口，但是修饰器也可以扩展接口，这种情况发生在几种“filter”类中）。在直接使用扩展子类的方法时，如果导致产生了大量的、用以满足所需的各种可能性组合的子类，这时通常就会使用修饰器处理太多的子类已不太实际。java i/o类库需要多种不同性质的组合，这正是使用修饰器模式的理由所在2。但是，修饰器模式也有一个缺点：在我们编写程序时，它给我们提供了相当多的灵活性（因为我们可以很容易地混合和匹配属性），但是它同时也增加了我们代码的复杂性。java io类库操作不便的原因在于：我们必须创建许多类“核心”io类型加上所有的修饰器才能得到我们所希望的单个io对象。filterinputstream 和 filteroutputstream 是提供给修饰接口用于控制特定输入流（inputstream）和输出流（outputstream）的两个类，它们的名字并不是很直观。filterinputstream 和 filteroutputstream 自 i/o 类库中的基类输入流（inputstream）和输出流（outputstream）衍生而来，这两个类是修饰器的必要条件（以便能为所有正在被修饰的对象提供通用接口）。读和写java1.1 对基本的 i/o“流”类库进行了重大的修改。当我们初次看见 reader 和 writer 类时，可能会以为这是两个用来替代 inputstream 和 outputstreamt 的类。但实际上并不是这样。尽管一些原始的“流”类库不再被使用（如果使用它们，则会收到编译器的警告信息），但是 inputstream 和 outputstreamt 在以面向字节形式的 i/o 中仍可以提供极有价值的功能，reader 和 writer 则提供兼容 unicode 与面向字符的 i/o 的功能。另外：1. java1.1 向 inputstream 和 outputstreamt 继承层次结构中添加了一些新类，所以很明显在这些层次结构中的类是不会被取代的。2. 有时我们必须把来自于“字节”层次结构中的类和“字符”层次结构中的类结合起来使用。为了实现这个目的，要用到“适配器（adapter）”类：inputstreamreader可以把 inputstream 转换为 reader，outputstreamwriter 可以把outputstream 转换为 writer。设计 reader 和 writer 继承层次结构主要是为了国际化。老的 i/o 流继承层次结构仅支持8 位字节流，并且不能很好地处理 16 位的 unicode 字符。既然 unicode 是用来国际化的（java 本身的 char 也是 16 位的 unicode），因此添加 reader 和 writer 继承层次结构就是为了在所有的 i/o 操作中都支持 unicode。另外，新类库的设计使得它的操作比旧类库更快。标准i/o“标准 i/o”这个术语参考的是 unix 中“程序所使用的单一信息流”这个概念（在 windows和其他许多操作系统中，也有相似形式的实现）。程序的所有输入都可以来自于“标准输入”，它的所有输出也都可以发送到“标准输出”，以及所有的错误信息都可以发送到“标准错误”。标准 i/o 的意义在于：我们可以很容易地把程序串联起来，一个程序的标准输出可以成为另一程序的标准输入。这真是一个强大的工具。从标准输入读取按照标准 i/o 模型，java 提供了 system.in，system.out 和 system.err。在整本书里，我们已经看到了怎样用 system.out 将数据写出到标准输出，其中 system.out 已经事先被包装成了 printstream 对象。system.err 同样也是 printstream，但 system.in 却是一个没有被包装的未经加工的 inputstream。这意味尽管我们可以立即使用system.out 和 system.err，但是在读取system.in 之前必须对其进行包装。通常我们会用 readline()一次一行地读取输入，因此我们会将 system.in 包装成bufferedreader 来使用。为此，我们必须用 inputstreamreader 把 system.in 转换成reader。标准i/o重定向java 的 system 类提供一些简单的静态方法调用，允许我们对标准输入、输出和错误 i/o流进行重定向：setin(inputstream)setout(printstream)seterr(printstream)如果我们突然开始在显示器上创建大量输出，而这些输出滚动的如此之快以至于无法阅读时，重定向输出就显得极为有用4。对于“我们想重复测试特定用户的输入序列”的命令行程序来说，重定向输入就很有价值。新i/ojdk1.4 的java.nio.*包中引入了java新的i/o类库，其目的在于提高速度。实际上，旧的i/o包已经使用nio重新实现过，以便充分利用这种速度提高，因此，即使我们不显式地用nio编写代码，也能从中受益。速度的提高在文件i/o和网络i/o中都有可能发生，我们在这里只研究前者 5，对于后者，将会在thinking in enterprise java中涉及到。速度的提高来自于所使用的结构更接近于操作系统执行 i/o 的方式：通道和缓冲器。我们可以把它想象成一个煤矿；通道是一个包含煤层（数据）的矿藏，而缓冲器则我们派送到矿藏的卡车。卡车载满煤炭而归，我们再从卡车上获得煤炭。也就是说，我们并没有直接和通道交互；我们只是和缓冲器交互，并把缓冲器派送到通道。通道要么从缓冲器获得数据，要么向缓冲器发送数据。唯一直接与通道交互的缓冲器是 bytebuffer也就是说，可以存储未加工字节的缓冲器。当我们查询 jdk 文档中的 java.nio.bytebuffer 时，会发现它是相当基础的类：通过告知分配多少存储空间来创建一个 bytebuffer 对象，并且还有一个方法选择的集用于以未加工的字节形式或原始的数据类型输出和读取数据。但是，没办法输出或读取对象，即使是字符串对象也不行。这种处理虽然是低水平但却正好，因为这是大多数操作系统中更有效的映射方式。旧 i/o 类库中有三个类被改进了，用以产生 filechannel，它们是： fileinputstream，fileoutputstream 以及用于既读又写的 randomaccessfile。注意这些是字节操纵流，与低层的 nio 特性一致。reader 和 writer 的字符模式类不能用于产生通道，但是java.nio.channels.channels 类能提供实用方法在通道中产生 reader 和 writer。原文出处thinking in java 4th，作者：bruce eckeljava i/o systemcreating a good input/output (i/o) system is one of the more difficult tasks for a language designer. this is evidenced by the number of different approaches. the challenge seems to be in covering all possibilities. not only are 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, 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 javas i/o system that it can be intimidating at first (ironically, the java i/o design actually prevents an explosion of classes). there was also a significant change in the i/o library after java i.o, when the original byte-oriented library was supplemented with char-oriented, unicode-based i/o classes. the nio classes (for new i/o, a name well still be using years from now even though they were introduced in jdk 1.4 and so are already old) were added for improved performance and functionality. as a result, there are a fair number of classes to learn before you understand enough of javas i/o picture that you can use it properly. in addition, its rather important to understand the evolution of the i/o library, even if your first reaction is dont bother me with history, just show me how to use it! the problem is that without the historical perspective, you will rapidly become confused with some of the classes and when you should and shouldnt use them.input and output 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 pieces of data. the stream hides the details of what happens to the data inside the actual i/o device. the java library classes for i/o are divided by input and output, as you can see by looking at the 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, everything derived from outputstream or writer classes has basic methods called write( ) for writing a single byte or an array of bytes. however, you wont generally use these methods; they exist so that other classes can use themthese other classes provide a more useful interface. thus, youll rarely create your stream object by using a single class, but instead will layer multiple objects together to provide your desired functionality (this is the decorator design pattern, as you shall see in this section). the fact that you create more than one object to produce a single stream is the primary reason that javas i/o library is confusing. its helpful 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 associated with output would be inherited from outputstream.type of inputstreaminputstreams job is to represent classes that produce input from different sources. these sources can be:1. an array of bytes. 2. a string obj ect. 3. a file. 4. a pipe, which works like a physical pipe: you put things in at one end and they come out the other.5. a sequence of other streams, so you can collect them together into a single stream. 6. other sources, such as an internet connection. 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 classes that attach attributes or useful interfaces to input streams.types of outputstreamthis category includes the classes that decide where your output will go: an array of bytes (but not a stringpresumably, you can create one using the array of bytes), a file, or a pipe. in addition, the filteroutputstream provides a base class for decorator classes that attach attributes or useful interfaces to output streams. this is discussed later.adding attributes and useful interfacesdecorators were introduced in the generics 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 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 extend the interface, which occurs in several of the filter classes. there is a drawback to decorator, however. decorators give you much more flexibility while youre writing a program (since you can easily mix and match attributes), 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 classesthe core i/o type plus all the decoratorsin order to get the single i/o object that you want. the classes that provide the decorator interface to control a particular inputstream or outputstream are the filterlnputstream and filteroutputstream, which dont have very intuitive 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 interface to all the objects that are being decorated).readers & writersjava 1.1 made significant modifications to the fundamental i/o stream library. when you see the reader and writer classes, your first thought (like mine) might be that these were meant to replace the inputstream and outputstream classes. but thats not the case. although some aspects of the original streams library are 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-oriented i/o, whereas the reader and writer classes provide unicode-compliant, character-based i/o. in addition:1. java 1.1 added new classes into the inputstream and outputstream hierarchy, so its obvious those hierarchies werent being replaced. 2. there are times when you must use classes from the byte hierarchy 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 an outputstream to a writer. 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 doesnt handle the 16-bit unicode characters well. since unicode is used for internationalization (and javas native char is 16-bit unicode), the reader and writer hierarchies were added to support unicode in all i/o operations. in addition, the new libraries are designed for faster operations than the old.standard i/othe term standard i/o refers to the unix concept of a single stream of information that is used by a program (this idea is reproduced in some form in windows and many other operating systems). all of the programs input can come from standard input, all of its output can go to standard output, and all of 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 programs standard output can become the standard input for another program. this is a powerful tool.reading from standard inputfollowing the standard i/o model, java has system.in, system.out, and system.err. throughout this book, youve seen how to write to standard output using system.out, which 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, system.in must be wrapped before you can read from it.youll 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.in to a reader using inputstreamreader.redirectingthe java system class allows you to redirect the standard input, output, and error i/o streams using simple static method calls:setin(inputstream) setout(printstream) seterr(printstream)redirecting output is especially useful if you suddenly start creating a large amount of output on your screen, and its 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 repeatedly.new i/othe java new i/o library, introduced in jdk 1.4 in the java.nio.* packages, has one goal: speed. in fact, the old i/o packages have been reimplemented using nio in order to take advantage of this speed increase, so you will benefit even if you dont explicitly write code with nio. the speed increase occurs both in file i/o, which is explored here, and in network i/o, which is covered in thinking in enterprise java. the sp