是否应该在mailto：超链接中进行编码？

在mailto超链接中放置带有地址标签（又称子地址）的电子邮件地址时 …

<a href="mailto:username+foo@example.com">mail us now!</a>

…电子邮件中的加号应使用URL编码吗？

<a href="mailto:username%2Bfoo@example.com">mail us now!</a>

我无法弄清楚，文档相互冲突。我们在现实世界中的测试也产生了不同的结果，从而使结果更加混乱。

加号用于编码URL中的空格，而不是HTML和SMTP（RFC2821）中的空格。但是，由于mailto:address@server.com是URI（具有协议，协议分隔符和协议地址），因此应将其视为URI，并且应进行百分比编码。

因此，由客户端来准确地解析编码的表示并将其解码为适当的程度。这是微软对此事的正式看法。

您应该在mailto上应用URL编码：如果电子邮件地址中的字符保留URI，则嵌入HTML中的URL。这样可以确保您做正确的事。客户端应从接收URI的位置适当地对其进行解码。是的，这this+address@gmail.com是一封非常有效的电子邮件；是this%2Baddress@gmail.com也有效。是的，这两个是不同的，但是是否要区别对待取决于客户...

如前所述，并非所有客户端都能正确呈现此图像。我建议找到用户将使用的最有可能的客户端（gmail？基于浏览器的客户端？Outlook？），并执行该客户端的操作。您说您在GMail上测试过？您是如何测试的？使用“基于浏览器的mailto：客户端（例如，firefox和gmail产品的附加组件），URI很有可能不会被解码（应该如此）。

您可以编码+，但不必这样做。

首先，我们需要同意这mailto是RFC 2396指定的通用URI的示例。（这就是XHTML和HTML 4的用途）。

现在让我们找出RFC 2396中的保留字符列表。

reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
              "$" | ","

URI分为绝对和相对：

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

并且由于mailto:指定了scheme，因此这是绝对URI：

absoluteURI   = scheme ":" ( hier_part | opaque_part )

而且，由于这两种模式的hier_part开头/，mailto是一个不透明的部分。

opaque_part   = uric_no_slash *uric

uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                "&" | "=" | "+" | "$" | ","

uric          = reserved | unreserved | escaped

因此，限制在于，/如果涉及第一个字符，则必须转义，但是之后您可以放入保留字符，包括+和@。

这是另一个支持此功能的RFC。在2010年发布的最新mailto方案RFC RFC 6068中，它表示：

'mailto'同样，创建URI的软件也必须小心以对使用的所有保留字符进行编码。HTML表单是一种创建'mailto'URI 的软件。当前的实现将空格编码为'+'，但这会产生问题，因为'+'无法'+'在'mailto' URI 中将这种空格与实数区分开。产生'mailto'URI时，所有空格都应编码为 %20，'+'字符可以编码为%2B。请注意，'+' 字符通常用作电子邮件地址的一部分，以指示子地址，例如中的<bill+ietf@example.org>。

严格阅读相关RFC表示，应对“ +”进行编码。

http://tools.ietf.org/html/rfc2368上第 2页顶部的第2节说：

“请注意，必须对“至”中的所有URL保留字符进行编码：尤其是括号，逗号和百分号（“％”），它们通常以“邮箱”语法出现。

URI的RFC（http://tools.ietf.org/html/rfc3986#section-2.2）列出了“ +”作为保留字符。

就是说，“正确”并不一定适用于所有浏览器。显然，某些浏览器将始终将正确的事情视为错误，将错误的事情视为正确。

编辑：至于RFC6068及其“ MAY”，我将其视为上下文相关。如果您正在编写用于文本阅读的URL，则“ +”会更有意义，但是，如果您以HTML编写，则对RFC3986的更严格解释将更符合“有效HTML”的想法，因此，使用该值的任何事物都应期望它被编码。

根据新的RFC http://tools.ietf.org/html/rfc6068#section-5

  ... '+' MAY BE encoded as %2B

所以我猜答案不是，但是也许？

我认为无论编码与否，都不会带来真正的改变。问题是邮件客户端。例如，Yahoo Mail仅将连字符用于子地址，而gMail使用加号。

那是我的2美分...

编辑：下面的响应有一个重点。

在RFC1738

3.5。马利托

mailto URL方案用于指定个人或服务的Internet邮件地址。除Internet邮件地址外，没有其他任何其他信息。

mailto URL的形式为：

    mailto:<rfc822-addr-spec>

如RFC 822中所述，addr-spec的编码在哪里。在mailto URL中，没有保留字符。

请注意，百分号（“％”）通常在RFC 822地址中使用，并且必须进行编码。

与许多URL不同，mailto方案并不表示要直接访问的数据对象。它没有指定对象的意义。它的用途与MIME中的message / external-body类型不同。

由于没有保留字符，因此应对其进行编码。

根据答案中提到的RFC 6068，您可以将加号编码为%2B。

造成混淆的原因是，将空格转换为加号实际上并不是标准网址编码的一部分，而是形式参数编码（即application/x-www-form-urlencoded）的一部分

就像PHP rawurlencode()和的区别urlencode()。

因此，RFC 6068所说的是，mailto:URL应该使用“原始”标准URL编码（根据RFC 3986），并且出现在URL中的加号应始终被视为文字加号，而不是被视为具有空格的被表单编码。

如果本地客户端确实将加号转换为空格，则表示它已损坏。