摘要

  • 成熟FTP把数据连接上的传输单位固定为八位，同时允许TYPE L另行声明文件的逻辑字节大小；两种边界可以彼此错开。
  • 接收端可以按本机字长重排存储，但转换必须可逆并应公开；只有使用相同参数存入和取回，协议才承诺得到相同文件。
  • TYPE I把文件当作连续位串，TYPE L则保留显式逻辑单位。命令成功、位流完整、本地可操作和最终应用含义仍是不同证据。

第九个八位组没有开启第三个字

把两个36位主机字首尾相接，会得到72位。FTP在线路上以八位为一个传输单位，因此72位占九个八位组。若接收程序每读到一个八位组就假定一个新的逻辑对象开始，它会在第一个36位字的中间越过边界，也会把第九个八位组误认成一个独立对象。

RFC 765与后来的RFC 959给出的TYPE L 36例子正是为了阻止这种偷换。逻辑字节连续打包，不理会八位传输单位的边界。命令的第二个参数不是文件长度、机器地址、磁盘块大小或网络包尺寸；它只声明解释这串位时每个逻辑单位有多宽。

这段算术看似属于已经消失的36位机器，实际揭示了协议设计中一个持久问题：共同线路必须选择一种可传输的最小语法，但共同语法不必吞并端点原有的数据单位。互操作的任务是让边界可以被重建，而不是宣布所有内部世界都长得一样。

早期FTP把异构性直接列进类型表

1971年的RFC 114没有从一种狭窄的“文本或二进制”二分开始。它列出多种ASCII形式、EBCDIC、SIXBIT、不同整数表示和机器特定的浮点格式；某些整数描述符可带1至255位的显式大小。

这些类型带有解释性。接收主机若声称接受一种类型，就可以把它转换成适合本机的内部形式。例如，一台36位字机器可能按每字五个七位ASCII字符存放某种文本，也可能对八位或九位字符采用另一种装箱方式。协议表试图告诉接收方“这些位是什么”，而不只是“这些位到了”。

不能把这张1971年的表当作RFC 959的命令语法。它的价值是显示问题原貌：ARPANET连接的主机在字符码、整数表示、浮点格式和物理字长上差异巨大。若只规定一条可靠位管道，文件落盘后仍可能失去结构；若在线路标准里规定每一种机器格式，标准又会被设备目录拖住。

一度连线路上的字节大小也可以改变

1972年的RFC 354已经把表示类型、数据连接字节大小和存储方式分开，但线路单位尚未固定为八位。客户端可以选择数据连接的字节大小；服务器无须接受所有数值，只应接受自己能有效处理的集合，规范建议至少实现八位。

当时的Local Byte表示依赖所选线路字节大小和具体主机。站点需要公开其转换规则，转换还必须可逆：用某个表示和字节大小存入的文件，应能用同一组参数取回相同文件。控制权因此被拆成两部分。请求方选择参数；接收站点决定怎样把这些参数映射到本机存储，但不能把不可逆的私有改写伪装成同一文件。

这种自由有明显成本。每增加一种线路字节大小，连接建立、缓冲、装箱和错误处理都多一个互操作分支。两个端点内部都理解36位，并不自动表示它们的数据连接实现也会接受36位传输单位。

1980年的简化没有消灭逻辑字节

RFC 765作出关键收束：数据连接上的传输字节固定为八位。1985年的RFC 959继续采用这一规则，并明确说FTP里有两个需要区分的“字节大小”：文件的逻辑字节，以及传输数据使用的八位单位。二者也都不等于接收系统实际存储时采用的物理单位。

这是减少协商面，而不是宣布所有文件都由八位对象组成。TYPE L保留了显式逻辑宽度。语法要求一个十进制参数，没有默认值。TYPE L若不说明大小，就没有足够信息恢复边界。

因此协议把复杂度从连接字节搬到了端点装箱。线路只需可靠搬运八位组；发送端把连续逻辑单位压入这条八位序列，接收端依照已知宽度重新切分。36与8的最小共同边界恰好是72位，所以九个八位组可以装下两个36位单位。

这不是把36位数转换成某种统一数值格式。RFC没有凭TYPE L 36规定符号位、整数端序、浮点指数或应用记录。它保存的是边界与位内容。知道一个箱子每格36位，不等于知道格中物品的业务意义。

填充只能出现在末尾

逻辑宽度未必整除八。发送方连续装箱后，最后可能剩下不足一个传输八位组的位数。RFC 765与RFC 959允许在末尾加入必要填充，却没有允许每个逻辑字节后都补齐到八位边界。

位置决定填充能否被识别。末尾填充可以结合总结构与选定参数被剥离；夹在每个单位之间的零则可能与真实数据无从区分。若一个网关为了自己的八位内存方便，擅自在每个36位单位后插入四个零，它已经创造了另一种编码，而不是忠实执行连续打包。

这条规则也限定监测方式。抓包中出现零位不能单独证明填充；应用数据本来就可能含零。调查者需要知道活动TYPE参数、文件或记录终点，以及实际位数。没有这些上下文，观察到的只是传输单位，不是逻辑边界。

本地存储可以不同，但转换必须能倒回来

收到36位逻辑单位的32位字机器不必把磁盘改造成36位。RFC 959举例说，它可以把每个36位单位放进64位双字，以便本机处理。多出的物理空间属于接收方的存储选择，不会沿FTP线路变成文件内容。

这种地方自治受到可逆性约束。实现应公开转换方法，并且在用相同参数取回时恢复相同文件。协议没有承诺用TYPE L 36存入后改用TYPE L 8取回仍然相同，也没有承诺另一个不知道原参数的工具能从磁盘布局猜回边界。

参数因此是文件证据的一部分，而非一次性命令日志。若归档系统只保存落盘字节，却丢掉当初的逻辑宽度和转换规则，日后即使存储介质完好，也可能无法证明哪个零是填充、哪个边界属于原文件。

Image与Local可能等效，却没有相同声明

FTP的Image类型把数据视为连续位串，在线路上同样装入八位传输单位。接收存储若必须对齐到字、块或记录，可以在末端补零，但应能识别并在取回时剥离。Image适合无须FTP解释内部单位的二进制数据。

Local则主动声明逻辑单位。对八位机器而言，TYPE L 8与Image可以等效；两台36位机器之间，TYPE L 36也应与按连续位处理产生同样结果。但“结果可能相同”不等于两个命令表达同一证据。Local告诉接收端每36位是一个可操作单位，Image只要求保持连续位内容。

这种差别在转换发生时最明显。若接收端需要为36位单位选择64位容器，Local参数提供了合法边界。Image没有授权它凭猜测把连续位串切成36位数。应用可以另有格式说明，但那是FTP之外的证据。

最低互操作要求停在八位

RFC 1123要求FTP程序支持TYPE I与TYPE L 8。对内存以m位字组织、且m不是8的倍数的机器，它允许另行支持TYPE L m。措辞没有要求所有服务器接受任意m，也没有把一条成功的TYPE回复变成部署普查。

这项下限颇有分寸。TYPE I给所有实现一个共同二进制路径；TYPE L 8确保Local命令形式至少在最常见的逻辑宽度上可用；非八位机器可以保留本机模式，却必须面对对端是否也支持的现实。

服务器拒绝TYPE L 36时，只证明这一连接没有接受该表示参数。它不证明文件损坏、网络不可靠或磁盘不足。客户端可以选择另一种表示，也可以在FTP之外先把数据编码成双方理解的格式，但不能把拒绝解释成接收端已经承诺转换。

ALLO使用这个单位，却没有定义它

刚发布的FTP ALLO历史研究的是另一条控制面。ALLO可以用逻辑字节表达预期存储量，服务器却可能返回正向回复而不做实际预留。它回答的是资源准备是否必要、声明是否被采用。

TYPE L回答的是数什么。若活动表示把每个逻辑单位定义为36位，那么ALLO中的逻辑字节计数会继承该单位；但一条ALLO命令不会自行创建36位边界，也不会规定接收端如何可逆存放。把两者合并，会把“单位的定义”与“按该单位提出的资源估计”混成一个权限。

同样，传输完成回复只说明FTP操作走到了相应状态，不等于应用已经能解释每个36位值，更不等于数据已按某种现代持久性模型落盘。表示、传输、分配与应用消费各有自己的结果。

登记表保存命令，不保存每台机器的映射

今天的IANA FTP命令与扩展登记表仍记录TYPE为表示类型命令，并指向基础规范。登记使实现者可以找到共同名称和参考文档。

它不列出某台服务器接受哪些Local宽度，不证明站点公开了怎样的磁盘转换，也不统计TYPE L 36是否仍被使用。规范语法、实现能力、会话接受和成功往返是四层证据。把第一层当成第四层，会重演本文一直警告的边界错误。

线路标准化的是搬运，不是所有意义

FTP从庞大的解释类型表，经过可变线路字节，走到固定八位传输单位与可选逻辑宽度，实际上收缩了共同层的职责。中间网络不必理解PDP-10、Multics或32位接收机怎样存储；它只搬运八位组。端点也没有因此失去表达非八位单位的能力。

代价是上下文必须随文件一起被治理。逻辑宽度、表示类型、结构、模式和本地转换规则不能在一个“二进制”标签里消失。共同线路越简单，端点越需要诚实保存那些线路故意没有定义的事实。

来源与证据边界

本文依据RFC 114、RFC 354、RFC 765、RFC 959、RFC 1123与IANA登记表。它们证明历史语义和规范边界，不证明现代部署比例、任意服务器的参数集合、特定磁盘布局或36位数据的应用含义。