CR和LF，回车换行符心得

最近需要按行解析文本，

所以要自动找到文本中的每一个换行符lineSeparator，

原本以为lineSeparator=='/r/n'，

所以就用'/r/n'分析文本，

开始分析的是保存到本地的网页文件，得到的行数没错，没有问题！

后来分析直接从网上读取的Html文件，得到的行数就有错了，问题来了。

用'/r/n'作为分行符得到的行数会少于实际行数(我用编辑器打开直接看的)。

这个问题让我头大如斗，

检查代码--没错，那就是这里面有小出路了，我只好使用Google大法。

以下是Google出来的理论结果，也是问题症结所在：

------------------------------------------------------------------------------

在文本处理中, CR, LF, CR/LF是不同操作系统上使用的换行符.
Dos和windows采用回车+换行CR/LF表示下一行,
而UNIX/Linux采用换行符LF表示下一行，
苹果机(MAC OS系统)则采用回车符CR表示下一行.
CR用符号'/r'表示, 十进制ASCII代码是13, 十六进制代码为0x0D;
LF使用'/n'符号表示, ASCII代码是10, 十六制为0x0A.
所以Windows平台上换行在文本文件中是使用 0d 0a 两个字节表示, 而UNIX和苹果平台上换行则是使用0a或0d一个字节表示.
一般操作系统上的运行库会自动决定文本文件的换行格式. 如一个程序在windows上运行就生成CR/LF换行格式的文本文件，而在Linux上运行就生成LF格式换行的文本文件.
在一个平台上使用另一种换行符的文件文件可能会带来意想不到的问题, 特别是在编辑程序代码时. 有时候代码在编辑器中显示正常, 但在编辑时却会因为换行符问题而出错.
很多文本/代码编辑器带有换行符转换功能, 使用这个功能可以将文本文件中的换行符在不同格式单互换.
在不同平台间使用FTP软件传送文件时, 在ascii文本模式传输模式下, 一些FTP客户端程序会自动对换行格式进行转换. 经过这种传输的文件字节数可能会发生变化. 如果你不想ftp修改原文件, 可以使用bin模式(二进制模式)传输文本. 

-------------------------------------------------------------------

通过以上可知，lineSeparator是不一定为'/r/n'的，

我得想法：

直接从网上读取Html文件保持了文件的原样性，有可能生成这个文件的系统是UNIX/Linux系统，

所以分行使用'/n'的，而保存的本地的网页在保存过程中Windows对文件的换行符做了转换：'/n'-->'/r/n'

这就是同一个文件在网上读取和在本地读取不同的原因吧。

然而还有一种跟变态的情况是同一文件中，既有'/r/n'的分行符，也有'/n'的分行符，

这就情况我就碰到了，原因不知道，但处理方法是有的：

当碰到'/r'就判断下一个是不是'/n'，是的话就作为分行符处理，并跳过下一个字符(跳过'/n')，

这样当碰到'/n'就可以肯定这是Unix/Linux的分行符，也作为分行处理。

CR LF心得：

http://hi.baidu.com/felixzhu84/blog/item/41a036456445188ab2b7dc9d.html