摘要

  • RFC 913 为其 Simple File Transfer Protocol 设计了 ASCII、Binary、Continuous 三种文件类型。文中的 TOPS-20 示例是一页 512 个 36 位字，三种模式分别发出 2560、2048、2304 个八位字节。
  • Binary 每字只取四个八位字节，尾部四位不发；Continuous 把字边界接起来，送走全部比特。网络按规矩送完了，收件端拿到的内容仍由传输前的模式决定。

屏幕跳出“传输完成”，人往往就去打开文件。要是打开后少了什么，网线可能会觉得冤枉：它把程序交给它的字节都送到了。Mark Lottor 在 1984 年 9 月的 RFC 913 里，把这种麻烦写进一个文件传输提案。它也叫 SFTP，使用 TCP 115 端口；这是与后来 SSH 文件传输工具同名缩写的另一套旧方案。Lottor 想要比 TFTP 更能干、比 FTP 更容易实现的服务，用一条 TCP 连接办事。真正会改变文件形状的，是看似普通的 TYPE 命令。

先看 TOPS-20。机器一个字宽 36 位，一页有 512 字，合计 18432 位。ASCII 模式把每个字视作五个七位字符，刚好用掉 35 位，最后一位不在文本表示里。字符装进八位传输单元，高位清零；本地行尾按 NETASCII 规则改成 CRLF。于是，这一页会送出 512 乘五，也就是 2560 个字节。这对交换文本可能正合适：收件机器收到的是可理解的字符和行尾约定。若目标是原样留住磁盘上的每一位，文本模式做的是另一件事。

Binary 听上去像“照原样”。可 RFC 的定义更具体：从每个 36 位字取四组八位，共 32 位；第 32 至 35 位留下。512 字乘四，这页成为 2048 个字节。留下的四位是否装着重要资料，要看原文件怎样布局。文件若本来只把有效内容放在四个八位组中，这样传也许完全合适。重点是“二进制”这个名字本身没有承诺把一个 36 位字全部带走。它保证的是按八位组取材。四位留在站台，列车仍可准点抵达。

Continuous 干脆不把字边界当作每次装箱的终点。第一字取出四个完整字节后，余下四位与第二字的头四位拼成下一字节。后面照此连续打包，整页 18432 位折成 2304 个八位字节，所有比特都登车。若机器本来以八的倍数为字宽，RFC 说 Binary 与 Continuous 的实现应当相同；TOPS-20 的 36 位让差别暴露出来。Continuous 保存了原始比特序列，至于收件机器如何把它还原为可用文件，还需要自己的规则。

这项选择很容易被操作界面藏起来。提案中的命令是四个 ASCII 字母加一个空字节；不指定类型时默认 Binary。服务器可以要求用户、账户、密码，也能列目录、换目录、改名、删除、收发文件。整套会话可能毫无错误地完成，但“默认”的 2048 字节与完整位流的 2304 字节代表不同东西。传输成功证明选定的流送达；它不会替操作人检查最初选择的表示方式是否忠于源文件。

RFC Editor 的记录 今天把这份提案列为 Historic。三个长度是文档中的算例，没有哪位用户的具体文件损坏记录。算例已足够锋利：同一页可以合法地变成 2560、2048 或 2304 字节。争议发生在磁盘格式、TYPE 规则和收件端重建之间。文件可以到站，四个比特却仍在出发地；调度员甚至能给这趟车盖上“成功”的章。