用于规范化（标准化但不仅仅是清理）电子邮件地址的库
有多种方式可以生成电子邮件地址字符串，这些字符串与直接字符串比较（参见下文）不同，但在逻辑上相同（即发送到两个邮件的邮件都发送到同一个邮箱）。 这通常允许用户提供看似独特的电子邮件地址，即使严格的平等不被允许。
我希望能够找到一个试图进行规范化的库，以便从大量电子邮件地址中找到一些重复项。 这里的目标是尽可能多地找到重复。 鉴于这是多么有用的多用途（在我的情况下，这是简单的滥用检测，因为滥用帐户往往（试图）只是重复使用某些帐户），我想可能有现有的解决方案。
那么，什么样的事情会有所不同？ 我至少知道这样的事情：
理想情况下，这将在Java中，尽管脚本语言也可以工作（命令行工具）
通过搜索“标准化电子邮件地址”，我可以在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。
我不知道其他提供者规则。 事情是，这些规则可能随时发生变化，你将不得不跟踪它们。
我认为就是这样。 如果你想出了一些工作代码，我会非常有兴趣看到它。
干杯!
我一直在使用Apache James Mime4J来解析电子邮件地址。
它正确处理（注释）并将它们从localPart和domainPart中删除
它正确处理“间隔并引用”和+标记的localParts。
它有getLocalPart（）和getDomainPart（）方法。
虽然没有标准化gmail localParts。
上一篇: Library for canonicalizing (normalizing but NOT just cleansing) email addresses