【发布时间】：2012-04-14 14:02:37
【问题描述】：
RFC 5321、5322 和 6531 具有用于验证电子邮件地址的复杂规则。他们：
- 允许在电子邮件地址中使用creating comments
- 为符号提供复杂的限制规则：
"() ,:;<>@[\] - 将
postmasterlocalpart 视为不区分大小写，但将所有其他视为区分大小写 - 允许groups of email addresses
由于这些复杂的规则，根据 RFC can't be performed 仅使用正则表达式来测试给定字符串是否是语法上有效的电子邮件地址。
显然，其中许多规则不受主要电子邮件提供商的支持。
从历史上看，为电子邮件地址创建如此复杂的规则的动机是什么？ Wikipedia article on the origins of email 似乎暗示 1980 年代初期的现代标准旨在涵盖所有具有特定标准和语法的遗留电子邮件系统。
但是，标准的实施者、电子邮件提供商和电子邮件最终用户都对一个工作系统有既得利益，当规则不是太神秘时更容易实现，并且可以很容易地投入到通过有限数量的软件中测试，那么为什么我们今天有一个如此复杂的标准，却没有人充分使用它？
从历史上看，XML 在很大程度上已被 JSON 取代，JSON 的成功部分归功于其语法的简单性。
【问题讨论】：
-
因为 RFC 应该涵盖所有边缘情况，而不仅仅是“主要提供者”？
-
我相信这是一个明智而有效的问题，最好用历史后见之明来讨论。上面提到的 RFC 并不是唯一的罪魁祸首；管理转录 IP 地址的有效方法的 RFC 同样令人费解。有趣的是，在现实世界中，这些 RFC 中只有一小部分被积极使用——几乎所有的电子邮件地址看起来都像
name@exxample.com，而所有的 IP 地址都像123.234.231.132。如果这个问题没有过早结束，我们现在可以就这些高度复杂的 RFC 的优缺点和历史背景进行热烈的讨论。 -
虽然这是一个有趣且有效（在更广泛的软件社区意义上）的问题，但它不适用于 StackOverflow。
-
我反对：这是一个讨论编程问题的网站。有时了解一些历史是件好事——为什么事情是这样的。这也是一个非常实际的问题，即：虽然电子邮件地址具有理论上令人难以置信的复杂语法，但在实践中，这通常是通向更简单版本的捷径。这里是讨论的地方。
-
Stackoverflow 在处理这些问题方面特别糟糕。也许在相关的邮件列表中询问。
标签： email email-validation email-address rfc5322