JavaScript: Wie validiert man eine E-Mail-Adresse?
Alle wollen die Regex. Interessant wird es, wenn man die verbreitete neben die eigene Prüfung des Browsers stellt und beide auf dieselben Eingaben loslässt: Bei fünf von zehn sind sie sich uneinig.
Drei Regeln, zehn Eingaben
input popular simple browser
"me@example.com" true true true
"a@b.co" true true true
"first.last+tag@sub.example.co.uk" true true true
"üser@example.com" true true false
"me@example" false false true
"me@@example.com" false false false
"no-at-sign.com" false false false
"me@localhost" false false true
"\"quoted string\"@example.com" true false false
"me@[192.168.0.1]" true true false
popular ist die RFC-angehauchte Regex, die aus der akzeptierten Antwort
kopiert wird, simple ist /^[^\s@]+@[^\s@]+\.[^\s@]+$/, und browser ist
checkValidity()
auf einem <input type="email">.
Bei den ersten drei und den beiden offensichtlichen Ablehnungen sind sie sich einig. Alles andere ist Streit.
Wo sie sich uneinig sind
"üser@example.com" regex=true browser=false
"me@example" regex=false browser=true
"me@localhost" regex=false browser=true
"\"quoted string\"@example.com" regex=true browser=false
"me@[192.168.0.1]" regex=true browser=false
Achte auf die Richtung: Es geht in beide. Die Regex ist kein strengerer Browser, und der Browser ist keine lockerere Regex. Es sind zwei verschiedene Regeln, die sich nur in den uninteressanten Fällen einig sind.
Das ist praktisch relevant, denn es erledigt den Plan, den man üblicherweise
hat: type="email" im Formular und dieselbe Regex auf dem Server. Die beiden
lehnen unterschiedliche Leute ab.
Der Browser implementiert nicht RFC 5322
me@example und me@localhost werden akzeptiert: Der Browser verlangt keinen
Punkt in der Domain. üser@example.com wird abgelehnt, obwohl es solche
Adressen gibt und sie zustellen.
Das ist kein Fehler. Die HTML-Spezifikation definiert ein eigenes E-Mail-Muster und bezeichnet es ausdrücklich als absichtliche Abweichung von RFC 5322 — gewählt, um implementierbar und praxistauglich zu sein statt vollständig. “Der Browser macht es falsch” ist also die falsche Sichtweise: Er folgt einer anderen, dokumentierten Regel.
Der Fehlerfall, der dich etwas kostet
real addresses the popular regex rejects:
me@localhost popular=false browser=true
user@[IPv6:2001:db8::1] popular=false browser=false
Eine Regex, die einen Tippfehler durchlässt, kostet dich eine unzustellbare Mail. Eine Regex, die eine echte Adresse ablehnt, kostet dich den Nutzer, der sich jetzt nicht registrieren kann und nicht weiß, warum. Diese beiden Fehler sind nicht gleich schlimm, das Muster sollte also eher locker sein.
Was tatsächlich etwas beweist
Nichts von alledem sagt dir, dass die Adresse existiert oder dass die Person, die sie tippt, sie lesen kann. Genau eines tut das: eine Mail mit einem Einmal-Link schicken und schauen, ob jemand klickt.
Die Anordnung, die funktioniert:
<input type="email" required>im Formular — eine kostenlose Prüfung im Client und auf dem Handy die passende Tastatur- etwas Lockeres auf dem Server,
/^[^\s@]+@[^\s@]+\.[^\s@]+$/, gegen das fehlende@ - eine Bestätigungsmail für die eigentliche Entscheidung
Die Regex fängt Tippfehler. Behandle sie als das, und sie hört auf, ein schweres Problem zu sein.
Hinweis zu Netcup (Werbung)
Der deutsche Hoster Netcup bietet unter anderem günstige und zugleich leistungsstarke Webhosting Pakete, KVM-basierte Root Server und dezidierte Server an. Mit unseren Gutscheincodes kannst du noch mehr Geld sparen (6€ bei deiner ersten Bestellung, 30% Rabatt auf alle KVM-basierten Root Server, ...).