FTP MODE C 如何重建从未发送的字节

摘要

填充描述符以 11 开头，余下六位给出数量。一个描述符字节就是完整指令，其后不附取值。RFC 765 与 RFC 959 对此保持一致。

任意重复数据采用另一种形式：前两位为 10，六位记录数量，随后还必须出现一个数据字节 d。接收端重复这个明示样本。因而，看到数量后没有样本，究竟是合法还是截断，要先看类别位：10 后缺样本是错误，11 后再索取样本才是错误。

原样数据又有第三种格式。最高位为零，余下七位记录正数 n，最多 127；之后正好跟随 n 个数据字节。这三种形式不是同一种压缩的长短版本，而是三份不同的解析承诺。

在 ASCII 表示下，填充是编码 32 的空格；在 EBCDIC 下，是编码 64 的空格；在 Image 或 Local byte 下，则是零字节。同一个 11 + 数量 描述符，在不同 TYPE 下会生成不同输出。

RFC 959 先说表示与传输模式基本独立，随即明确指出例外：采用 Compressed 模式时，填充字节的性质取决于表示类型。这一处依赖让最短编码成为可能，也否定了“MODE C 数据流可以脱离会话自行解码”的想象。

如果监测系统只保存数据连接，它会留下数量，却丢掉选择空格或零的依据。数据流哈希仍然完全正确，但它只能证明捕获了哪些编码字节，不能单独证明这些字节当时代表哪个文件。

任意值都可以用 10 形式重复，因为样本就在流里。11 只适用于当前表示预先指定的填充值。ASCII 文件中的一串零并不会因此成为 ASCII 填充；ASCII 的特殊值是空格。Image 流中的零则可以不附样本地展开。

这是一种语义优化，而非单纯寻找相邻相同字节。发送端利用会话已经建立的约定，省掉了一个原本需要传输的值。

控制信息还有第四条路径：全零转义字节后接一个描述符，使用 BLOCK 模式定义的代码，并作用于随后的一串字节。解码器必须在交付文件之前判断当前项究竟是原样串、显式重复、隐式填充还是控制。

RFC 959 把 COMPRESSED 描述为以少量 CPU 成本换取大型网络传输的带宽，并特别提到 RJE 主机生成的打印文件。固定版式、列和页边距会制造长段空格；为它们设置单字节游程，在当时有直接的操作收益。

文本表示把空格当作“空白材料”，二进制表示把零当作对应值。协议没有宣称发现了一种通用压缩理论，而是在特定工作负载与既有表示语义之间做了紧密耦合。

这种耦合也会制造取证风险。日志若把 TYPE A 错记成 TYPE I，不必改变任何数据字节，就能让日后的重建结果由空格变成零。分析器若假设每个游程数量后都应有样本，则会把完整输入误判为损坏。

TYPE、STRU 与 MODE 通过控制连接设置。证据必须记录服务端实际接受的命令与响应，而不是只记录客户端曾经发送的意图。一次被拒绝的 TYPE 更改，不会建立新的表示状态。

每次获准更改参数，都应划开新的解码时期。数据区间要绑定当时有效的 TYPE/STRU/MODE、传输起止位置与解析器初末状态。TCP 分段和本地读取缓冲区没有这种权力；它们不能决定描述符或样本的边界。

RFC 959 为 MODE 分配 S、B、C，默认值是 Stream。RFC 1123 后来规定的最低实现只要求 Stream，而不是每一种标准模式。因此，MODE C 是标准中的历史设计，但不能据此声称所有当时或当今实现都支持它。

RFC 5797 与 IANA FTP 命令和扩展登记表继续把 MODE 列为基础参数命令。这证明词汇与规范引用仍受协调，不证明服务器接受 C，更不验证它的解析器与存储往返行为。

完整记录至少包括：原始流、长度与哈希；已接受的参数时间线；每个项目的类别、数量和预期后续长度；控制事件；解析器终态；以及规范化重建结果的哈希。即使显式重复和填充偶然生成相同字节，也不能抹掉两者来源的差异。

测试应让同一个填充描述符依次处于 ASCII、EBCDIC、Image 与 Local byte 环境；把它与结果相同的显式重复并排；在本地读取之间切开描述符与样本；并让流在 10 描述符后无样本地结束。判定依据是语法和状态，不是包长。

发送端没有发送那个字节，是因为会话早已替它命名。FTP 通过借用上下文节省带宽；若要让历史字节继续成为证据，就必须把被借用的上下文一并保存。