是否应该在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>

我无法弄清楚，文档冲突。我们在现实世界中的测试也产生了不同的结果，使结果更加令人困惑。

您能否更具体地说明实际测试的方法和结果？某些电子邮件客户端/服务是否正确处理而其他人则感到窒息？您能更具体一点吗？

@bryson我知道“使用gmail发送” chrome扩展程序在mailto中存在未编码加号的问题：例如，但这也许是一个错误。

只需使用适用于chrome的任何一种。

#1 楼

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

因此，客户可以准确解析编码表示并在适当的情况下对其进行解码。这是Microsoft对此事的正式主张。

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

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

有人在何处有效有任何实际数据吗？

–Wez Furlong
2011年6月25日19:29

我确实对微软确认的工作做了具体说明。

– jcolebrand
2011年6月25日19:50

这是现场。 Gmail无法正确处理它们，但是由于Google忽略了用户错误报告，因此您无能为力。

–马修·雷德（Matthew Read）
2011年6月25日在21:02

如果您在URI中使用encoding +，则@也需要进行编码，因为它也是保留字符。如果仔细阅读RFC，您会发现在不透明的部分，+是合法的。

– Eugene Yokota
2011-6-25 21:30

我可能是错的，但不是保留将用户名与主机分开（例如example@example.com/path）吗？然后它将在地址中占据一席之地，因为它确实将用户名与主机分开。

– Maciej Piechotka
2011年6月26日9:59

#2 楼

您可以编码+，但不必编码。

首先，我们需要同意mailto是RFC 2396指定的通用URI的示例。（这是XHTML和HTML 4现在，让我们找出RFC 2396中的保留字符列表。

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

URI分为绝对和相对：

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

由于指定了方案mailto:，因此这是绝对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

所以限制是，如果要涉及第一个字符，则必须转义/，但是此后可以放入保留字符，包括+和@。 br />
这里是另一个RFC支持这一点。在2010年发布的最新的mailto方案RFC RFC 6068中，它表示：

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

我对该语法并不完全熟悉，但是它列出了与未保留池分开的字符，这表明+是保留字符。它并不表示必须对其进行编码。微软表示要对其进行编码。等等，我拭目以待。

– jcolebrand
2011年6月25日19:56

如果部分不以/开头，则+不再成为保留字符。

– Eugene Yokota
2011年6月25日20:00

我不同意。 “电子邮件地址”的定义非常特殊，首先必须谨慎对待。该标准非常令人困惑。幸运的是，我们在这里意见分歧。

– jcolebrand
2011-6-25在20:21

#3 楼

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

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

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

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

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

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

在RFC 3986中，mailto将被视为无路径根，它允许通过（unreserved / pct-encoded / sub-delims /“：” /“ @”）定义pchar序列。 +是sub-delims的一部分。因此严格的阅读说+不需要百分比编码。

– Eugene Yokota
2011年6月25日在21:44

#4 楼

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

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

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

#5 楼

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

这是我的2美分...

编辑：下面的回答很明确。

是的，没错，电子邮件子寻址存在一些差异-但在这种情况下，电子邮件是由gmail托管的，因此我知道加号是正确的，并且假定电子邮件通过客户端接收，则在服务器接收时将起作用。

–杰夫·阿特伍德
2011年6月25日19:03

问题是应用程序解析URI请求。如果它希望接收URLEncoded数据，则它将解码数据，但这对您（错误编码）或客户端（进行假设）都不公平。协议没有规定预期的编码，客户端则有规定。查看我对@Wez对A所做的进一步编辑

– jcolebrand
2011年6月25日19:08

#6 楼

RFC1738

3.5。 MAILTO

mailto URL方案用于
指定个人或服务的Internet邮件地址
。
除Internet之外，没有其他信息。邮寄地址存在或暗示。

mailto URL的形式为：

    mailto:<rfc822-addr-spec>

其中（
对一个addr-spec的编码，如RFC 822中指定的
。在
mailto URL中，没有保留的
字符。

请注意，百分号（“％”）是RFC 822
地址中常用的
，必须进行编码。

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

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

并且根据tools.ietf.org/html/rfc6068“生成'mailto'URI时，所有空格应编码为％20，'+'字符应编码为％2B”

–杰夫·阿特伍德
2011年6月25日19:29

由于没有保留字符，因此应对其进行编码。嗯，这没有任何意义。

– jcolebrand
2011年6月25日19:34

@jcolebrand'+'是URL方案中的特殊字符，因此当它没有特殊作用时必须进行编码-即。不保留时。

– S.Skov
2011年6月25日19:41

@Jeff确实-我对生活在旧的RFC世界中很不好。然后，tools.ietf.org/html/rfc2119基本上告诉您做自己认为最适合的事情。

– S.Skov
2011-6-25 19:46

似乎……在精神上与我最初阅读说明的方式背道而驰。

– jcolebrand
2011年6月25日19:50

#7 楼

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

混淆的原因是，将空格转换为加号实际上并不是标准URL编码的一部分，它是表单参数编码（即application/x-www-form-urlencoded）

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

RFC 6068所说的是mailto: URL应该使用“原始”标准URL编码（根据RFC 3986）以及出现在URL中的加号应始终视为文字加号，而不应视为已进行形式编码的空格。

如果本地客户端确实将加号转换为残破的空格。

编程黑洞网