HTML5 - input type email

[cookie961]

Hallo,

ich habe eine Frage zum "neuen" input type="email".
Und zwar werden die EIngaben ja bereits vom Browser geprüft. Wie ich durch testen herausgefunden habe, filtern unterschiedliche Browser die Adressen unterschiedlich.

So lässt Firefox den String "dö1!@wd" als E-Mail Adresse durchgehen. Hingegen Chrome und der IE nicht. Gibt es irgendwo eine Dokumentation oder ähnliches wo man sieht wie genau bei welchem Browser gefiltert wird?

Des weiteren habe ich gelesen, dass beim input type ="email" immer die Regular Expression
/^[1]+@[a-zA-Z0-9-]+(?:.[a-zA-Z0-9-]+)*$/
verwendet wird. Aber wie kann es dann sein, dass unterschiedliche Browser unterschiedliche Strings durchlassen? Oder hab ich da was falsch verstanden.

Mfg,

---

1. a-zA-Z0-9.!#$%&'*+/=?^_`{|}~- ↩︎

[Robert B.]

Moin cookie961,

ich habe eine Frage zum "neuen" input type="email".
Und zwar werden die EIngaben ja bereits vom Browser geprüft. Wie ich durch testen herausgefunden habe, filtern unterschiedliche Browser die Adressen unterschiedlich.

Dabei ist doch spezifiziert, wie eine Emailadresse auszusehen hat.

Des weiteren habe ich gelesen, dass beim input type ="email" immer die Regular Expression
/^[1]+@[a-zA-Z0-9-]+(?:.[a-zA-Z0-9-]+)*$/
verwendet wird. Aber wie kann es dann sein, dass unterschiedliche Browser unterschiedliche Strings durchlassen? Oder hab ich da was falsch verstanden.

Vielleicht haben die Browserhersteller auch etwas anders verstanden ;-)

Viele Grüße,
Robert

---

1. a-zA-Z0-9.!#$%&'*+/=?^_`{|}~- ↩︎

[Gunnar Bittersmann]

@@Robert B.:

nuqneH

Dabei ist doch spezifiziert, wie eine Emailadresse auszusehen hat.

Nei-en!! Wir müssen nicht dieselbe Diskussion noch mal führen, oder?

Selbstverständlich sollte eine E-Mail-Adresse auch Nicht-ASCII-Zeichen enthalten dürfen: иван@царевич.испытание, שמואל@גאלדבערג.טעסט

E-Mail-Adresse im Sinne von: was der Nutzer als Adresse verwendet, nicht was im Hintergrund von irgendwelchen Protokollen als E-Mail-Adresse angesehen wird. Die Umsetzung der Nicht-ASCII-Zeichen in ASCII-Zeichen auf niederen Ebenen inteessiert den Nutzer rein gar nicht.

Vielleicht haben die Browserhersteller auch etwas anders verstanden ;-)

Manche Browserhersteller haben es noch nicht verstanden und haben <input type="email"> falsch implementiert.

Qapla'

[cookie961]

Erst mal Danke für die schnellen Antworten. :)

Vielleicht haben die Browserhersteller auch etwas anders verstanden ;-)

Manche Browserhersteller haben es noch nicht verstanden und haben <input type="email"> falsch implementiert.

Sprich, es gibt eine Standardisierte Regular Expression(wenn ja, welche?), die nur nicht bei allen Browsern richtig implementiert ist? Ich versteh nicht ganz nach was sich da gerichtet wird. Für mich als Laien klingt das irgendwie komisch, dass Eine Regular Expression, die ja immer gleich funktionieren sollte in verschiedenen Browsern anders implementiert wurde?!

LG

[Gunnar Bittersmann]

@@cookie961:

nuqneH

Sprich, es gibt eine Standardisierte Regular Expression(wenn ja, welche?)

.+@.+

Man könnte das weiter einschränken, das wird aber sehr aufwändig. Aber wozu?

Qapla'

[Felix Riesterer]

Lieber Gunnar Bittersmann,

.+@.+

in meinem FF (aktuell) wird ein führendes Leerzeichen reklamiert. Ganz so einfach kann die RE also nicht sein...

Liebe Grüße,

Felix Riesterer.

[1UnitedPower]

Hakuna matata!

.+@.+

in meinem FF (aktuell) wird ein führendes Leerzeichen reklamiert. Ganz so einfach kann die RE also nicht sein...

Es gibt keinen regulären Ausdruck, der eine Email-Adresse richtig erkennt, und es kann auch keinen geben, weil die Sprache der Email-Adressen nicht regulär ist.

Um einen korrekten Email-Parser mit JavaScript zu schreiben, reichen reguläre Ausdrücke einfach nicht aus. Endliche Automaten würden sich dafür eignen, aber dadurch wird das ganze Unterfangen auch gleich sehr viel komplizierter.

Aber, wenn ich Gunnar richtig verstanden habe, wäre ein korrekter Validator sowieso nicht erstrebenswert, weil Email-Provider toleranter mit der Syntax sind, als es im Standard festgelegt ist.

In jedem Fall halte ich es für besser, eine falsche Emailadresse versehentlich zu akzeptieren, als eine korrekte Emailadresse aus Übereifer zurückzuweisen, denn die clientseitige Validierung ist ja nur ein Service für den Endnutzer, die ihm dabei helfen sollen offensichtliche Fehler (@ vergessen?) zu vermeiden. Mit den komplizierten Regeln kennt sich doch sowieso kein Mensch aus.

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Hakuna matata!

.+@.+

in meinem FF (aktuell) wird ein führendes Leerzeichen reklamiert. Ganz so einfach kann die RE also nicht sein...

Es gibt keinen regulären Ausdruck, der eine Email-Adresse richtig erkennt, und es kann auch keinen geben, weil die Sprache der Email-Adressen nicht regulär ist.

Klar, das liegt daranb, dass es gar keine Email-Adressen gibt, sondern nur Email-Namen.
Das wurde hier von den Sprachwissenden und den Ignoranten zwar schon öfter kontrovers diskutiert, und immer kam nur Müll dabei heraus, aber die Definition in der IT lautet:

Adresse:
Ein Platzhalter für eine Ortsangabe eines Objektes oder einer Objektgruppe. Bei Bewegung der Objekte oder Objektgruppe im Definitionsraum muss sich deren Adresse ändern, da sie den Ort und nicht dsas Objekt selbst beschreibt.

Name:
Ein Bezeichner für ein Objekt oder eine Objektgruppe. Bei Bewegung des Objektes im Definitionsraum bleibt der Name am Objekt haften, da er das Objekt und nicht dessen Ort beschreibt.

Wenn der Mailserver von web.de von Karlsruhe nach Stuttgart/Patch Barracks umzieht, ändern sich die Mailnamen der User überhaupt nicht. Aber im DNS tut sich was, und zwar nur an einer einzigen Stelle. Wenn die Änderung nun direkt die Bezeichner der Objekte betreffen würde, würde der DNS an den notwendigen Änderungen schwitzen ;-P

Spirituelle Grüße
Euer Robert

[Matthias Apsel]

Om nah hoo pez nyeetz, Robert R.!

Das sind mir die richtigen:

Erst sich beschweren und dann nicht auf Antworten reagieren. ;-)

https://forum.selfhtml.org/?t=219161&m=1512364

Matthias

[1UnitedPower]

Hakuna matata!

Es gibt keinen regulären Ausdruck, der eine Email-Adresse richtig erkennt, und es kann auch keinen geben, weil die Sprache der Email-Adressen nicht regulär ist.

Klar, das liegt daranb, dass es gar keine Email-Adressen gibt, sondern nur Email-Namen.

Nein, darauf wollte ich definitiv nicht hinaus. Ich habe nicht von menschlicher Sprache, sondern von formalen Sprachen geredet. Das sind mathematische Modelle und man kann mit mathematischen Methoden bestimmte Eigenschaften für diese formalen Sprachen nachweisen. Wenn man für eine Sprache zum Beispiel zeigen kann, dass sie nicht regulär ist, dann kann man daraus folgern, dass es auch keinen regulären Ausdruck für diese Sprache geben kann. Das hat mit missverständlicher menschlicher Sprache nicht das Geringste zu tun, das sind objektive Fakten. Es ist nicht so, dass wir einfach alle zu blöd sind einen regulären Ausdruck für Email-Adressen zu finden, es ist einfach so, dass es beweisbar keinen geben kann.

Wenn ich mir die Grammatik von RFC5322 anschaue, dann würde ich rein intuitiv sagen, dass diese zwei Produktionsregeln dafür verantworlich sind, dass die formale Sprache der Email-Adressen nicht regulär ist:

ccontent        =   ctext / quoted-pair / comment  
comment         =   "(" *([FWS] ccontent) [FWS] ")"

Intuitiv deshalb, weil sich die Produktionsregeln rekursiv quasi unendlich oft anwenden lassen, außerdem sieht dieser Ausschnitt der Dyck-Sprache (die Sprache der korrekt geklammerten Ausdrücke) sehr ähnlich, welche ebenfalls nicht regulär ist. Formal könnte man diese Eigenschaft mit dem Pumping-Lemma beweisen.