为什么这种电子邮件的正则表达式模式在它甚至不考虑小写字母的情况下如此受欢迎?

sam*_*ers 3 email regular-expression wildcards pattern-matching

我已经看到以下模式在几个地方(甚至在 SOF 上)用作电子邮件 ID 验证的示例。

\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b
Run Code Online (Sandbox Code Playgroud)

以上摘自https://www.regular-expressions.info/tutorial.html,以及引用

 this pattern describes an email address. 
Run Code Online (Sandbox Code Playgroud)

这种模式不考虑小写字母(除非我遗漏了一些东西)。

我对这个模式有什么进一步的了解吗?由于这种模式不能真正用于生产?为什么如此受欢迎?

pin*_*ime 14

我已经看到下面的模式在几个地方使用(甚至在sof上)......为什么它如此受欢迎?

因为人们在他们的答案、博客和代码中复制粘贴第一个谷歌搜索结果,这些结果反过来被搜索引擎选中,这会带来更多的人复制粘贴它,产生一个地狱漩涡,结束互联网任何更好的内容。

除非我错过了什么

按照您的问题的链接,有一段漫无边际的题外话应该“回答”您的所有问题。

  • 题外话中的这句话几乎总结了它:_“我上面的正则表达式的优点是它匹配了今天使用的 99% 的电子邮件地址。”_ - 所以拒绝 1% 拥有有效电子邮件地址的人是可以的从你的网站?见鬼去吧,这只是为糟糕的 RE 找借口。或者真的,因为在工作中使用了错误的工具(RE 经常是这样)。 (3认同)

roa*_*ima 13

它不应该用于生产。例如,"email me"@contoso.com是一个语法上有效的电子邮件地址,但不会被那个朴素的 RE 匹配。

请参阅RFC5322 第 3.4.1 节了解最终语法。

也许令人讨厌的是,没有 BRE 或 ERE 可以匹配该语法定义,但您可以非常接近。但是,PCRE 可以解决问题。请参阅如何使用正则表达式验证电子邮件地址?在 StackOverflow 上。

  • 即使您使用 RFC 正则表达式,您也必须以第二种方式验证电子邮件地址。仅仅是因为该用户在输入时可能有拼写错误。那么为什么要使用比 `.*@.*\..*` 更复杂的正则表达式呢? (4认同)
  • @ThomasWeller 甚至这实际上也太复杂了,因为从技术上讲,主机部分可能是 TLD,例如`thomas@de`。对于 gTLD,这实际上也成为一个可行的选择。(主机部分甚至可以是 IP 地址,但我不介意那些被拒绝。) (3认同)
  • @marcelm newgTLD 不允许这样做。这是传统 TLD 的一种选择。前一段时间 .io 确实提供了这样的电子邮件,但它停止这样做了,我认为任何顶级 tld 都不会这样做。 (2认同)