Ansicht:   

#365446 Fehler in Regular Expression zur E-Mail-Adress-Validierung (web.coding)

verfaßt von thorr zur Homepage von thorr, Münster (Nordrhein-Westfalen), 14.05.2014, 14:49:03

> Du hast jetzt 3 Varianten für die Länge der TLD (im Regex 2-6, in den
> Gedanken 2-4, in der Beschreibung 2-5).

Na gut, da bin ich wohl ein bisschen inkonsequent.  ;-) Und wie gesagt: bei den TLDs herrschte noch Unsicherheit meinerseits über die (meiner Meinung nach teils unsinnigen) Möglichkeiten, die es da inzwischen gibt.

> Was versprichst Du Dir von der Validierung?
>
> Wenn Du sicherstellen willst, daß die E-Mail-Adresse dazu geeignet ist, dem
> User eine E-Mail zu schicken, hilft es nicht, wenn Du sicherstellst, daß
> eine formal richtige Adresse vorliegt (blabla@example.org hält jeder
> formalen Prüfung stand, eine Mail dorthin wird aber den User nicht
> erreichen).
> Das schaffst Du nur, wenn Du dem User auf die angegebene Adresse eine Mail
> schickst mit einem Code, den der User auf Deiner Seite wieder eingeben muß.
> Nur wenn der User den korrekten Code wieder eingibt (den er NUR per E-Mail
> erhalten darf), weißt Du, daß die Adresse zu diesem Zeitpunkt geeignet ist.

Du hast natürlich Recht, dass eine MX-Record-Überprüfung effektiver und letztendendes auch einfacher ist. Da der spätere Hostinganbieter jedoch u. U. keine externen Verbindungen zulässt, fällt diese Möglichkeit eventuell weg.

Es handelt sich bei der Sache um ein Kontaktformular, in das der Nutzer schon aus eigenem Interesse eigentlich eine korrekte E-Mail-Adresse eintragen sollte. Die Validierung soll lediglich sicherstellen, dass dort, wo eine E-Mail-Adresse einzugeben ist, auch nur eine E-Mail-Adresse akzeptiert wird. Vielleicht hat sich der Nutzer auch vertippt und wird durch die Überprüfung hierauf aufmerksam. Ich würde sagen: Es geht mehr um's Prinzip als um einen praktischen Nutzen für mich.

> Dein Ausdruck läßt ungültige E-Mail-Adressen durch, lehnt dafür aber
> gültige Adressen ab.
>
> Der Hostname (also der Teil nach dem @) darf aus theoretisch unendlich
> vielen Ebenen bestehen, aber dabei gilt:
> 1 bis 64 Zeichen pro Ebene, 256 Zeichen maximal, 2 Ebenen minimal.
>
> Dein Ausdruck erlaubt für die TLD nur 6 Zeichen, es gibt viele deutlich
> längere TLDs, siehe Datenbank der
> TLDs, hier werden also gültige Adressen abgelehnt.
> Dein Ausdruck erlaubt aber auch für jede Ebene (außer der TLD) beliebig
> viele Zeichen.

Was wo im Nutzer- und Hostnamen erlaubt ist, ist in der RegExp noch nicht ganz korrekt. Vielen Dank schon einmal für die Aufklärung diesbezüglich. Diese Details sollen dann zum Schluss umgesetzt werden, zunächst geht es mir erst einmal um die Funktionsweise.

> Daß Du IDN (internationalized domain names, also Domainnamen mit Umlauten
> oder kyrillischen, arabischen, chinesischen, ... Zeichen) mit Deinem Regex
> nicht zuläßt, ist Dir hoffentlich auch bewußt. Diese müßten bei Deiner
> Prüfung als Punycode, also als xn--... eingegeben werden.

Naja, mit den Umlautdomains ist das so eine Sache. Wer eine solche Domain verwendet, muss sich bewusst sein, dass diese im Grunde gar nicht existiert, sondern nicht viel mehr ist als ein rein clientseitiges Gespinst. Internationale Domainnamen können durch Konflikte mit ASCII-Domains sogar zu ernsthaften Inkonsistenzen führen. Gerade im Bereich der E-Mail-Clients gibt es noch keine vollwertige Unterstützung der IDNs. Praktisch sind die IDNs natürlich, allerdings sind sie mit Vorsicht zu genießen. Ich verwende Umlautdomains als Umleitung selbst gerne für Internetauftritte, das ASCII-Äquivalent sollte jedoch immer verfügbar sein, um Inkompatibilitäten schon im Vorfeld entgehen zu können.

 

gesamter Thread:

Ansicht:   
Auf unserer Web-Seite werden Cookies eingesetzt, um diverse Funktionalitäten zu gewährleisten. Hier erfährst du alles zum Datenschutz