邮件地址验证是 Web 系统中最基础却最容易被低估的环节。表面上简单的 user@example.com 背后，RFC 5322 定义了一套复杂的语法规则，涵盖嵌套注释、引号字符串、折叠空白符以及废弃语法的向后兼容。更棘手的是，当业务需要支持国际化域名（IDN）和 UTF-8 本地部分时，开发者必须在严格合规与工程可行性之间做出权衡。
RFC 5322 的核心语法挑战
邮件地址的正式语法由 addr-spec 定义，结构为 local-part "@" domain。其中 local-part 可以是 dot-atom（点分隔的原子串）或 quoted-string（引号包围的字符串），而 domain 可以是 dot-atom 或 domain-literal（方括号包围的 IP 地址）。
真正复杂的是 CFWS（Comments and Folding White Space） 机制。RFC 5322 允许在结构化字段的多个位置插入注释和折叠空白符，其 ABNF 定义如下：
comment = "(" *( [FWS] ccontent ) [FWS] ")"
ccontent = ctext / quoted-pair / comment
CFWS = (1*( [FWS] comment ) [FWS]) / FWS
关键问题在于 ccontent 递归引用了 comment 自身，这意味着注释可以嵌套。例如 (outer (inner) text) 是合法的 CFWS。根据形式语言理论，嵌套结构需要上下文无关文法（CFG）来描述，而正则表达式无法匹配任意深度的嵌套括号。Joshua Cranmer 在邮件客户端开发实践中指出，任何试图用单一正则表达式匹配完整 RFC 5322 addr-spec 的做法都是错误的，因为正则语言无法表达平衡括号问题。
quoted-string 同样引入复杂性。引号字符串内部允许出现 qcontent，包括 qtext（可打印 ASCII 字符，排除 " 和 \）和 quoted-pair（反斜杠转义序列）。同时，FWS 可以出现在引号字符串内部，意味着 "user name"@example.com 中的空格是合法的。更微妙的是，quoted-pair 在语义上 "不可见"——"user\"name"@example.com 应被解释为 username。
国际化扩展：EAI 与 IDNA
当邮件地址包含非 ASCII 字符时，RFC 5322 本身已不足以描述。国际化邮件地址（EAI）框架由 RFC 6530-6532 定义，允许本地部分和域名使用 UTF-8 编码。
对于域名部分，实际工程中的标准做法是 IDNA（Internationalized Domain Names in Applications） 转换。域名中的 Unicode 字符必须先通过 Punycode 算法转换为 ASCII 兼容编码（ACE），例如 münchen.example 转换为 xn--mnchen-3ya.example，然后才能用于 DNS 查询。RFC 5890-5891 定义了 IDNA2008 标准，要求实现者使用 ToASCII 转换进行域名验证。
本地部分的国际化更为复杂。RFC 6532 允许 SMTP 服务器通过 SMTPUTF8 扩展协商传输 UTF-8 本地部分，但许多遗留系统仍只接受 7-bit ASCII。工程上的保守策略是：在验证阶段接受 UTF-8 本地部分，但在发送前检查目标服务器是否声明支持 SMTPUTF8，否则拒绝或要求用户更换地址。
工程实现策略与妥协
1. 解析器架构选择
面对嵌套注释和引号字符串，推荐使用基于状态机的递归下降解析器而非正则表达式。核心思路是：
- 词法分析阶段：将输入字符流转换为 Token 序列（ATOM、DOT、DQUOTE、LPAREN、RPAREN、BACKSLASH 等）
- 语法分析阶段：使用递归函数处理嵌套结构，维护栈深度防止恶意输入导致的栈溢出
- CFWS 剥离：在语义分析前移除所有注释和折叠空白符，简化后续处理
对于资源受限场景，可采用有限妥协策略：限制注释嵌套深度（如最多 5 层）和整体地址长度（如 254 字符），超出则视为无效。这既防止拒绝服务攻击，又覆盖 99.9% 的合法用例。
2. 本地部分验证参数
| 验证级别 | 允许字符 | 引号字符串 | 最大长度 | 适用场景 |
|---|---|---|---|---|
| 严格 RFC 5322 | atext + quoted-string |
支持嵌套转义 | 64 字符 | 邮件客户端、MTA |
| 实用主义 | a-zA-Z0-9!#$%&'*+/=?^_{ |
}~-` | 不支持 | 64 字符 |
| HTML5 兼容 | 同上，加点号限制 | 不支持 | 无硬性限制 | 浏览器原生验证 |
实践中，实用主义级别通常是最佳折中。它覆盖绝大多数真实邮箱（Gmail、Outlook、企业邮箱），同时避免处理 "user@name"@example.com 这类理论上合法但实际罕见的地址带来的复杂性。
3. 域名验证流程
输入域名 → Unicode 规范化 (NFC) → IDNA ToASCII 转换 →
DNS 标签长度检查 (≤63 字符/标签, ≤253 字符/整体) →
TLD 有效性检查 → 输出 ACE 格式域名
关键参数：
- U-Label 长度：转换前最多 64 Unicode 字符（实际限制更严格）
- A-Label 长度：转换后每个 DNS 标签 ≤63 字节，整体 ≤253 字节
- TLD 白名单：可选择限制为 ICANN 已批准 gTLD/ccTLD，防止
user@example.c0m类 typo 通过验证
4. 废弃语法处理
RFC 5322 第 4 节定义了大量废弃语法（obs-* 规则），如 obs-local-part 允许 word *("." word) 形式（即点号前后无需 atext）。规范要求解析器必须接受这些语法以兼容旧邮件，但禁止生成。
工程建议采用宽松解析、严格生成策略：
- 解析阶段：支持 obsolete 语法，但记录警告
- 生成阶段：始终使用当前语法（dot-atom 形式）
- 存储阶段：规范化存储（小写域名、移除 CFWS、展开 quoted-string）
可落地的检查清单
在部署邮件地址验证系统前，验证以下要点：
解析器健壮性
- 限制注释嵌套深度 ≤5，防止栈溢出
- 限制整体输入长度 ≤254 字符
- 处理
quoted-pair转义时正确跳过反斜杠后的字符 - 拒绝包含裸 CR/LF（非 CRLF 序列）的输入
国际化支持
- 域名部分使用 IDNA2008 ToASCII 转换，拒绝转换失败的输入
- 本地部分 UTF-8 验证通过后才标记为 EAI 地址
- 发送前验证目标 MX 是否支持 SMTPUTF8（通过 EHLO 响应检查）
安全考量
- 规范化后比较地址（大小写不敏感域名，保留原始大小写本地部分）
- 拒绝包含控制字符（除 HTAB/SP）的 local-part
- 对解析结果进行 XSS/SQL 注入过滤（独立于地址语法验证）
测试用例覆盖
- 基础：
simple@example.com - 引号：
"user name"@example.com - 注释：
user(comment)@example.com - 嵌套注释：
user(a(b)c)@example.com - IDN：
用户@例子.测试→用户@xn--fsq092h.xn--0zwm56d - 废弃语法：
user. @example.com（应接受但警告）
结论
RFC 5322 邮件地址解析是一个典型的 "简单问题复杂化" 案例。嵌套注释的存在使正则表达式方案从根本上不可行，国际化扩展又引入了字符编码和 DNS 兼容的额外维度。工程实践中的理性选择是：在核心解析器实现严格 RFC 5322 + IDNA2008 支持，但在业务层面提供可配置的限制策略，在安全、兼容性和开发成本之间找到平衡点。
最终，任何语法验证都无法替代发送验证邮件这一黄金标准。语法检查只是第一道防线，真正的地址有效性只能通过实际投递确认。
参考来源
- RFC 5322: Internet Message Format, October 2008
- RFC 6532: Internationalized Email Headers, February 2012
- RFC 5890: Internationalized Domain Names for Applications (IDNA): Definitions and Document Overview, August 2010
- Joshua Cranmer, "Why email is hard, part 4: Email addresses", December 2013
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。