用于规范化(规范化但不仅仅是清理)电子邮件地址的库

Sta*_*Man 10 java email normalization email-validation

有多种方法可以生成电子邮件地址字符串,这些字符串与直接字符串比较(见下文)不同,但在逻辑上是等效的(即发送到两者的邮件都转到同一个邮箱).这通常允许用户提供看似独特的电子邮件地址,即使不允许严格的平等.

我希望找到一个试图进行规范化的库,以便从大量的电子邮件地址中找到一些重复项.这里的目标是找到尽可能多的重复项.鉴于这对于多种用途有多大用处(在我的情况下,它是简单的滥用检测,因为滥用帐户倾向于(尝试)只重用某些帐户),我认为可能存在现有的解决方案.

那么什么样的东西可以变化?我至少知道这样的事情:

  • 域名部分不区分大小写(根据DNS); 但本地部分可能是也可能不是,这取决于邮件提供商(例如,Gmail认为它不区分大小写)
  • 很多域都有别名(googlemail.com相当于gmail.com)
  • 一些电子邮件提供商允许他们忽略的其他变体(例如,gmail忽略电子邮件地址中的任何点!)

理想情况下,这将是Java,虽然脚本语言也可以工作(命令行工具)

Min*_*ark 19

我可以通过搜索" 规范化电子邮件地址 " 在Google上找到一些代码,但几乎没有足够的彻底.我担心你必须编写自己的工具.如果我要编写这样的工具,我认为我会应用以下几条规则:

首先,该工具将降低域名的大小写(在@之后).它不应该太难,除非您想处理具有国际域名的电子邮件.例如,JoE@caFÉ.fR(注意E上的重音)应首先通过Nameprep算法.这导致JoE@xn--caf-dma.fr.我从未见过有这样一个国际电子邮件地址的人,但我怀疑你可能会在中国或日本找到一些,例如.

RFC 5322声明电子邮件本地部分(在@之前)区分大小写,但几乎所有提供商的事实标准都是忽略大小写(我从未见过人类实际使用的区分大小写的电子邮件地址) ,但我想仍然有一些系统管理员使用他们的Un*x电子邮件帐户,这种情况很重要).我认为该工具应该有一个选项来忽略域名列表的情况(或者相反,只对区域列表区分大小写).所以此时,电子邮件地址JoE@caFÉ.fR现已标准化为joe@xn--caf-dma.fr.

再一次,弹出国际(又称非ASCII)电子邮件地址的问题.如果本地部分是非ASCII,该怎么办?例如甲斐@黒川.日本(免责声明:我不会说日语).RFC 5322禁止这样做,但最近的RFC确实支持这一点(参见这篇维基百科文章).很多语言都没有低级或大写的概念.当他们这样做时,如果你想改成小写形式,确保使用适当的Unicode小写算法,它并不总是微不足道的.例如,在德语中,"Großes"一词的小写字母可能是"grosses"或"großes"(免责声明:我也不会说德语).所以在这一点上,电子邮件地址"Großes@caFÉ.Fr"应该已经标准化为"grosses@xn--caf-dma.fr".

我没有详细阅读RFC 5322,但我认为还有可能在电子邮件地址中发表评论,无论是在本地部分的开头还是结尾,例如(sir)john.lennon@beatles.com或john.lennon(ono)@beatles.com.应该删除这些注释(这将导致john.lennon@beatles.com.剥离注释并不是完全无足轻重的,因为我不知道如何处理嵌套注释,并且用双引号括起来的注释也不应该是根据RFC(除非我弄错了).例如,根据RFC:"john.(ono).lennon"@ beatles.com,不应删除以下电子邮件地址中的注释.

一旦电子邮件正常化,我将应用您建议的"提供商特定"规则.例如,剥离GMail地址中的点并混合等效的域名(例如googlemail.com == gmail.com).我想我会把它与以前的规范化步骤分开.

请注意,Gmail也会忽略加号(+)及其后的所有内容,例如smith+hello_world@gmail.com等同于smith@gmail.com.

我不知道其他提供商规则.问题是,这些规则可能随时发生变化,您必须全部跟踪它们.

我认为就是这样.如果你想出一些工作代码,我真的很有兴趣看到它.

干杯!


Nei*_*gan 5

我一直在使用 Apache James Mime4J 来解析电子邮件地址。

  1. 它正确处理(评论)并将它们从 localPart 和 domainPart 中删除

  2. 它正确处理“间隔和引用”和+标记的localParts。

  3. 它有 getLocalPart() 和 getDomainPart() 方法。

  4. 虽然不规范 gmail localParts。