RFC 6068《mailto URI 方案》中文导读

1. mailto 是什么

当你在网页上点一个“联系我们”链接，浏览器打开邮件客户端并预填好收件人与主题——背后用的就是 mailto: URI。RFC 6068 规范了这个 URI 方案，定义了它如何表达收件人、抄送、主题、正文乃至附件提示。

它废止了 RFC 2368，是互联网邮件与 Web 互通的基础约定之一；其语义与 RFC 5321/5322 的地址与头字段相对应。

2. 语法结构

mailto URI 的整体结构非常紧凑，由“方案名 + 收件人 + 可选的查询头字段”组成：

mailtoURI = "mailto:" [ to ] [ hfields ]
to       = addr-spec *("," addr-spec)
hfields  = "?" header *( "&" header )

• to：紧跟在冒号后、问号前，是一个或多个用逗号分隔的邮箱地址（addr-spec）；可省略，表示只带头字段。
• hfields：问号之后，是若干“头字段名=值”，彼此用 & 分隔；常见如 subject、cc、body。

示例：mailto:bob@example.com?subject=Hello&body=Hi%20Bob 表示给 bob 发一封主题为 Hello、正文为 “Hi Bob” 的邮件。

3. 编码：UTF-8 百分比编码

mailto URI 中的非 ASCII 字符（包括国际化邮箱地址、中文主题与正文）必须按 UTF-8 编码后再做百分比编码（percent-encoding）：每个字节表示为 %XX。

这与 HTML 表单的 application/x-www-form-urlencoded 不同，必须明确区分。例如中文“你好”先转 UTF-8 字节，再每字节加 %。处理软件在解析时应先百分比解码、再按 UTF-8 解码，得到可读文本。

4. 伪头字段 subject 与 body

hfields 里有两个特殊的“伪头字段”（不是真正的邮件头，只是给邮件客户端预填用的）：

• subject：预填邮件主题；
• body：预填邮件正文（第一个 body 参数整体作为正文，多 body 参数按实现定义处理，规范建议只用一个）。

其余如 cc、in-reply-to 等是真实存在的头字段名，客户端应把它们映射到对应邮件头。注意问号、等号、与号本身在 URI 中有特殊含义，出现在值中时必须百分比编码。

5. 不安全的头字段被禁止

文档明确列出不得由 mailto 设置的“不安全头字段”，因为它们涉及邮件的来源、路由与时间，若可被链接任意设定，会被用于伪造与欺骗：

• from / sender：发件人身份，应由邮件系统据实填写；
• date：邮件时间，由系统生成；
• received：传输路径记录，由 MTA 添加；
• content-*、bcc 等也可能被限制。

合规的邮件客户端应忽略 mailto 中对这些字段的设置，或至少向用户提示。反过来，允许设置 subject、body、cc、in-reply-to 等无害字段，是 mailto 的可用价值所在。

6. 解析与渲染的健壮性

规范对处理方给出若干健壮性要求：遇到无法识别的头字段名时，应当忽略而非报错；遇到重复或不支持的参数时，按保守策略处理；对于 body 中的换行，需谨慎处理以免被注入额外头字段（头字段注入风险）。

对 Web 开发者而言，构造 mailto 时必须对所有动态内容做正确的百分比编码，并避免把用户输入不加转义地拼进 URI——这是 mailto 最常见的现实安全陷阱。

参考：https://www.rfc-editor.org/rfc/rfc6068.txt