0

意图

尽管看到很多建议不要这样做，但我正在尝试对电子邮件地址进行一些最小的验证。我这样做的原因是我正在实施的规范要求电子邮件地址采用以下格式：

mailto:<uri-encoded local part>@<domain part>

我想简单地拆分 startmailto:和 final @，并假设“本地部分”在这两者之间。我将验证“本地部分”是否经过 URI 编码。

我不想做更多的事情，规范允许我对大部分内容进行“尽力而为”验证，但对 URI 编码和mailto:前缀非常具体。

问题

从我读过的所有内容来看，分裂对@我来说似乎有风险。

我在网上和 Stack Overflow 的答案上看到了很多相互矛盾的建议，其中大部分都说“阅读 RFC”，其中一些说域部分只能是某些字符，即1-9 a-z A-Z -.，可能是其他几个字符，但仅此而已。例如：

当我阅读有关域名的各种 RFC 时，我看到“任何 CHAR”（dtext）或“ASCII 33 到 90 之间的任何字符”（dtext）都是允许的，这意味着@允许使用符号。这更加复杂，因为括号中允许使用“注释”，( )并且可以包含 ASCII 42 到 91 之间的字符，其中包括@.

RFC1035 似乎支持字母+数字+破折号+句号的要求，但RFC5322 中的“域文字”语法似乎允许更多字符。

我是否误解了 RFC，或者我是否遗漏了一些不允许@在电子邮件地址的域中使用的内容？“域文字”语法是我不必担心的吗？

4

1 回答 1

2

Internet 上最新的电子邮件 RFC 是RFC 5322，它专门针对地址。

addr-spec       =   local-part "@" domain
local-part      =   dot-atom / quoted-string / obs-local-part

点原子是规范中定义的一组高度受限的字符。但是，这quoted-string是您可能遇到麻烦的地方。它不经常使用，但就你遇到它的可能性而言，你很可能会在引号中得到一些本身可能包含@字符的东西。

但是，如果您从最后一个 拆分字符串@，您应该安全地找到local-part和domain，这在规范中就如何验证它进行了很好的定义。

问题来自punycode，几乎任何 Unicode 字符都可以映射到有效的 DNS 名称。如果您作为前端的系统可以理解和解释 punycode，那么您必须处理几乎所有包含有效 unicode 字符的东西。如果您知道您不会使用 punycode，那么您可以使用更受限制的集合，通常是字母、数字和连字符。

引用已故伟大的 Jon Postel 的话：TCP 实现应该遵循稳健性的一般原则：在你所做的事情上保持保守，在你从他人那里接受的事情上保持自由。

关于本地部分的旁注：当然，请记住，互联网上可能有很多系统不需要严格遵守规范，因此由于长期存在，可能允许规范之外的东西工作自由接受/保守传播哲学。

于 2013-06-08T18:09:15.277 回答