摘要

  • 在 STRU R 与 MODE S 下，FTP 用全 1 字节引出两字节控制码：后续值 1 表示 EOR，2 表示 EOF，3 表示两者在同一点发生。
  • 若全 1 字节本来就是数据，发送端必须把它重复一次。接收端只有结合协商状态并跨读取保留解析状态，才能区分字面值与结构控制。
  • BLOCK 与 COMPRESSED 把同样的边界放进描述位；RFC 1123 后来收窄了记录结构的必备范围，却没有允许实现把“保存编码字节”冒充为“重建记录语义”。

第一个字节没有最终解释权

两个连续的全 1 字节并不是两个命令，也不是两个数据字节。按照 RFC 765 和 RFC 959 的 STREAM 规则，它们解码后只留下一个全 1 数据字节。

若第二个值换成 1，这一对表示记录结束；换成 2，表示文件结束；换成 3，则最后一条记录与文件同时结束。第一个字节只是转义哨兵，它的意义必须由相邻字节和此前选择的 STRU R 一起补全。

这条“重复”规则很关键。协议从完整的数据字母表里借走一个值作为控制入口，又用两次出现的办法把字面值归还给文件。因此传输流长度可以大于还原后的数据长度，即使没有压缩、重复写入或丢失。

流只负责顺序，记录由 FTP 声明

FTP 把文件结构与传输模式分开选择。STRU F 把文件看成连续数据字节；STRU R 把它看成顺序记录。MODE S 则规定这些内容以连续传输字节通过数据连接。

可靠有序的流并不会自动知道源文件在哪里分段。记录结构传输中的每个 EOR 都必须明确出现，最后一个也不例外。发送主机先把本地的记录记号转换成 FTP 共同表示，接收主机再转换成适合本地存储的形式。

早期异构系统尤其需要这层分离。一个 IBM 系统的本地计数字段并不是另一台主机可以直接理解的记录边界。共同协议传递的是“边界在这里”，而不是强迫目的端复制源磁盘的内部格式。

四种后继值组成一台小型状态机

解析器看到普通字节时可以直接输出；看到全 1 哨兵时则进入等待状态。下一字节决定四种合法结果：输出一个字面哨兵、产生 EOR、产生 EOF，或同时产生 EOR 与 EOF。

组合控制值避免为了表示“最后一条记录同时结束文件”而虚构一个空记录。双哨兵又保证所有可能的字节值仍能进入文件。二者使内嵌控制保持可逆。

接收程序不能见到哨兵就立刻切分，也不能把双哨兵原样保留为两个数据。它必须分别统计传输字节、还原数据与结构事件；否则单一字节哈希无法解释记录数量为何改变。

读取边界可以切在转义对中间

RFC 9293 描述的是可靠、有序的 TCP 字节流，不是应用记录服务。一次本地读取可能恰好以转义哨兵结束，后继判别值在下一次读取才到达；也可能两者一起出现。

这些切法都不改变 FTP 含义。若实现把 TCP 分段、接收缓冲区或读取调用的边界当成 EOR，就会凭目的端运行方式制造源文件从未声明的结构。

因此测试必须故意把两个字节拆开。连接正常关闭也不能掩盖悬空哨兵：此时接收端仍缺少完成解释所需的第二个字节。

切换到 STRU F，同一字节重新只是数据

在 STRU F + MODE S 中，每个传输字节都是数据，发送端通过关闭数据连接表示 EOF。全 1 字节不再开启特殊语法，也不需要重复。

同一串八位值由此可能得到不同解释。若抓包没有同时保存 STRU 与 MODE 的协商时间线，观察者无法判断双哨兵该还原成一个数据，还是保留为两个普通数据，也无法判断某个字节对是否代表 EOR。

文件结构与记录结构对关闭事件的依赖也不同。前者通常用连接关闭表达 EOF；后者仍要明确给出每个 EOR。只记录“连接正常结束”不足以证明最后一条记录闭合。

其他模式把边界搬到描述字段

BLOCK 模式让数据块带有长度与描述位。其中一位表示块末尾是 EOR，另一位表示 EOF，两位可以同时置位；另有位表示可疑数据或重启标记。

COMPRESSED 模式也用描述形式传递 EOR/EOF，同时拥有重复数据与填充的编码。记录边界这一语义没有改变，线上表示却随 MODE 改变。

所以“有效载荷相同”并非完整证据。不同模式可以用不同字节表达同一记录图；不同协商也可能让相同原始字节具有不同意义。审计需要把控制连接、原始数据流和解码后的边界图合在一起。

行结束不是记录结束的别名

FTP 还明确区分 end-of-line 与 end-of-record。没有记录结构的 ASCII 文本可以用 CRLF 分行，EBCDIC 文本可以用 NL；STRU R 则显式传递 EOR。

许多可见文本恰好一行一记录，这种巧合容易诱发有损简化。一条记录可以跨多行，也可以包含行结束符；非文本记录甚至没有“行”。把 EOR 换成换行符，可能得到可阅读文件，却不再是原结构。

RFC 959 要求 ASCII 与 EBCDIC 文本接受记录结构，并要求文件型与记录型主机之间的转换尽量有用且可逆。判断标准不是屏幕上是否整齐，而是按同一结构取回时能否恢复原来的记录划分。

后来的最低要求承认并非每台主机都原生支持记录

RFC 1123 把强制范围收窄为：只有文件系统支持记录结构的主机才必须实现它。不具备这类存储的主机仍可接受 STRU R，并把字节流按原样记录。

但原样保存编码流与为本地应用重建记录是两种承诺。前者可能保留日后精确恢复所需的材料，后者才提供可直接使用的记录图。接收、解码、扁平化与拒绝必须分别报告。

RFC 5797 与 IANA FTP 命令注册表 保留 STRU、MODE 的基础参数角色。注册表协调词汇，并不证明某台服务器接受 R、正确跨读取保存转义状态或能完成结构往返。

验证的对象应当包括解码器

可靠记录需要保存 TYPE、STRU、MODE、原始流哈希、解码数据哈希、两类长度、全部 EOR/EOF 位置、关闭状态、解析器终态与目的端重建结果。

金丝雀应覆盖双哨兵字面值、三种控制、跨读取拆分、连续边界，以及同一记录图的 STREAM/BLOCK 两种编码。悬空转义、未知后继值、缺失最终 EOR 或切换模式后仍沿用旧状态，都说明解释失败。

这个字节必须出现两次，不是因为网络重复了它，而是因为协议既要控制入口，也不愿牺牲任何合法数据。真正需要守住的是把二者分开的上下文。

来源