Bester regulärer Ausdruck für die Überprüfung von E-Mail-Formaten mit der Validierung von ASP.NET 3.5

Wenn Sie sich fragen, warum diese Frage so wenig Aktivität generiert, liegt es daran, dass so viele andere Probleme behandelt werden müssen, bevor Sie über die Leistung nachdenken. Das Wichtigste dabei ist, ob Sie Regexes verwenden sollten, um E-Mail-Adressen überhaupt zu validieren - und der Konsens ist, dass Sie nicht sollten. Es ist viel schwieriger als die meisten Leute erwarten, und wahrscheinlich auch sinnlos.

Ein weiteres Problem besteht darin, dass Ihre beiden Regexes sehr unterschiedlich sind in Bezug auf die Arten von Strings, mit denen sie übereinstimmen können. Zum Beispiel ist der zweite an beiden Enden verankert, aber der erste ist nicht; Es würde " >>>>[email protected]<<<< " entsprechen, weil es etwas gibt, das wie eine eingebettete E-Mail-Adresse aussieht. Vielleicht zwingt das Framework die Regex dazu, die ganze Zeichenfolge anzupassen, aber wenn das der Fall ist, warum ist die zweite verankert?

Ein weiterer Unterschied ist, dass die erste Regex \w durchgehend verwendet, während die zweite% [0-9a-zA-Z] an vielen Stellen verwendet. In den meisten Regex-Varianten entspricht \w dem Unterstrich zusätzlich zu Buchstaben und Ziffern, in einigen (einschließlich .NET) jedoch auch Buchstaben und Ziffern aus jedem Schriftsystem, das Unicode bekannt ist.

Es gibt viele andere Unterschiede, aber das ist akademisch; keine dieser Regexes ist sehr gut. Siehe hier für eine gute Diskussion des Themas und eine viel bessere Regex.

Wenn ich auf die ursprüngliche Frage zurückkomme, sehe ich kein Performance Problem mit einer dieser Regexes. Abgesehen von dem Nested-Quantifier-Anti-Pattern, das in diesem BCL-Blog-Eintrag zitiert wird, sollten Sie auch auf Situationen achten, in denen zwei oder mehr benachbarte Teile der Regex mit demselben Zeichensatz übereinstimmen können - zum Beispiel

Es gibt nichts dergleichen in den beiden Regexes, die du gepostet hast. Teile, die durch Quantoren kontrolliert werden, werden immer durch andere Teile, die nicht quantifiziert sind, aufgebrochen. Beide Regexes werden einige vermeidbare Backtracking erfahren, aber es gibt viele bessere Gründe als die Leistung, sie zurückzuweisen.

EDIT: Also die zweite Regex ist zu katastrophalen Backtracking unterzogen; Ich hätte es gründlich testen müssen, bevor ich mir den Mund abschoß. Wenn ich mir diesen Regex näher ansehe, sehe ich nicht, warum du im ersten Teil das äußere Sternchen brauchst:

Es genügt, sicherzustellen, dass das erste und das letzte Zeichen alphanumerisch sind und gleichzeitig einige zusätzliche Zeichen dazwischen stehen. Diese Version macht dasselbe, aber es schlägt viel schneller fehl, wenn keine Übereinstimmung möglich ist:

Das würde wahrscheinlich ausreichen, um das Backtracking-Problem zu beseitigen, aber Sie könnten den Teil nach dem "@" auch effizienter machen, indem Sie eine Atomgruppe verwenden:

Mit anderen Worten: Wenn Sie Teilzeichenfolgen, die wie Domänenkomponenten aussehen, mit nachgestellten Punkten versehen, und der nächste Teil nicht wie eine TLD aussieht, sollten Sie sich nicht um das Zurückverfolgen kümmern. Das erste Zeichen, das du aufgeben musst, ist der letzte Punkt, und du weißt, dass [a-zA-Z]{2,9} nicht mit diesem übereinstimmt.

Wir verwenden diese RegEx, die intern gegen 1,5 Millionen Adressen getestet wurde. Es identifiziert besser als 98% von uns, aber es gibt einige Formate, von denen ich weiß, dass es Fehler geben würde.

Wir stellen auch sicher, dass es keine EOL-Zeichen in den Daten gibt, da ein EOL diese RegEx fälschen kann. Unsere Funktion:

Ich bin ein Neuling, aber ich habe Folgendes versucht und es scheint, dass ".xxx" auf zwei Vorkommen oder weniger begrenzt wurde, nach dem Symbol "@".

Hinweis: Ich musste das einzelne '\' durch das doppelte '\' ersetzen, da ich diesen Ausdruck in R verwende.

Diese überprüfen nicht alle zulässigen E-Mail-Adressen gemäß dem RFC-E-Mail-Adressen .

Ich lasse MS die Arbeit für mich erledigen:

Für die serverseitige Validierung fand ich Phil Haacks Lösung als eine der besseren. Sein Versuch war, sich an den RFC zu halten:

Details: Ссылка

Nur um etwas beizutragen, verwende ich diese Regex.

Die Sache ist, dass sich die Spezifikationen mit jeder Domain-Erweiterung ändern, die eingeführt wird.

Sie sitzen hier mod Ihren Regex, Test, Test, Test und weitere Tests. Sie erhalten schließlich, was Sie "denken", ist genau dann ändert sich die Spezifikation ... Sie aktualisieren Ihre Regex, um zu berücksichtigen, was die neuen Anforderungen sind.

Dann gibt jemand [email protected] ein und Sie haben die ganze Arbeit für was getan? Es geht durch deine Phantasie Regex .. bummer!

Sie können auch einfach nach einem einzelnen @ und einem "." und fahre fort. Ich versichere Ihnen, Sie werden keine E-Mails erhalten, wenn sie nicht aufgeben wollen. Sie erhalten Müll oder ihr Hotmail-Konto, das sie nie überprüfen und sich nicht kümmern.

Ich habe in vielen Fällen gesehen, dass dies schief läuft und ein Client aufruft, weil seine eigene E-Mail-Adresse wegen einer schlecht ausgeführten Regex-Prüfung abgelehnt wird. Was wie erwähnt nicht einmal versucht werden sollte.