这是一个有效的电子邮件地址吗？

Question

"Françoise Lefèvre"@example.com

我正在阅读RFC 5321，试图真正理解什么构成了有效的电子邮件地址 - 我可能比必要的困难得多 - 但这一直在困扰着我。

               i.e., within a quoted string, any
               ASCII graphic or space is permitted
               without blackslash-quoting except
               double-quote and the backslash itself.

这是否意味着引号内可以使用扩展ASCII字符集？还是仅限于标准ASCII表？

编辑 - 考虑到答案，这里有一个简单的jQuery 验证器，它可以作为插件内置电子邮件验证的补充来检查字符。

jQuery.validator.addMethod("ascii_email", function( value, element ) { 
    // In compliance with RFC 5321, this allows all standard printing ASCII characters in quoted text.
    // Unquoted text must be ASCII-US alphanumeric or one of the following: ! # $ % & ' * + - / = ? ^ _ ` { | } ~   
    // @ and . get a free pass, as this is meant to be used together with the email validator

    var result = this.optional(element) || 
        (
            /^[\u002a\u002b\u003d\u003f\u0040\u0020-\u0027\u002d-u002f\u0030-\u0039\u0041-\u005a\u005e-\u007e]+$/.test(value.replace(/(["])(?:\\\1|.)*?\1/, "")) &&     
            /^[\u0020-\u007e]+$/.test(value.match(/(["])(?:\\\1|.)*?\1/, ""))   
        );
    return result;
}, "Invalid characters");

插件内置的验证似乎相当不错，除了无法捕获无效字符。在列出的测试用例这里中，它只禁止注释、折叠空格和缺少TDL的地址（即：@localhost，@255.255.255.255） - 所有这些我都可以轻松忍受。

- Greg

---

通常，对于这种问题的最佳答案是，如果您可以让几个不同的MTA接受它，则地址有效。 IETF标准并不总是像您希望的那样清晰地指定事物。 - msw

不要验证单个字符，而是验证语法。最好使用正则表达式来验证电子邮件地址。 - BalusC

@BafusC 我确实验证语法。我也想阻止人们将梵文塞入仅限ASCII的字段中。这两者并不互斥。然而，我确实意识到使用正则表达式进行真正的电子邮件验证就像一位红迪特用户所说的那样，“只用电钻建造房屋”。客户端验证只是告诉某人“嘿，这不属于这里” - 我认为这是一个好的、简单的方法。 - Greg

此外，那个链接中的正则表达式太糟糕了。我不知道为什么会被投票支持。接受错误的电子邮件是可以的，但你不能让脚本拒绝大量有效的电子邮件。它甚至无法识别像[e-mail]这样简单的电子邮件地址。如果您不想花费精力正确地进行客户端验证，请不要这样做。相反，发送一封电子邮件并查看是否有效。 - Greg

Answer 1

根据这个MSDN页面，扩展ASCII字符目前无效，但有一个拟议的规范将改变这一点。

http://msdn.microsoft.com/en-us/library/system.net.mail.mailaddress(VS.90).aspx

重点在这里：

Thomas Lee正确指出，在电子邮件地址中，带引号的本地部分是有效的，并且如果不在带引号的字符串中，则某些邮件地址可能无效。但是，其他人提到的字符（如umlaut和agave）不在ASCII字符集中，它们是扩展ASCII。在RFC 2822（以及随后的RFC 5322和3696）中，dtext规范（允许在带引号的本地部分中使用）仅允许大多数ASCII值（RFC 2822第3.4.1节），其中包括33-90和94-126范围内的值。 RFC 5335已经被提出，将允许在addr-spec中使用非ASCII字符，但仍标记为实验性质，并且在MailAddress中不受支持。

- James Black

Answer 2

在这个RFC中，ASCII代表US-ASCII，也就是说，不允许使用值大于127的字符。以下是RFC 5321中的一些引用作为证明：

邮件数据可能包含任何128个ASCII字符代码，[...]

[...]

系统不得以需要在SMTP中使用非ASCII字符（高位设置为1的八位字节）或ASCII“控制字符”（十进制值0-31和127）的方式定义邮箱。这些字符不得在MAIL或RCPT命令或其他需要邮箱名称的命令中使用。

这些引用非常明确地暗示了值大于127的字符被认为是非ASCII的。由于这些字符在MAIL TO或RCPT命令中被明确禁止使用，因此无法将它们用于电子邮件地址。

因此，"Francoise Lefevre"@example.com是一个完全有效的地址（根据RFC），而"Françoise Lefèvre"@example.com则不是。

- Heinzi

Answer 3

从技术上讲，是的，但请继续阅读：

虽然上述对于本地部分的定义相对宽松，
但为了最大限度的互操作性，期望接收邮件的主机应避免定义需要（或使用）引号字符串形式的本地部分或者本地部分区分大小写的邮箱。

...

系统不得以需要在SMTP中使用非ASCII字符的方式定义邮箱。

- fredley

Answer 4

HTML5规范对于有效电子邮件地址的问题有一个有趣的看法：

有效的电子邮件地址是一个与ABNF制作 1 *（atext /“。”）“@” ldh-str 1 *（“。” ldh-str）匹配的字符串，其中atext在RFC 5322第3.2.3节中定义，而ldh-str在RFC 1034第3.5节中定义。

当然，好处在于您可以查看开源浏览器验证 源代码 (查找 IsValidEmailAddress 函数)。当然，它是用C编写的，但翻译成JS也不太难。

- robertc