E-Mail-Validierung in JavaScript: Wie es unter der Haube funktioniert (Code-Analyse)

Wie man E-Mails in JavaScript validiert: Vom einfachen Regex bis zur vollständigen Analyse unter der Haube

Jeder Entwickler ist mindestens einmal im Leben auf die Frage gestoßen: „How can I validate an email address in JavaScript?“. Diese Frage auf Stack Overflow hat Tausende von Aufrufen und Hunderte von Antworten gesammelt, weil das Thema ein wahres Knäuel von Nuancen ist. Heute geben wir nicht nur fertigen Code, sondern schauen unter die Haube: Wir analysieren, warum eine einfache Prüfung a@b durchlassen oder "test@[IPv6:2001:db8::1]" blockieren kann. Los geht's!

Warum „einfach Regex“ eine schlechte Idee ist

Die beliebteste Lösung im Internet ist es, einen regulären Ausdruck zu kopieren. Aber seien wir ehrlich: E-Mail-Adressen sind Chaos. Die Spezifikationen RFC 5321 und RFC 5322 erlauben die Verwendung von Zeichen wie +, -, ., % und sogar Kommentare in Klammern. Und dann gibt es noch Domains wie museum oder @[192.168.1.1]. Versuchen Sie, das alles in eine einzige Regex-Zeile zu packen – und Sie lassen entweder eine gültige Adresse durch oder blockieren einen echten Benutzer.

Hier ist ein Beispiel, das oft auf Stack Overflow zu finden ist:

const emailRegex = /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/;

Dieser Code funktioniert in 90% der Fälle, aber:

\n
• Er lässt test@localhost durch (gültig für lokale Netzwerke)
\n
• Er blockiert "test@[192.168.1.1]" (laut RFC gültig)
\n
• Er prüft weder die Länge der Domain noch das Vorhandensein von Punkten
\n

Moral der Geschichte: Versuchen Sie nicht, einen perfekten Regex zu schreiben. Verwenden Sie besser eine Kombination aus einfacher Prüfung + serverseitiger Validierung.

Anatomie einer E-Mail-Adresse: Was Sie vor dem Schreiben von Code wissen müssen

Bevor wir einen Validator schreiben, analysieren wir die Struktur einer E-Mail gemäß der Spezifikation:

\n
• Lokaler Teil (vor dem @): Kann Buchstaben, Ziffern, Punkte, Pluszeichen, Bindestriche enthalten, darf aber nicht mit einem Punkt beginnen oder enden. Anführungszeichen für Sonderzeichen sind zulässig.
\n
• Domain (nach dem @): Besteht aus durch Punkte getrennten Labels. Jedes Label hat 1 bis 63 Zeichen. Die Domain kann eine IP-Adresse in eckigen Klammern sein.
\n
• Gesamtlänge: Nicht mehr als 254 Zeichen.
\n

Mit diesem Wissen können wir eine sinnvollere Prüfung schreiben.

Schritt 1: Einfache, aber funktionierende Validierung (für 99% der Fälle)

Beginnen wir mit Code, der in echten Projekten verwendet wird (z. B. in Angular oder React). Er ist nicht perfekt, aber für die meisten Formulare ausreichend:

function isEmailSimple(email) {\n    // Leerzeichen entfernen\n    const trimmed = email.trim();\n    \n    // Prüfung auf leeren String\n    if (!trimmed) return false;\n    \n    // Grundstruktur: etwas @ etwas . etwas\n    const atIndex = trimmed.lastIndexOf('@');\n    if (atIndex < 1 || atIndex === trimmed.length - 1) return false;\n    \n    const localPart = trimmed.slice(0, atIndex);\n    const domain = trimmed.slice(atIndex + 1);\n    \n    // Domain muss mindestens einen Punkt enthalten\n    const dotIndex = domain.lastIndexOf('.');\n    if (dotIndex < 1 || dotIndex === domain.length - 1) return false;\n    \n    // Längenprüfung\n    if (trimmed.length > 254) return false;\n    if (localPart.length > 64) return false;\n    \n    return true;\n}\n\n// Beispiele:\nconsole.log(isEmailSimple('user@example.com')); // true\nconsole.log(isEmailSimple('a@b.c')); // true (formal gültig)\nconsole.log(isEmailSimple('user@localhost')); // false (kein Punkt)\nconsole.log(isEmailSimple('@example.com')); // false\n

Dieser Code ist bereits besser als ein blinder Regex. Er prüft die Struktur, die Länge und das Vorhandensein von @ mit Punkt. Aber er lässt user@[192.168.1.1] durch – für die meisten Webformulare ist das nicht kritisch.

Schritt 2: Erweiterte Validierung unter Berücksichtigung von RFC (fast wie im Browser)

Moderne Browser verwenden eine integrierte Validierung über das Attribut type="e