AI 摘要：本文批判性地回顾了 HTTP 多个版本发展之后，Web 表单（forms）在处理和数据编码方式上依旧混乱与落后。作者剖析了现有的两种表单数据编码方式（application/x-www-form-urlencoded 和 multipart/form-data）存在哪些规范不统一、实现分歧和技术缺陷，以及标准缺失导致开发体验极差；尽管 HTTP 协议多次进化，表单数据交互方式却数十年未有本质改进。文章最后指出，业界对更优的数据编码格式需求迫切，当前的局面已难以令人满意。

1. HTTP 1.1 及标准库开发的挑战
• HTTP 1.1 并非设计良好，RFCs 更像现状描述参考而非真正规范文档
• 实现 HTTP 协议过程中遇到种种格式和约定的古怪乃至异常细节，增加开发复杂度
• 常见如 chunked transfers 的十六进制长度、状态行中的强制空格等非直观规则

2. 表单数据编码现状与问题
• application/x-www-form-urlencoded
• 历史悠久但缺乏清晰权威的完整规范，依赖 URI 查询参数语法（RFC 3986）
• 编码方式不唯一：对于特殊字符、非 ASCII 字符及数组字段，各实现可能不同
• 对文件与大体量（非 ASCII）数据极为低效（尺寸膨胀、难处理），仅适合简单字段
• 标准文件来源分散且部分已废弃（如 RFC 1866）
• multipart/form-data
• 基于 MIME，规范为 RFC 7578
• 通过分隔符（boundary）串联各部分；分隔符任意但需保证不与正文冲突，增加复杂度
• 无内容长度（Content-Length）头，需流式查找分界符，解析困难导致代码容易出错
• 各字段内容 Content-Type 可以随意宣称，可信度低
• 同样缺乏对数组、对象等复杂数据结构的直接支持，序列化无统一方案
• 不适合前端与后端所有技术栈无缝协作，且导致报文冗余、解析低效

3. 表单标准规范缺失与业界影响
• RFC 文档对主流表单格式覆盖不全，甚至可实现 HTTP 服务器时完全不支持表单却依旧合规
• 主流浏览器始终只支持上面两种，阻碍更现代、结构化的数据格式如 JSON 的广泛采用
• 早年曾有 JSON、XForms 作为新方案提出，但均未流行或长远落地

4. 现实与展望
• 浏览器与后端互操作受限，文件与字段混合上传尤为无解
• 新协议如 tus，仅可用于纯文件上传场景；JSON 提案因多方面原因未标准化
• 表单机制停滞，严重滞后于网络协议和数据交换发展的需求