摘要

  • STRU P 把不连续文件表示为带逻辑索引的独立页面；Page Index 指向文件中的位置，而不是页面通过网络的先后序号。
  • 页表里的空位置直接不发送，真实存在但内容为零的页面仍是数据。RFC 959 特别强调，空洞不等于零页。
  • 这一机制主要来自 TOPS-20 与 NLS 的需要。RFC 1123 后来不建议普遍实现，却要求真正需要传输随机访问或空洞文件时使用标准页格式，不能另造私有 FTP 方言。

没有到达的数据仍然表达了位置

普通数据流中间少了一段，人们首先想到传输丢失。RFC 959 的 page structure 却给出了另一种可能：源文件本来就在那个逻辑位置没有页面。

每个已发送页面都带有 Page Index。规范明确说，它是该页面在文件里的逻辑页号，不是传输序号。因此，连接上紧邻的两个页面可以在文件地图上相隔一格甚至多格。

TOPS-20 附录把边界写得非常直接：页表中的空页，也就是空洞，根本不发送；空洞不等于一页零。前者说明那个位置没有页面，后者说明页面存在，只是其中的值恰好为零。

在某些系统上，两者读取时可能出现相似结果。但分配状态、存储成本、元数据和后续写入行为都可能不同。把空洞填成零并非中立恢复，而是新建了源地图中没有的内容。

FTP 为什么不只谈字节

FTP 把三个参数分开。TYPE 规定逻辑表示，STRU 规定文件内部组织，MODE 规定数据连接上的传输框架。它们会互相影响，却不是同一个选择。

STRU F 是默认文件结构，把文件看作连续数据字节。STRU R 把文件看作顺序记录。STRU P 则把它看作可独立定位的索引页面。

这种区分来自主机存储差异。RFC 959 用 IBM 大型机上的定长记录和 TOPS-20 上常见的字符流作对照。同一份源代码落到不同系统，本地自然形态可能完全不同。若协议只搬动字节而不说明结构，接收端只能猜测哪些边界属于文件，哪些是本地转换。

转换并未被禁止，但必须尽量可逆。面向连续文件的主机收到记录结构时，可以生成本地有用的形式；以后以记录结构取回时，又要能反向还原。RFC 1123 延续了这项要求：在不牺牲目标主机可用性的前提下，记录与文件结构的转换应尽可能可逆。

所以，一次传输的证据不仅是线上负载，还包括当时生效的 TYPE、STRU 与 MODE。

页头给零长度加上语境

STRU P 中每页都有页头，至少包含 Header Length、Page Index、Data Length 与 Page Type 四个逻辑字段。每个字段的位宽由 TYPE 给出，不能擅自套用接收机的字长。

Page Type 使“数据长度为零”不再只有一种解释。Last Page 用最小页头和零数据明确结束分页传输。Simple Page 是普通数据页。Descriptor Page 携带适用于整个文件的描述。Access Controlled Page 还会加入与该页相关的控制字段。

因此，未出现的索引位置可以是空洞；出现了但没有数据的终止页可以是明确结束；描述页可以影响整个文件。单独看到一个零或一段空白，不足以判断语义。

索引与到达顺序的分离同样关键。若实现按照网络到达先后排列页面，而不是依照 Page Index 放入地图，即使一个字节都没丢，最后也会得到另一份文件。

TOPS-20 与 NLS 留下的具体需求

RFC 765 与 RFC 959 都说明，页结构的主要动力是 TOPS-20 系统之间高效传输文件，尤其是 NLS 使用的文件。

一个 TOPS-20 磁盘文件包含路径名、页表、可能为空的页面集合以及属性。页表项可以是 EMPTY，也可以指向实际页面；非空项还可能带有只属于该页的访问位。文件属性包括创建、读写时间、写入者字节大小、文件结束指针、计数器和备份信息。

页表不要求连续。已占用页面之间可以夹着空项。文件结束指针也只是一个数，不保证指向最后一份数据。NLS 文件确实会使用空洞和不位于最后数据处的结束指针。

规范给出的示例参数是 TYPE L 36, STRU P, MODE S。36 位逻辑字节对应 TOPS-20 的字。Page Index 是页图位置；Descriptor Page 携带全文件属性；数据页还能附带页级访问控制。

这不是要求所有主机复制 TOPS-20 的存储系统，而是让理解这一结构的两端有机会保持它，不必藏进私有扩展。

三种“线上少传一些”

附录还允许缩短一个实际存在的页面：若末尾是零，可以减少 Data Length，不必传完通常的 512 个字。这就产生三种容易混淆的情况。

空洞是某个页图位置没有页面。零页是页面存在、内容为零。缩短页面则是页面存在，并按约定省略了尾部零值。三者都会减少线上可见的非零内容，表达的文件地图却不同。

只对所有页面负载拼接后计算哈希，可能无法证明结构被忠实重建。审计还要保存索引、类型、页头和数据长度、描述字段、控制字段、终止页以及转换规则。

证据边界也必须保留。RFC 没有保证所有目标文件系统都以同样方式实现空洞，也没有说空洞在每个平台都读作零，更没有保证页级访问信息一定能在异构系统上执行。FTP 定义的是可传递的区别，不是统一存储实现。

不建议普及，不等于允许私有化

1989 年的 RFC 1123 对 page structure 作出很有分寸的判断：一般情况下不建议实现。它过于专门，不应成为所有 FTP 主机共同负担。

但真正需要通过 FTP 处理随机访问或空洞文件的主机，必须使用已经定义的页结构格式，不能自己发明一个私有 FTP 格式。实现者可以不支持；一旦支持，就不能让同一问题失去共同语义。

文件结构是普遍要求。记录结构只对本地文件系统支持记录的主机强制，其他主机也可以接受 STRU R 并按字节流原样存放。页结构依旧可选。STRU 命令属于必备词汇，并不表示每台服务器都支持 F、R、P 的所有组合。

登记名称与实际能力

RFC 5797 后来把 STRU 列入 FTP 基础强制命令。IANA FTP 命令与扩展登记表 保留了 File Structure、参数设置类和 RFC 959 引用。

登记表协调命令名称与角色，却不证明某台服务器接受 P，某个客户端能还原 TOPS-20 页图，页级控制会保留，或这一功能今天仍在部署。

登记表里有一行，不等于服务器里有一种能力。线上没出现一个页面，也不等于文件里出现了一页零。

不要自动填满沉默

今天的数据模型仍常把缺失、零值、未知、已遮蔽、不适用塞进同一个空字段。文件可以顺利解析，来源的结构含义却已经消失。

STRU P 留下的设计纪律是：明确表示缺失，把逻辑位置与到达顺序分开，携带重建所需的元数据，并说明转换是否能往返。

缺失页面本身就是信息。填上它不是修复，而是另造一份文件。

来源