chapter10.htm

Thinking In Java的中文版。Java学习的经典教程。

<br>
4. 行的编号与文件输出<br>
这个例子展示了如何LineNumberInputStream来跟踪输入行的编号。在这里，不可简单地将所有构建器都组合起来，因为必须保持LineNumberInputStream的一个句柄（注意这并非一种继承环境，所以不能简单地将in4造型到一个LineNumberInputStream）。因此，li容纳了指向LineNumberInputStream的句柄，然后在它的基础上创建一个DataInputStream，以便读入数据。<br>
这个例子也展示了如何将格式化数据写入一个文件。首先创建了一个FileOutputStream，用它同一个文件连接。考虑到效率方面的原因，它生成了一个BufferedOutputStream。这几乎肯定是我们一般的做法，但却必须明确地这样做。随后为了进行格式化，它转换成一个PrintStream。用这种方式创建的数据文件可作为一个原始的文本文件读取。<br>
标志DataInputStream何时结束的一个方法是readLine()。一旦没有更多的字串可以读取，它就会返回null。每个行都会伴随自己的行号打印到文件里。该行号可通过li查询。<br>
可看到用于out1的、一个明确指定的close()。若程序准备掉转头来，并再次读取相同的文件，这种做法就显得相当有用。然而，该程序直到结束也没有检查文件IODemo.txt。正如以前指出的那样，如果不为自己的所有输出文件调用close()，就可能发现缓冲区不会得到刷新，造成它们不完整。。<br>
<br>
10.5.2 输出流<br>
两类主要的输出流是按它们写入数据的方式划分的：一种按人的习惯写入，另一种为了以后由一个DataInputStream而写入。RandomAccessFile是独立的，尽管它的数据格式兼容于DataInputStream和DataOutputStream。<br>
<br>
5. 保存与恢复数据<br>
PrintStream能格式化数据，使其能按我们的习惯阅读。但为了输出数据，以便由另一个数据流恢复，则需用一个DataOutputStream写入数据，并用一个DataInputStream恢复（获取）数据。当然，这些数据流可以是任何东西，但这里采用的是一个文件，并进行了缓冲处理，以加快读写速度。<br>
注意字串是用writeBytes()写入的，而非writeChars()。若使用后者，写入的就是16位Unicode字符。由于DataInputStream中没有补充的“readChars”方法，所以不得不用readChar()每次取出一个字符。所以对ASCII来说，更方便的做法是将字符作为字节写入，在后面跟随一个新行；然后再用readLine()将字符当作普通的ASCII行读回。<br>
writeDouble()将double数字保存到数据流中，并用补充的readDouble()恢复它。但为了保证任何读方法能够正常工作，必须知道数据项在流中的准确位置，因为既有可能将保存的double数据作为一个简单的字节序列读入，也有可能作为char或其他格式读入。所以必须要么为文件中的数据采用固定的格式，要么将额外的信息保存到文件中，以便正确判断数据的存放位置。<br>
<br>
6. 读写随机访问文件<br>
正如早先指出的那样，RandomAccessFile与IO层次结构的剩余部分几乎是完全隔离的，尽管它也实现了DataInput和DataOutput接口。所以不可将其与InputStream及OutputStream子类的任何部分关联起来。尽管也许能将一个ByteArrayInputStream当作一个随机访问元素对待，但只能用RandomAccessFile打开一个文件。必须假定RandomAccessFile已得到了正确的缓冲，因为我们不能自行选择。<br>
可以自行选择的是第二个构建器参数：可决定以“只读”（r）方式或“读写”（rw）方式打开一个RandomAccessFile文件。<br>
使用RandomAccessFile的时候，类似于组合使用DataInputStream和DataOutputStream（因为它实现了等同的接口）。除此以外，还可看到程序中使用了seek()，以便在文件中到处移动，对某个值作出修改。<br>
<br>
10.5.3 快捷文件处理<br>
由于以前采用的一些典型形式都涉及到文件处理，所以大家也许会怀疑为什么要进行那么多的代码输入——这正是装饰器方案一个缺点。本部分将向大家展示如何创建和使用典型文件读取和写入配置的快捷版本。这些快捷版本均置入packagecom.bruceeckel.tools中（自第5章开始创建）。为了将每个类都添加到库内，只需将其置入适当的目录，并添加对应的package语句即可。<br>
<br>
7. 快速文件输入<br>
若想创建一个对象，用它从一个缓冲的DataInputStream中读取一个文件，可将这个过程封装到一个名为InFile的类内。如下所示：<br>
<br>
463-464页程序<br>
<br>
无论构建器的String版本还是File版本都包括在内，用于共同创建一个FileInputStream。<br>
就象这个例子展示的那样，现在可以有效减少创建文件时由于重复强调造成的问题。<br>
<br>
8. 快速输出格式化文件<br>
亦可用同类型的方法创建一个PrintStream，令其写入一个缓冲文件。下面是对com.bruceeckel.tools的扩展：<br>
<br>
464-465页程序<br>
<br>
注意构建器不可能捕获一个由基础类构建器“掷”出的违例。<br>
<br>
9. 快速输出数据文件<br>
最后，利用类似的快捷方式可创建一个缓冲输出文件，用它保存数据（与由人观看的数据格式相反）：<br>
<br>
465页程序<br>
<br>
非常奇怪的是（也非常不幸），Java库的设计者居然没想到将这些便利措施直接作为他们的一部分标准提供。<br>
<br>
10.5.4 从标准输入中读取数据<br>
以Unix首先倡导的“标准输入”、“标准输出”以及“标准错误输出”概念为基础，Java提供了相应的System.in，System.out以及System.err。贯这一整本书，大家都会接触到如何用System.out进行标准输出，它已预封装成一个PrintStream对象。System.err同样是一个PrintStream，但System.in是一个原始的InputStream，未进行任何封装处理。这意味着尽管能直接使用System.out和System.err，但必须事先封装System.in，否则不能从中读取数据。<br>
典型情况下，我们希望用readLine()每次读取一行输入信息，所以需要将System.in封装到一个DataInputStream中。这是Java 
1.0进行行输入时采取的“老”办法。在本章稍后，大家还会看到Java 
1.1的解决方案。下面是个简单的例子，作用是回应我们键入的每一行内容：<br>
<br>
466页程序<br>
<br>
之所以要使用try块，是由于readLine()可能“掷”出一个IOException。注意同其他大多数流一样，也应对System.in进行缓冲。<br>
由于在每个程序中都要将System.in封装到一个DataInputStream内，所以显得有点不方便。但采用这种设计方案，可以获得最大的灵活性。<br>
<br>
10.5.5 管道数据流<br>
本章已简要介绍了PipedInputStream（管道输入流）和PipedOutputStream（管道输出流）。尽管描述不十分详细，但并不是说它们作用不大。然而，只有在掌握了多线程处理的概念后，才可真正体会它们的价值所在。原因很简单，因为管道化的数据流就是用于线程之间的通信。这方面的问题将在第14章用一个示例说明。<br>
<br>
10.6 StreamTokenizer<br>
尽管StreamTokenizer并不是从InputStream或OutputStream衍生的，但它只随同InputStream工作，所以十分恰当地包括在库的IO部分中。<br>
StreamTokenizer类用于将任何InputStream分割为一系列“记号”（Token）。这些记号实际是一些断续的文本块，中间用我们选择的任何东西分隔。例如，我们的记号可以是单词，中间用空白（空格）以及标点符号分隔。<br>
下面是一个简单的程序，用于计算各个单词在文本文件中重复出现的次数：<br>
<br>
467-469页程序<br>
<br>
最好将结果按排序格式输出，但由于Java 1.0和Java 1.1都没有提供任何排序方法，所以必须由自己动手。这个目标可用一个StrSortVector方便地达成（创建于第8章，属于那一章创建的软件包的一部分。记住本书所有子目录的起始目录都必须位于类路径中，否则程序将不能正确地编译）。<br>
为打开文件，使用了一个FileInputStream。而且为了将文件转换成单词，从FileInputStream中创建了一个StreamTokenizer。在StreamTokenizer中，存在一个默认的分隔符列表，我们可用一系列方法加入更多的分隔符。在这里，我们用ordinaryChar()指出“该字符没有特别重要的意义”，所以解析器不会把它当作自己创建的任何单词的一部分。例如，st.ordinaryChar('.')表示小数点不会成为解析出来的单词的一部分。在与Java配套提供的联机文档中，可以找到更多的相关信息。<br>
在countWords()中，每次从数据流中取出一个记号，而ttype信息的作用是判断对每个记号采取什么操作——因为记号可能代表一个行尾、一个数字、一个字串或者一个字符。<br>
找到一个记号后，会查询Hashtable counts，核实其中是否已经以“键”（Key）的形式包含了一个记号。若答案是肯定的，对应的Counter（计数器）对象就会增值，指出已找到该单词的另一个实例。若答案为否，则新建一个Counter——因为Counter构建器会将它的值初始化为1，正是我们计算单词数量时的要求。<br>
SortedWordCount并不属于Hashtable（散列表）的一种类型，所以它不会继承。它执行的一种特定类型的操作，所以尽管keys()和values()方法都必须重新揭示出来，但仍不表示应使用那个继承，因为大量Hashtable方法在这里都是不适当的。除此以外，对于另一些方法来说（比如getCounter()——用于获得一个特定字串的计数器；又如sortedKeys()——用于产生一个枚举），它们最终都改变了SortedWordCount接口的形式。<br>
在main()内，我们用SortedWordCount打开和计算文件中的单词数量——总共只用了两行代码。随后，我们为一个排好序的键（单词）列表提取出一个枚举。并用它获得每个键以及相关的Count（计数）。注意必须调用cleanup()，否则文件不能正常关闭。<br>
采用了StreamTokenizer的第二个例子将在第17章提供。<br>
<br>
10.6.1 StringTokenizer<br>
尽管并不必要IO库的一部分，但StringTokenizer提供了与StreamTokenizer极相似的功能，所以在这里一并讲述。<br>
StringTokenizer的作用是每次返回字串内的一个记号。这些记号是一些由制表站、空格以及新行分隔的连续字符。因此，字串“Where 
is my cat?”的记号分别是“Where”、“is”、“my”和“cat?”。与StreamTokenizer类似，我们可以指示StringTokenizer按照我们的愿望分割输入。但对于StringTokenizer，却需要向构建器传递另一个参数，即我们想使用的分隔字串。通常，如果想进行更复杂的操作，应使用StreamTokenizer。<br>
可用nextToken()向StringTokenizer对象请求字串内的下一个记号。该方法要么返回一个记号，要么返回一个空字串（表示没有记号剩下）。<br>
作为一个例子，下述程序将执行一个有限的句法分析，查询键短语序列，了解句子暗示的是快乐亦或悲伤的含义。<br>
<br>
471-472页程序<br>
<br>
对于准备分析的每个字串，我们进入一个while循环，并将记号从那个字串中取出。请注意第一个if语句，假如记号既不是“I”，也不是“Are”，就会执行continue（返回循环起点，再一次开始）。这意味着除非发现一个“I”或者“Are”，才会真正得到记号。大家可能想用==代替equals()方法，但那样做会出现不正常的表现，因为==比较的是句柄值，而equals()比较的是内容。<br>
analyze()方法剩余部分的逻辑是搜索“I am sad”（我很忧伤、“I am 
nothappy”（我不快乐）或者“Are you sad?”（你悲伤吗？）这样的句法格式。若没有break语句，这方面的代码甚至可能更加散乱。大家应注意对一个典型的解析器来说，通常都有这些记号的一个表格，并能在读取新记号的时候用一小段代码在表格内移动。<br>
无论如何，只应将StringTokenizer看作StreamTokenizer一种简单而且特殊的简化形式。然而，如果有一个字串需要进行记号处理，而且StringTokenizer的功能实在有限，那么应该做的全部事情就是用StringBufferInputStream将其转换到一个数据流里，再用它创建一个功能更强大的StreamTokenizer。<br>
<br>
10.7 Java 1.1的IO流<br>
到这个时候，大家或许会陷入一种困境之中，怀疑是否存在IO流的另一种设计方案，并可能要求更大的代码量。还有人能提出一种更古怪的设计吗？事实上，Java 
1.1对IO流库进行了一些重大的改进。看到Reader和Writer类时，大多数人的第一个印象（就象我一样）就是它们用来替换原来的InputStream和OutputStream类。但实情并非如此。尽管不建议使用原始数据流库的某些功能（如使用它们，会从编译器收到一条警告消息），但原来的数据流依然得到了保留，以便维持向后兼容，而且：<br>
(1) 在老式层次结构里加入了新类，所以Sun公司明显不会放弃老式数据流。<br>
(2) 
在许多情况下，我们需要与新结构中的类联合使用老结构中的类。为达到这个目的，需要使用一些“桥”类：InputStreamReader将一个InputStream转换成Reader，OutputStreamWriter将一个OutputStream转换成Writer。<br>
所以与原来的IO流库相比，经常都要对新IO流进行层次更多的封装。同样地，这也属于装饰器方案的一个缺点——需要为额外的灵活性付出代价。<br>
之所以在Java 1.1里添加了Reader和Writer层次，最重要的原因便是国际化的需求。老式IO流层次结构只支持8位字节流，不能很好地控制16位Unicode字符。由于Unicode主要面向的是国际化支持（Java内含的char是16位的Unicode），所以添加了Reader和Writer层次，以提供对所有IO操作中的Unicode的支持。除此之外，新库也对速度进行了优化，可比旧库更快地运行。<br>
与本书其他地方一样，我会试着提供对类的一个概述，但假定你会利用联机文档搞定所有的细节，比如方法的详尽列表等。<br>
<br>
10.7.1 数据的发起与接收<br>
Java 1.0的几乎所有IO流类都有对应的Java 1.1类，用于提供内建的Unicode管理。似乎最容易的事情就是“全部使用新类，再也不要用旧的”，但实际情况并没有这么简单。有些时候，由于受到库设计的一些限制，我们不得不使用Java 
1.0的IO流类。特别要指出的是，在旧流库的基础上新加了java.util.zip库，它们依赖旧的流组件。所以最明智的做法是“尝试性”地使用Reader和Writer类。若代码不能通过编译，便知道必须换回老式库。<br>
下面这张表格分旧库与新库分别总结了信息发起与接收之间的对应关系。<br>