背景信息
我们使用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键盘或允许对终端进行其他修改,这可能导致拒绝服务或甚至损坏数据。它们可以触发(有时可编程)
1条答案
按热度按时间46qrfjad1#
目的
有人能解释一下正则表达式[...]中这些控制字符的用途吗?
这些不可打印的控制字符的目的是创建一个与定义电子邮件地址格式的RFC非常接近的正则表达式。
如果有人想知道-是的-这个email regex中的控制字符是否真的符合RFC规范。我认为验证这一点超出了这个问题的范围,所以我不会详细引用规范,但这里有相关部分的链接:3.2.3(atoms)、3.2.4(带引号的字符串)、3.4(地址规范)、3.4.1(addr-spec规范)、4.1(Misc Obsolete Token)。总之,地址的本地部分和域部分允许包含带引号的字符串,该字符串允许包含某些不可打印的控制字符。
引用自SonarQube rule S6324(着重部分已添加):
ASCII表中代码32下面的条目称为控制字符或非打印字符。由于它们在JavaScript字符串中并不常见**,因此在正则表达式中使用这些不可见的字符***很可能是***一个错误。
遵循规范 * 不是 * 错误。当一个 * 通常 * 有帮助的lint规则在人们的代码中遇到一个它没有帮助的情况时,人们通常只是使用lint工具的case-by-case忽略机制。我认为这解决了你的赏金的第二个条款,它规定:
什么是更好的替代方案,将避免破坏我们的网站,同时也通过SonarQube的质量门?
也就是说,使用所提供的机制之一让SonarQube忽略那些违反规则的行为,您也可以选择完全不检查该规则,但这可能有些过头了。
对于SonarQube,使用
NOSONAR
comments根据具体情况禁用警告。有用性示例
这取决于背景。
如果您的最终目标纯粹是验证 * 任何给定的电子邮件地址 * 是否是RFC定义的有效电子邮件地址,那么严格遵循RFC规范的正则表达式非常有用。
这并不是每个人的最终目标,引自维基百科:
虽然有很多特殊字元在技术上是有效的,但机构、邮件服务、邮件服务器和邮件客户实际上往往并不全部接受。例如,Windows Live Hotmail只允许使用字母数字、点(.)、下划线(_)和连字符(-)来创建电子邮件地址。一般的建议是避免使用一些特殊字元,以避免电子邮件被拒绝。
没有任何东西可以解释 * 为什么 * 大多数应用程序没有完全遵守RFC规范,但是你可以推测,或者你可以尝试去问他们的维护者。例如,像简单性这样的考虑可能-在某人的上下文中-被声明或视为比完全遵守RFC更重要。
如果您的目标是检查给定的电子邮件地址是否是有效的 hotmail 电子邮件地址 *,并 * 拒绝RFC允许但hotmail使用的子集不允许的电子邮件地址,那么完全符合RFC将是 * 不 * 必要的(有用的)。