此电子邮件验证正则表达式中不可打印控制字符的用途是什么？

背景资料

我们使用 SonarQube 来获取有关代码库的质量指标。根据规则，SonarQube 在我们的 Node.js 代码库中标记了十多个错误S6324 https://rules.sonarsource.com/javascript/RSPEC-6324，与 Google 排名靠前的网站提倡的电子邮件验证正则表达式相关emailregex.com https://emailregex.com/。该网站声称该正则表达式是 RFC 5322 官方标准。但是，正则表达式中的控制字符被 SonarQube 标记为删除，因为它们是不可打印的字符。这是正则表达式：

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

以下是 SonarQube 抱怨的控制字符的完整列表：‘.\x0e…\x0e…\x0c…\x0c…\x0b…\x0c…\x1f…\x01…\x1f…\x01…\x01…\x09…\x08…\x0b…\x0b…\x0e…\x0b…\x08…\x0c…\x0e…\x09…\x01.’

Regular-Expressions.info 的电子邮件页面 https://www.regular-expressions.info/email.html确实解决了上述正则表达式的变体，如下所示：

您不应该使用此正则表达式的原因是它过于广泛。您的应用程序可能无法处理此正则表达式允许的所有电子邮件地址。域特定的路由地址可以包含不可打印的 ASCII 控制字符，如果您的应用程序需要显示地址，这可能会导致麻烦...

但是，我似乎找不到任何解释的信息why一些站点正在添加这些不可打印的控制字符或“特定于域的路由地址”的含义。我看过一些Stack Overflow 正则表达式问题 https://stackoverflow.com/questions/tagged/regex?sort=frequent和堆栈溢出正则表达式维基 https://stackoverflow.com/tags/regex/info。控制字符似乎没有被解决。

问题

有人可以解释一下正则表达式中这些控制字符的用途吗？possibly提供一些这个正则表达式何时有用的例子？

（注意：请避免关于验证电子邮件的最佳/最差正则表达式是什么的辩论/讨论。在这个问题上似乎没有达成一致，这个问题已经在 Stack Overflow 和更广泛的互联网上的许多地方进行了讨论和辩论。本题重点在于理解正则表达式中控制字符的用途）。

Update

我还联系了 SonarQube 社区，并且似乎没有人有任何答案 https://community.sonarsource.com/t/why-is-a-email-validation-regular-expression-flagged-for-having-control-characters/71081.

Update

仍在寻找权威答案，以解释为什么上面的电子邮件正则表达式专门检查电子邮件地址中的不可打印控制字符。

里面有这个RFC5322 第 5 节 https://www.rfc-editor.org/rfc/rfc5322#section-5，但它是关于消息正文，而不是地址：

5. 安全考虑

在终端或终端上显示消息时需要小心 终端模拟器。强大的终端可以作用于转义序列 以及 US-ASCII 控制字符与各种的其他组合 的后果。他们可以重新映射键盘或允许其他 对终端的修改可能导致拒绝服务或 甚至损坏数据。它们可以触发（有时是可编程的）

目的

有人可以解释一下吗purpose正则表达式中这些控制字符的数量[...]？

这些不可打印控制字符的目的是创建一个严格符合定义电子邮件地址格式的 RFC 的正则表达式。

以防万一有人想知道 - 是的 - 这个电子邮件正则表达式中的控制字符确实do符合 RFC 规范。我认为验证这一点超出了这个问题的范围，所以我不会详细引用规范，但这里是相关部分的链接：3.2.3（原子） https://www.rfc-editor.org/rfc/rfc5322#section-3.2.3, 3.2.4（带引号的字符串） https://www.rfc-editor.org/rfc/rfc5322#section-3.2.4, 3.4（地址规范） https://www.rfc-editor.org/rfc/rfc5322#section-3.4, 3.4.1（addr-spec规范） https://www.rfc-editor.org/rfc/rfc5322#section-3.4.1, 4.1（其他过时代币） https://www.rfc-editor.org/rfc/rfc5322#section-4.1。总之，地址的本地部分和域部分允许包含带引号的字符串，允许包含某些不可打印的控制字符。

引用自SonarQube 规则 S6324 https://rules.sonarsource.com/javascript/RSPEC-6324（强调）：

ASCII 表中代码 32 以下的条目称为控制字符或非打印字符。因为他们不是common在 JavaScript 字符串中，在正则表达式中使用这些不可见字符是最常见的likely一个失误。

遵循规范是not一个失误。当 lint 规则是usually有用的会遇到人们代码中没有帮助的情况，人们通常只使用 lint 工具的个案忽略机制。我认为这解决了赏金的第二条，其中规定：

有什么更好的替代方案可以避免损坏您的侧面并同时通过 SonarQube 质量门？

IE。使用提供的机制之一使 SonarQube 忽略这些违反规则的行为。您也可以选择完全不检查该规则，但这可能有点矫枉过正。

对于 SonarQube，使用NOSONAR评论 https://docs.sonarqube.org/latest/faq/根据具体情况禁用警告。

有用的例子

这取决于具体情况。

如果您的最终目标纯粹是验证是否任何给定的电子邮件地址是 RFC 定义的有效电子邮件地址，那么严格遵循 RFC 规范的正则表达式非常有用。

这不是每个人的最终目标。引用自维基百科 https://en.wikipedia.org/wiki/Email_address#Local-part:

尽管技术上有效的特殊字符范围很广，但实际上组织、邮件服务、邮件服务器和邮件客户端通常并不接受所有这些字符。例如，Windows Live Hotmail 仅允许使用字母数字、点 (.)、下划线 (_) 和连字符 (-) 创建电子邮件地址。常见的建议是避免使用一些特殊字符，以避免电子邮件被拒绝的风险。

没有什么可以解释的why大多数应用程序并不完全遵守规范，但您可以推测，或者您可以尝试询问他们的维护人员。例如，在某些人的背景下，诸如简单性之类的考虑因素可能会被声明或视为比完全遵守 RFC 更重要。

如果您的目标是检查给定的电子邮件地址是否有效hotmail电子邮件地址and拒绝 RFC 允许但 hotmail 使用的子集不允许的电子邮件地址，则完全符合 RFCnot是必要的（有用的）。