背景信息

我们使用SonarQube来获得关于代码库的质量度量。SonarQube在规则S6324下标记了我们的Node.js代码库中的十几个错误，这些错误与Google上一个名为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's Email page处理上述正则表达式的变体，如下所示：
您不应该使用此正则表达式的原因是它过于宽泛。您的应用程序可能无法处理此正则表达式允许的所有电子邮件地址。域特定的路由地址可能包含不可打印的ASCII控制字符，如果您的应用程序需要显示地址，这可能会导致问题...
然而，我似乎找不到任何信息来解释 * 为什么 * 一些网站会添加这些不可打印的控制字符，或者他们所说的"特定于域的路由地址"是什么意思。我看了一些Stack Overflow regex questions和Stack Overflow Regex Wiki。控制字符似乎没有得到解决。

问题

有人能解释一下正则表达式中这些控制字符的用途吗？* 可能的话 * 提供一些正则表达式何时有用的例子？
(Note：请避免辩论/讨论什么是最好/最坏的正则表达式来验证电子邮件。似乎没有就这个问题达成一致意见，这个问题已经在Stack Overflow和更广泛的互联网上的许多地方进行了讨论和辩论。这个问题的重点是理解正则表达式中控制字符的用途。

更新

我还联系了SonarQube社区和no one seems to have any answers。

更新

仍然在寻找权威的答案来解释为什么上面的电子邮件正则表达式专门检查电子邮件地址中不可打印的控制字符。
RFC5322第5节中有这样的内容，但它是关于消息体的，而不是地址：
1.安全注意事项
在终端或终端模拟器上显示消息时需要小心。强大的终端可能会对转义序列和US-ASCII控制字符的其他组合起作用，并产生各种后果。它们可以重新Map键盘或允许对终端进行其他修改，这可能导致拒绝服务或甚至损坏数据。它们可以触发（有时可编程）