Es gibt mehrere Möglichkeiten, E-Mail-Adressen zu erzeugen, die sich beim direkten Vergleich von Strings unterscheiden (siehe unten), aber logisch gleich sind (d. h. Nachrichten, die an beide gesendet werden, werden an dieselbe Mailbox gesendet). Dadurch können Benutzer scheinbar eindeutige E-Mail-Adressen angeben, selbst wenn strenge Gleichheit nicht zulässig ist.
Ich hatte gehofft, eine Bibliothek zu finden, die versuchen würde, eine Normalisierung durchzuführen, um einige Duplikate aus großen Mengen von E-Mail-Adressen zu finden. Ziel ist es, so viele Duplikate wie möglich zu finden. Angesichts dessen, wie nützlich das für mehrere Zwecke ist (in meinem Fall ist es eine einfache Missbrauchserkennung, da Missbrauchskonten dazu neigen, bestimmte Konten einfach wiederzuverwenden), denke ich, dass es möglicherweise Lösungen gibt.
Also, was für Dinge können variieren? Ich kenne zumindest Dinge wie:
Idealerweise wäre dies in Java, obwohl Skriptsprachen auch funktionieren würden (Befehlszeilentool)
Ich könnte ein wenig Code auf Google finden, indem ich nach " suche E-Mail-Adresse normalisieren ", aber nicht annähernd gründlich genug. Ich fürchte, du müsstest dein eigenes Werkzeug schreiben. Wenn ich ein solches Tool schreiben würde, wären hier ein paar Regeln, die ich anwenden würde:
Zuerst würde das Tool den Fall des Domain-Namens (nach dem @) absenken. Es sollte nicht zu schwer sein, es sei denn, Sie möchten E-Mails mit internationalen Domain-Namen bearbeiten. Zum Beispiel sollte JoE@caFÉ.fR (beachten Sie den Akzent auf dem E) zuerst den Nameprep -Algorithmus durchlaufen. Dies führt zu [email protected]. Ich habe noch nie jemanden mit einer solchen internationalen E-Mail-Adresse gesehen, aber ich vermute, dass Sie zum Beispiel in China oder Japan etwas finden.
RFC 5322 gibt an, dass der lokale Teil der E-Mail (vor dem @) die Groß- und Kleinschreibung berücksichtigt , aber der de facto -Standard für praktisch alle Anbieter besteht darin, die Groß- / Kleinschreibung zu ignorieren (ich habe noch nie eine von einem Menschen tatsächlich verwendete Groß- und Kleinschreibung gesehen), aber ich vermute, es gibt noch einige Systemadministratoren da draußen, die ihre Un * x E-Mail-Accounts verwenden, wo es egal ist). Ich denke, das Tool sollte eine -Option haben, um case für eine Liste von Domain-Namen zu ignorieren (oder im Gegenteil, nur für eine Liste von Domain-Namen case sensitive). Zu diesem Zeitpunkt ist die E-Mail-Adresse JoE@caFÉ.fR nun auf [email protected] normalisiert.
Auch hier taucht die Frage nach internationalen (auch nicht ASCII) E-Mail-Adressen auf. Was ist, wenn der lokale Teil kein ASCII ist? Zum Beispiel etwas wie 甲 斐 @ 黒 川. 日本 (Disclaimer: Ich spreche kein Japanisch). RFC 5322 verbietet dies, aber neuere RFCs unterstützen dies (siehe dieser Wikipedia-Artikel ). Viele Sprachen haben keine Vorstellung von Klein- oder Großbuchstaben. Wenn Sie dies tun, wenn Sie in die Kleinschreibung wechseln möchten, stellen Sie sicher, dass Sie die entsprechenden Unicode-Kleinbuchstaben verwenden, was nicht immer trivial ist. Zum Beispiel kann im Deutschen der Kleinbuchstabe "groß" entweder "grosses" oder "großes" sein (Disclaimer: ich spreche auch kein Deutsch). An dieser Stelle sollte die E-Mail-Adresse "Großes@caFÉ.Fr" auf "[email protected]" normiert sein.
Ich habe RFC 5322 nicht im Detail gelesen, aber ich denke, es gibt auch eine Möglichkeit, Kommentare in einer E-Mail-Adresse entweder am Anfang oder am Ende des lokalen Teils zu haben. Sir) [email protected] oder John.lennon(ono)@beatles.com. Diese Kommentare sollten entfernt werden (dies würde zu [email protected] führen. Das Entfernen der Kommentare ist nicht ganz trivial, weil ich nicht weiß, was ich mit den verschachtelten Kommentaren tun soll, und auch Kommentare in doppelten Anführungszeichen sollten nicht gemäß RFC entfernt werden (es sei denn, ich irre mich), sollte der Kommentar in der folgenden E-Mail-Adresse nicht entfernt werden, nach dem RFC: "john. (ono) .lennon" @ beatles.com.
Sobald die E-Mail auf diese Weise normalisiert ist, würde ich die "anbieterspezifischen" Regeln anwenden, die Sie vorschlagen. Zum Beispiel das Entfernen der Punkte in GMail-Adressen und das Mischen äquivalenter Domainnamen (googlemail.com == gmail.com zum Beispiel). Ich denke, ich würde das wirklich von den vorherigen Normalisierungsschritten trennen.
Beachten Sie, dass Google Mail auch das Pluszeichen (+) ignoriert und alles danach, z. B. [email protected], entspricht [email protected].
Ich kenne keine anderen Anbieterregeln. Die Sache ist, diese Regeln können sich jederzeit ändern, du müsstest sie alle verfolgen.
Ich denke, das ist es. Wenn Sie einen Arbeitscode entwickeln, wäre ich wirklich interessiert, ihn zu sehen.
Prost!
Ich habe Apache James Mime4J zum Parsen von E-Mail-Adressen verwendet.
Es behandelt (Kommentare) richtig und entfernt sie aus dem localPart und domainPart
Es behandelt "spaced und quoted" und + getaggte localParts korrekt.
Es hat die Methoden getLocalPart () und getDomainPart ().
Normalisiert gmail localParts jedoch nicht.
Tags und Links java email normalization email-validation