Pourquoi la validation de formulaire HTML5 autorise-t-elle les e-mails sans point?


112

J'écris une maquette très simple pour démontrer une certaine validation de formulaire HTML5. Cependant, j'ai remarqué que la validation de l'e-mail ne vérifie pas le point dans l'adresse, ni ne vérifie les caractères après ledit point.

En d'autres termes, "john @ doe" est considéré comme valide, quand ce n'est clairement pas une adresse e-mail valide; "doe" n'est pas un domaine.

Voici comment je codifie mon champ email:

<input type="email" required />

N'est-ce pas assez?

Vérifiez ce violon pour voir ce que je veux dire.

Remarque: je sais comment y parvenir via un modèle RegEx à la place. Je me demande simplement comment quelqu'un pourrait s'en tirer en utilisant le type de courrier électronique à la place.


10
In other words, "john@doe" is considered valid, when it's clearly not a valid email address; doe isn't a domain.Oui, doepeut certainement être un domaine (pensez localhost), et cette adresse est techniquement valide selon les spécifications.
admdrew

2
@admdrew Heh ... ce serait un cas intéressant, si vous envoyez un e-mail à partir du serveur de messagerie lui-même et décidez d'écrire "friend @ localhost"
Katana314

@ Katana314 - hé, ouais. La plupart des serveurs de messagerie (bien configurés) rejetteront les messages envoyés à des adresses qui ne correspondent pas à un domaine attendu, donc en général, il n'y a pas de problème avec les localhostadresses.
admdrew

Réponses:


83

Parce qu'un @ b est une adresse e-mail valide (par exemple, localhost est un domaine valide). Voir http://en.wikipedia.org/wiki/Email_address#Examples

Gardez également à l'esprit que vous devez toujours effectuer la validation d'entrée dans le serveur. La validation côté client doit être uniquement destinée à donner des commentaires à l'utilisateur et ne doit pas être invoquée, car elle peut être facilement contournée.


7
Merci. Je ne vois tout simplement pas comment une entreprise pourrait bénéficier de cette validation par e-mail prête à l'emploi. Facebook ne laisserait personne s'inscrire avec une adresse a @ b. Merci néanmoins pour l'info. (Je n'ai pas voté contre votre réponse)
WEFX

6
Dans le cas de sites Web tels que Facebook avec accès public, cela ne sert à rien. Mais pensez aux sites Web internes. Vous voudrez peut-être écrire à joe @ support. Mais je pense aussi que c'est d'une utilisation minimale. Néanmoins, les navigateurs Web doivent mettre en œuvre sur la base de normes (c'est-à-dire RFC), et non sur les cas les plus courants.
Ali Alavi

9
Je me demande quand la dernière fois que quelqu'un a envoyé un e-mail à localhost!
Matthew Lock

2
À titre indicatif, l'une des adresses e-mail de travail les plus courtes ( recordsetter.com/world-record/shortest-email-address/4327 ) estau@ua
Kyborek

132

Vous pouvez théoriquement avoir une adresse sans "." dans.

Depuis techniquement des choses telles que:

user@com
user@localserver
user@[IPv6:2001:db8::1]

Sont tous des e-mails valides.

Ainsi, la validation HTML5 standard autorise tous les e-mails valides, y compris les plus rares.

Pour quelques explications faciles à lire (au lieu de lire les standards): http://en.wikipedia.org/wiki/Email_address#Examples


1
D'accord, celui-ci répond au «pourquoi», pas à la «solution». J'étais également curieux de savoir pourquoi. Maintenant, je sais ne pas "réparer".
Eleanor Zimmermann

Un exemple du premier type est le domaine uz, qui pointe directement vers une adresse IP à partir d'octobre 2018. Si vous faites un nslookup uz, il pointe vers 91.212.89.8, il devrait donc être possible d'avoir des e-mails sur ce domaine également.
PulseJet

36

Essayez d'ajouter ceci à l'entrée

pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,63}$"

Violon


2
Avec beaucoup de nouveaux domaines disponibles, c'est-à-dire (comptables [11], international [13], etc.) et une longueur maximale potentielle de 63, la valeur de longueur du modèle d'expression régulière devrait être {2, 63}.
unasAquila

42
-1. Premièrement, vous n'avez même pas essayé d'expliquer ce que cela permet ou restreint, ni pourquoi quelqu'un voudrait ces règles. Deuxièmement, c'est beaucoup plus restrictif que ne le permettent les standards (je ne prétendrai pas avoir lu et grokked les standards, mais voir, par exemple, en.wikipedia.org/wiki/Email_address#Internationalization ou les nombreuses questions de validation d'email sur Stack Débordement pour des exemples d'adresses électroniques étranges) Pourquoi le faire? Si quelqu'un entre quelque chose d'inhabituel comme e-mail, acceptez-le - il y a de fortes chances qu'il le sache mieux que vous.
Mark Amery

7
En fait, je dirais que les "chances sont" qu'ils font une erreur. Il se peut qu'ils aient une adresse e-mail très inhabituelle, mais je dirais que la plupart des fois, vous obtiendrez simplement une adresse e-mail correcte à la place d'une adresse e-mail incorrecte si vous l'empêchaiez de passer la validation et demandiez le l'utilisateur à vérifier.
Geoff Kendall

1
Cela devrait avoir un ^, indiquant qu'il devrait commencer à correspondre au début de la chaîne et accepter également les majuscules:^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]+$
Kohjah Breese

13

La RFC 822 , chapitre 6, donne la spécification d'une adresse sous forme augmentée Backus-Naur (BNF):

addr-spec   =  local-part "@" domain
local-part  =  word *("." word)
domain      =  sub-domain *("." sub-domain)

L'utilisation de cette spécification a@best une adresse valide.

METTRE À JOUR

Pour répondre au commentaire de Trejkaz, j'ajoute les définitions suivantes. Nous voyons que SPACE est autorisé mais uniquement entre guillemets.

word          =  atom / quoted-string
atom          =  1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">
SPACE         =  <ASCII SP, space>
CTL           =  <any ASCII control character and DEL> 
qtext         =  <any CHAR excepting <">, "\" & CR, and including linear-white-space>
quoted-pair   =  "\" CHAR  

OTOH, RFC 822 me permet également de mettre des espaces dans la partie locale, ce que Chrome ne semble pas au moins permettre, donc je ne suis pas sûr qu'ils utilisent la RFC comme référence. (Même s'ils devraient l'être!)
Trejkaz

8

Sur cette page MDN, il montre les navigateurs d'expression régulière à utiliser pour valider l'e-mail:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#Validation

Vous pouvez légèrement modifier cette expression régulière pour exiger au moins un point dans le nom de domaine: changez l'étoile *à la fin de l'expression régulière en plus +. Ensuite, utilisez cette expression régulière comme patternattribut:

<input type="email" pattern="^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)+$"></input>

3

Vous pouvez personnaliser le modèle du champ d'e-mail:

input:valid {
  border-color: green
}

input:invalid {
  border-color: red
}
Email:
<input type="email" required value="a@b.c" /><br>

Non-dots Email:
<input type="email" required pattern="[^.]+@[^.]+" value="a@b.c" />


2

Voici comment vous pouvez le faire avec html5 en utilisant un modèle regex. Vous pouvez également inclure un message personnalisé à afficher.

<form>
  <input type="email" value="paul@test" required pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,63}$" title="Hey, you are missing domain part in the email !!!"/>
  <button type="submit">Click Me</button>
</form>


-5

Ce modèle fonctionne toujours pour moi.

Le texte doit être en minuscules pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"mais je pense qu'il couvre plus ou moins la plupart des e-mails.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.