文件结束符和负一说开去

     前一段对于文件结束符非常的想研究，到底文件怎么结束？因为以前总听说EOF(end of file)，就是文件结束符。从EOF的字面意思来讲也确实如此。但是，后来查查EOF是-1，也并不是十分特殊，或者在二进制情况下就能避免的了的值。当时就怀疑EOF此值其实没有什么特殊性的，特别在二进制文件中出现任何值都是有可能的。如果固定以EOF来判断，那么在处理二进制文件时就很可能就会误判的。由于工作以来，都是用Java语言来编写程序，当时也研究了EOF值的特性，特别印证了下java JDK中一些I/O函数的说明，都将-1作为结束符来用。
既然如此，-1还是具有一些特殊性的，不然么多的库和系统都选择此值作为EOF。那么-1到底有什么特殊的意义呢？当时，就很饶有兴致地在VC中看了-1的内存表示，-1在内存中被表示为0xFFFFFFFF，原来如此啊？！神奇，也应该如此！！在我们定义很多无效值的时间，或者全零或者全F，这些值都可以被很正常地作为“弃值”和不用的值，而在一些文件中或码流中被自然地规避，可以理所当然地被认为遇到时就是Invalid的值。

 

 

  如果你经常写UDP、TCP通信程序的话，就会知道这几乎是惯用的做法。-1作为文件结束，确实有其极少被使用所致。在ASCII码表中，全零没有标识、全F也没有标识，都有其一致和对照的地方。

     后来，就愈发的有兴趣知道，在二进制文件中，一切皆有可能。在I/O接口读取二进制文件时，是如何判断文件的结束的？如果固定以EOF来判断二进制的文件结束的话，那么将有可能遭遇误判？这样的话，难道就没有方式用I/O方式来读取二进制文件了。总会有方法的，实际不是方法，只是你不知道对应的方法而已，如果以老方法处理肯定会遭遇失败，以EOF的文本读写的方式是来处理二进制文件肯定是有问题的。那这个方法是什么的呢？是什么呢？当然了，对付二进制的方法，应该还是二进制的，一物降一物，总会有办法处理的。在read系统调用中，对应的库函数fread中，没有直接将数据作为返回值返回，则就可以区分返回值和真正数据的区别。那里返回值为0说明读取到文件结束，读取大于零则说明这次读真正地读取了多少个字符，如果小于零则说明出错了。

 

     更深一层，在read接口中，它又是如何知道二进制文件的长度和文件结束呢？一切形式的递归下去，都会最终由终结的，这也是我以前博客中反映的一个思想，没有终结的过程是不稳定的，只有终结或停机的图灵机才能带来人类所希望的价值。那么二进制文件的长度和结束的判断结束在何处呢？操作系统的文件记录表项。如果在一个确定性、无跳变的过程中，要问问它是怎么产生、怎么来的，熟知其历史就可以言之未来，这个过程是可以追踪的。在文件创建和以后的维护过程中，如果操作系统在这一块不出bug，总会知道一个二进制文件的结束的，就停止在那里了。

     疑问了那么多天，在今天有闲暇时，读了《unix环境高级编程》，终于体会出来，啊哈，原来如此的感觉，就是这样的，一切其实都是很自然和简单的。有可能经过迷雾或千峰路转，她变得不清晰，但是，当你明白时，你会觉得一切其实都是很自然和简单的。