摘要

  • 2015 年的 RFC 7578 禁止合并同名部分，也禁止中间环节重排结果。请求完整抵达，不代表应用仍能看见所有提交值。
  • Larry Masinter 参与的标准演变，把格式保真、业务解释和使用权限分成了不同责任；客户端提供的文件名并不具有本地存储决定权。

系统返回“成功”，并不能回答它究竟留下了什么。假设一个申请表允许在同一上传字段中提交两份证明，两个文件各占一个部分，字段名相同。一层便利接口把提交转换为每个名称只对应一个值的字典，最后只留下第二份文件。网络没有必要发生丢包，申请记录却已不完整。这个例子只是机制说明，不是已发现的事故，也不是对某个库的测试结论。它提供了理解 Larry Masinter 相关标准工作的入口：接收字节，与保存足以解释这些字节的信息，是两回事。

从能上传，到能共同理解

1995 年 11 月，E. Nebel 与 L. Masinter 合作发表 RFC 1867。当时，普通 HTML 表单缺少统一请求用户提交本地文件的办法，服务方可能需要自制应用。提案把文件选择扩展、兼容 MIME 的提交表示和面向旧浏览器的迁移方案放在一起。它的类别是 Experimental，明确不是互联网标准。把这一阶段直接描述成全网已经采用的成熟规范，会混淆提案与部署。

1998 年 8 月，署名 L. Masinter 的 RFC 2388 进入标准轨道。2015 年 7 月，RFC 7578 将其取代。后一份文件仍署同一作者，但状态说明明确记录了公开审阅和 IETF 社群共识。作者持续承担规范工作，不等于浏览器实践与 MIME 基础都由他一人发明。其旧版个人主页标注了 2014 年的时间背景，可用于了解历史工作及公开照片，不能据此推定今天的雇主或职务。

multipart 的主体是一串由边界分隔的部分。每一部分都通过 form-data 类型的 Content-Disposition 头及 name 参数，标明原来的字段名。文本与文件内容因此可以一起传输，同时保留各自边界。2015 年规范还刻意把适用范围扩展到 HTML、HTTP 之外，乃至没有用户在屏幕上填写表单的应用。熟悉的上传按钮只是它的一种入口，而不是格式的全部意义。

重名不是必然的错误

两代规范之间最有解释力的变化，藏在关于顺序和重复名称的小节。RFC 2388 第 5.5 节没有定义表单字段顺序与返回值顺序的关系，也没有定义多个字段同名时如何处理。RFC 7578 第 5.2 节作出更明确的安排：表单已有明确顺序时，处理方应当按序返回；中间环节不得重排结果；同名部分不得合并。这里的第一项是 SHOULD 建议，不是要求所有表单都必须拥有天然顺序；后两项则保护提交中已经存在的区别。

重复还可能是正确表示本身。第 4.3 节要求，一个字段中的多个文件分别占据一个部分，并使用相同的 name。早先建议的嵌套 multipart/mixed 方式被弃用，新的发送规则贴近已经广泛部署的做法；规范同时建议，面向广泛用途的接收方也支持旧方式。这并不等于所有接收方必须无条件兼容一切旧输入，而是承认修改规范不能让历史客户端瞬间消失。

开篇例子的关键不在“字典一定不能用”，而在转换发生的时点。应用明确检查收到多少项、决定只接受哪一项之后，单值表示可以是有意选择。若便利层先抹掉多值，业务层便没有机会判断重复是否合理。保留顺序或每个名称的多个值，能够保住这项证据，却不会自动授权这些值产生多个业务操作。格式忠实与业务许可不能相互代替。

字段名、文件名与权限

name 表明一个部分属于哪个字段；filename 是另一类元数据。RFC 7578 建议文件内容携带文件名，但允许在名称不可得、没有意义或涉及隐私时省略。接收方不能盲目照用客户端名称，也不能把其中的目录路径当成本地存储位置的决定依据。设备直接产生的数据流，不必编造一个桌面文件名才能被解释。

字符编码又形成一条兼容边界。规范建议使用 ASCII 字段名，以降低互操作困难；非 ASCII 名称不可避免时，则建议统一使用 UTF-8。它记录了默认字符集的惯例，也提醒解析方面对不同旧编码做法。filename* 参数在这一格式中被禁止，不能把其他头字段语境里的规则不加辨别地移植进来。规范是在约束实际互通问题，不是在保证一个解码猜测适用于所有历史输入。

最后，multipart 主体本身没有提供把数据与原始表单关联起来的机制。应用可以借处理目的地或自带数据建立上下文，但仅有格式并不能认证上下文。它也不提供保密性或完整性。1995 年提案已经警告，不应发送用户没有明确要求发送的本地文件；2015 年文本进一步讨论无意泄露、覆盖文件及可执行内容。解析成功，只能说明结构可以被读出，不能证明文件应当交给谁、保存在哪里或被执行。

证据边界

本文依据上述三份原始 RFC 与有时间背景的个人主页，没有调查今天各库的部署比例，没有测算损失率，也没有进行攻击测试。业务后果是从规范区别推导的编辑分析。公开头像仅用于生成保留本人身份特征的 AI 编辑肖像；画面中的工作环境为虚构，不是已证实的办公地点。