开发者工具 · URL 编码器和解码器
如何对 mailto 进行编码：与主题、正文换行符和符号的链接
· 为什么它很重要
邮寄至 url 编码 html
带有主题和正文的 mailto: 链接是一个 URL，因此空格、换行符和 & 必须进行百分比编码。这篇文章展示了哪些情况下它们不会损坏，以及如何构建在邮件客户端中正确打开的链接。
主题停在第一个空格的联系链接 — 一个具体的损坏的 mailto：以及邮件客户端收到的内容
联系链接（如 <a href="mailto:test@example.com?subject=Support Inquiry">发送</a>）会中断，因为“支持查询”中的空格会终止邮件客户端中的链接。许多客户仅收到“支持”作为主题。发生这种情况是因为 mailto: 链接遵循 RFC 6068，指定查询参数中的空格和特殊字符需要百分比编码。 & 符号需要 %26 编码以避免成为参数分隔符。
损坏的邮件：链接清楚地说明了问题。像 <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">Contact</a> 这样构建的链接只会生成主题为“Support”的邮件。在不同的邮件客户端中进行的测试显示出不同的容忍度：Apple Mail 部分处理链接，Gmail 仅显示“支持”，Outlook 完全失败。
mailto：是一个 URL 方案 — RFC 6068 简而言之，哪些部分是查询字符串
RFC 6068 定义 mailto：具有特定于组件的编码规则的 URL 方案。与常规 URL 不同，mailto: 每个组件都有特定的规则。地址部分 (test@example.com) 保持未编码状态； @ 和域是结构性的。查询参数（主题、正文、抄送、密件抄送）需要编码。 RFC 6068 参考 RFC 3986 的规则，强制对空格和特殊字符进行百分比编码。当值中的“&”作为数据而不是分隔符出现时，将变为 %26。
了解 mailto：方案结构可防止编码错误。格式为：mailto:地址?参数1=值1&参数2=值2。问号引入查询部分。分隔参数的 & 符号保持未编码；仅值中的 & 符号编码为 %26。如果主题包含“Tom & Jerry”，则编码为 Tom%20%26%20Jerry。主题和正文之间的“&”符号保持未编码状态。这种嵌套编码很容易出错。
将主题和正文编码为 %20、换行符为 %0D%0A、& 为 %26 内部值
对主题和正文进行编码需要仔细处理空格和特殊字符。 mailto: 链接中的空格变为 %20，而不是与 HTML 表单不同的加号。这种关键的差异让熟悉 Web 表单的开发人员感到困惑。换行符编码为 %0D%0A（电子邮件中的 CRLF 行结尾）。 & 符号变为 %26。百分号变为 %25。主题通常包含空格、重音符号和括号。正文包含空格、重音符号、换行符。
mailto: 链接中的常见编码包括：空格为 %20、换行符为 %0D%0A、与号为 %26、百分比为 %25、哈希为 %23、问题为 %3F。非 ASCII 之类的重音符号首先转换为 UTF-8 字节，然后进行百分比编码。 “Über 报告”变为 %C3%9ber%20report。 “你好！ 再见”变为 Hello%21%0D%0AGoodbye。仅编码值，而不编码结构？和 & 字符。
工作示例：构建一个包含主题、两行正文和抄送的链接 — 编码结果及其在邮件客户端中的显示方式
工作示例：与主题“会议议程（九月）”建立链接，正文“让我们讨论： 季度目标”，并抄送“manager@example.com”演示完整的编码。受试者需要：空格作为 %20，括号作为 %28 和 %29。机构需要：“让我们讨论：”基本不变（空间为 %20），换行符为 %0D%0A，“季度目标”基本不变。 cc 字段不需要编码。
生成的 mailto: 为：mailto:contact@example.com?subject=Meeting%20agenda%20%28Sept%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com。在浏览器中的测试揭示了不同的邮件客户端解释。 Gmail 将打开包含正确主题、两行正文和抄送的撰写窗口。 Outlook 显示了类似的结果。 Apple Mail 需要权限。老年客户因缺乏身体支撑而失败。
为什么 + 在这里是错误的 — mailto: 遵循 RFC 3986，而不是表单编码，所以 + 仍然是一个加号
为什么加号是错误的 — mailto: 遵循 RFC 3986，而不是形式编码，因此加号保持字面意思 — 澄清了关键区别。 HTML 表单编码使用加号表示查询字符串中的空格。 RFC 3986 和 RFC 6068 都指定 %20 作为空格。 mailto: with subject="Meeting+Agenda" 创建带有文字加号而不是空格的主题。将表单编码逻辑复制到 mailto: Generation 时会发生此错误。 plus的意思是加号，不是空格。
为什么这很重要：开发人员将表单 GET 提交逻辑复制到 mailto: Generation Break 链接。主题“会议议程”在形式上变为“会议+议程”。在 mailto: 链接中，它创建带有文字加号的“会议+议程”。用户手动修复主题行。测试 mailto: 链接需要单击它们或检查生成的链接，而不是分析表单规则。
常见错误 — 忘记对 href 中的 & 分隔符进行 HTML 转义，并对地址中的 @ 进行百分比编码
常见的 mailto：构建错误包括忘记在 href 属性中转义 HTML 和符号。在 HTML 中，对于有效的 XHTML，属性中的 & 符号应为 &。 href="mailto:address?subject=Test&body=Test" 是无效 HTML；它应该是 href="mailto:address?subject=Test&body=Test"。这表示与 URL 编码不同的编码。 HTML 解析器在浏览器处理 URL 之前将 & 解释为 &。
测试这些错误需要检查 HTML 源代码和浏览器控制台。右键单击并选择“检查元素”以查看实际的 href 值。将 href 值复制粘贴到地址栏中（带有 mailto: 前缀）并检查邮件客户端。某些电子邮件链接在某些浏览器中有效，但在其他浏览器中无效。自动化测试很困难，因为 mailto: 涉及外部客户端，使得手动验证很常见。
这不包括什么 - 邮件客户端支持差异和多个收件人深入
这不包括邮件客户端支持差异和多个收件人。并非所有客户端都同样支持 RFC 6068 参数。 body 参数得到了广泛的支持，但一些老客户端忽略了它。 cc 和 bcc 参数具有可变支持。多个收件人需要以逗号分隔的电子邮件地址，对于复杂地址，将逗号编码为 %2C。不同的区域设置需要正确的 UTF-8 编码才能显示。
邮件客户端的演变影响 mailto: 跨平台的行为。现代网络邮件客户端（Gmail、Outlook.com）比旧的桌面客户端具有更好的 RFC 6068 合规性。移动客户端有时有更严格的解析。有些支持富文本，而另一些则仅支持纯文本。开发人员应该使用受众实际使用的邮件客户端进行测试。尽管有 RFC 6068 规范，但实际实现有所不同。
要点：对每个值进行编码，保留结构 — URL 编码器和解码器的单值模式如何为您提供要粘贴的编码主题和正文
要点：对每个值进行编码，保持结构 - URL 编码器和解码器单值模式生成编码的主题和正文，准备粘贴到链接中。该工具接受未编码的值，例如“会议议程（九月）”，并生成“Meeting%20agenda%20%28Sept%29”。将输出直接复制到 mailto: href 属性中。对于多行正文，粘贴带换行符的纯文本版本，获得 %0D%0A 编码版本。
最佳实践从编码部分组装 mailto: 链接，而不是手动构建。在 JavaScript 或模板中动态构建 HTML 时，请在使用 & 分隔符连接之前分别对每个参数进行编码。对于静态 HTML，URL 编码器和解码器在手写之前可靠地测试编码。代码注释中的文档编码过程。在部署之前，通过使用实际邮件客户端单击链接来测试生成的 mailto: 链接。