搜索

2011年5月15日星期日

行尾符的故事


译者:笨乌不飞

美国标准通讯代码(ASCII)并没有规定统一的行尾符。作为替代,他们定义了两个独立的打印头动作:“回车”(CR)和“换行”(LF)(IBM 公司增补的通讯代码——EBCDIC码——就没犯这样的错误,他们定义了一个单独的行尾符:NL)。早期的操作系统设计者们不得不自行约定行尾符:有些用“回车”,有些用“换行”,有些用“回车+换行”,或者反过来。
ARPA网时代(美国军用网络,互联网前身 ~1970-1972),行尾符不一致问题给跨平台网络通讯带来了非常大的麻烦。经讨论(这些讨论被记录在一些早期的RFC中),研究者们做了如下约定:
用于网络传输的ASCII文本必须使用“回车+换行”做为行尾符。
这个决定基于当时的软硬件环境,旨在让纯文本文件通行于所有操作系统。每个系统都被要求对行尾符进行适当的转换,以保证当文本输送到网络时,遵守此规则。
这一行尾符规则被做为早期远程登录协议(Telnet protocol)的核心部分(虽然随后添加了协商机制)。Jon Postel新规则的捍卫者之一,在推广这一标准的过程中起了非常重要的作用。他将“回车+换行”的行尾符规则带入了ARPA网中的FTPSMTP协议,随后这些协议被做为互联网的核心协议原样继承。
现在,很少有人关心行尾符问题了,因为现代系统通常(不总是如此!)会进行自动转换。举例而言,RFC的官方系统会将这些文档储存在Unix系统上,该系统的行尾符是单个“换行”符。当您点击RFC网页的时候,RFCFTP服务器会将单个的“回车”符替换成“回车+换行”的形式输送到互联网,然后您的客户端软件会将接收到的“回车+换行”式行尾符转换为您本地操作系统要求的格式。
今天,许多人使用Windows——MS-DOS发展而来——这是一个较新的系统,直接遵循了“回车+换行”式的行尾符规则。这简化了问题:网络通讯时毋须做行尾符转换。
RFC 2223:《RFC作者需知》,描述了RFC的格式:每行终止于“回车+换行”——与互联网传输格式一致。尽管RFC文件实际保存在ISI或者别的Unix系统上,他们的本地格式是以单个“换行”符为行尾的。
这些系统都能正常工作,魔法似的,但是错误的系统配置或匹配方式依旧可能导致问题。例如:您也许会在某个RFC的行尾遇到多余的Ctrl+M或者“回车”符;或者在Windows系统中,行尾缺少“回车”符会导致格式错乱;而在一些Unix系统上,您可能会不得不使用unix2dos工具来删去怪异的Ctrl+M字符。
注意,当使用二进制FTP模式时,文件会被精确原样复制,因此,源系统的文件格式会被原样传输至互联网。通常即便如此,系统也可以正常运作,因为大多数时候二进制FTP仅用于类似系统之间的传输。RFC官方网络系统采用tarzip压缩文档保存RFC文件(www.rfc-editor.org/download.html
)。这些压缩文档以二进制格式保存,所以包含各自的源系统行尾符:tar文件使用单个“换行”符做为行尾;而zip文档通常来自Windows系统,因此采用MS-DOS风格。
RFC编辑
2004.04.18

没有评论:

发表评论