摘要

  • RFC 2397 为小型“即时”数据定义了 data:：可选媒体类型、可选 ;base64 标志，以及把声明与数据分开的逗号。
  • 当字节被装进 URL，本来位于远端获取路径上的判断，转移到了本地 URL 使用者、媒体类型处理器和内存边界。

普通地址暗含一段旅程：客户端读出位置，联系外部系统，再取回内容。RFC 2397 把这条链缩短成一个字符串。data:[<mediatype>][;base64],<data> 看上去只是紧凑语法，实际上却把“去哪里找”与“找到什么”压进了同一个对象。

规范称之为“即时寻址”。逗号后面没有一台微型服务器。对于这段内嵌数据本身，使用者不必再访问第二个位置；它要做的是分开声明和载荷，重建字节，然后按照媒体类型解释。地址在这里不再只是指针，也成为运输容器。

容器仍有严格结构。省略媒体类型时，默认值是 text/plain;charset=US-ASCII；也可以省略 text/plain 而单独给出字符集。没有等号的 ;base64 用来选择 base64，因此它与普通媒体类型参数不同。不使用 base64 时，安全 URL 字符可直接表示相应字节，其余字节使用 %xx。这些都是表示规则，不是加密、认证或授权。

data: 也没有相对形式。相对引用需要从上下文继承地址，而即时寻址已经把关键内容完整给出：类型在前，数据在后。这个差别把 RFC 2397 与相对 URL 的历史清楚分开。前者携带自己的货物，后者借用周围文档的地址基础。

规范多次强调“短”。它列出 HTML 2.0 的 SGML 约束：一个属性值字面量最多 1,024 个字符，一个标签内所有属性值合计 2,100 个字符，整个标签也是 2,100 个字符。文中的小型 GIF 已被形容为接近实用边缘。这些数字不是 data: 的普遍上限，而是在提醒：语法能够表达，并不等于外层格式、解析器或内存分配能够承受。

安全部分把控制位置说得更直接。防火墙代理可以阻止从外部取回某类媒体，却很难用同一条路径筛查已经装在 URL 里的内容。因此规范要求应用不要解释被自身配置禁止的媒体类型。真正有执行力的门位于消费端：解析器决定边界，解码器恢复字节，媒体处理器赋予含义，应用决定是否接受。

RFC 2397 还承认，当时并不知道超长 data: 会造成什么影响，某些软件在输入超过已分配缓冲区时可能出现不合理行为。这里的风险不是单一“安全问题”，而是策略与容量共同失效。即使没有为内嵌项发起远程请求，本地软件仍必须回答两个问题：允许处理吗？能够安全处理吗？

这项设计并非纸面发明。规范把最初提议追溯到 1995 年 8 月，并记录了 VRML、HTML 内嵌数据提案、商业产品以及 Java、ActiveX 对象参数中的使用。设计也曾收紧：媒体类型可以省略，base64 标志更紧凑，quoted-printable 则被移除，因为 %xx 已能完成所需表示。

勘误显示边界仍需谨慎阅读。两条已核准修正分别把不可能的 %fg 示例改掉，并把 RFC 2396 中不存在的 urlchar 改为 uric。关于带引号参数和分隔符歧义的意见仍处于 Reported 或 Held for Document Update，不能当作已经生效的新规范。把全文 “URL” 改成 “URI” 的提议则被驳回，因为原文用语符合当时历史语境。

RFC 2397 最值得保留的不是一种方便写法，而是一条控制原则：路径缩短，责任不会消失。它只会向真正能解释并执行数据的组件集中。越少依赖外部检索，本地边界就越不能含糊。

资料来源