La reconnaissance régulière d'une adresse électronique est-elle difficile?
https://stackoverflow.com/questions/156430
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'ai récemment lu quelque part qu'écrire une expression rationnelle pour faire correspondre une adresse e-mail, en tenant compte de toutes les variations et possibilités de la norme, est extrêmement difficile et considérablement plus compliqué que ce que l'on pourrait supposer au départ.
Quelqu'un peut-il expliquer pourquoi?
Existe-t-il des expressions rationnelles connues et éprouvées qui le font pleinement?
Quelles sont les bonnes alternatives à l'utilisation des expressions rationnelles pour faire correspondre les adresses e-mail?
La solution
Pour la spécification de messagerie formelle , oui, il est techniquement impossible via Regex en raison de la récursivité d'éléments tels que les commentaires (surtout si vous ne supprimez pas d'abord les commentaires dans les espaces), et différents formats différents (une adresse électronique n'est pas toujours quelqu'un@somewhere.tld). Vous pouvez vous en approcher (avec des motifs de Regex massifs et incompréhensibles), mais une meilleure façon de vérifier un courrier électronique est de faire la poignée de main très familière:
- ils vous disent leur e-mail
- vous leur envoyez par courrier électronique un lien de confirmation avec un Guid
-
quand ils cliquent sur le lien, vous savez que:
- l'e-mail est correct
- il existe
- ils le possèdent
Bien mieux que d'accepter aveuglément une adresse e-mail.
Autres conseils
Un certain nombre de modules Perl (par exemple) le font. N'essayez pas d'écrire votre propre expression rationnelle pour le faire. Regardez
Mail::VRFY fera la vérification de la syntaxe et du réseau (le serveur SMTP accepte quelque part cette adresse)
https://metacpan.org/pod/Mail::VRFY
RFC::RFC822::Address - Analyseur d'adresses e-mail à descente récursive.
https://metacpan.org/pod/RFC::RFC822::Address
Mail::RFC822::Address - Validation d'adresse basée sur l'expression rationnelle, il suffit de regarder uniquement pour l'expression rationnelle insensée
http://ex-parrot.com/~pdw/Mail -RFC822-Address.html
Des outils similaires existent pour d'autres langues. Expression rationnelle insensée ci-dessous ...
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)
De toute façon, la validation des adresses électroniques n’est pas très utile. Il n'accroche pas les fautes de frappe courantes ou les adresses électroniques inventées, car elles ont tendance à ressembler syntaxiquement aux adresses valides.
Si vous voulez vous assurer qu'une adresse est valide, vous n'avez pas d'autre choix que d'envoyer un courrier de confirmation.
Si vous voulez juste être sûr que l'utilisateur entre quelque chose qui ressemble à un email plutôt que juste & "asdf &", puis recherchez un @. Une validation plus complexe ne procure aucun avantage réel.
(Je sais que cela ne répond pas à vos questions, mais je pense que ça vaut la peine de le mentionner quand même)
J'ai maintenant rassemblé les cas tests de Cal Henderson, Dave Child, Phil Haack, Doug Lovell et RFC 3696. 158 adresses de test en tout.
J'ai exécuté tous ces tests sur tous les validateurs que j'ai pu trouver. La comparaison se trouve ici: http://www.dominicsayers.com/isemail
Je vais essayer de garder cette page à jour à mesure que les utilisateurs améliorent leurs validateurs. Merci à Cal, Dave et Phil pour leur aide et leur coopération dans la compilation de ces tests et la critique constructive de mon propre validateur .
Les gens doivent être au courant des errata contre la RFC 3696 en particulier. . Trois des exemples canoniques sont en fait des adresses invalides. Et la longueur maximale d'une adresse est de 254 ou 256 caractères, et non 320.
Cela n’a toutefois aucun sens, car autoriser des caractères tels que "+" peut être très utile pour les utilisateurs luttant contre le spam, par exemple. myemail+sketchysite@gmail.com ( adresses Gmail jetables instantanées ).
Seulement lorsqu'un site l'accepte cependant.
Il existe une grammaire sans contexte dans BNF qui décrit les adresses électroniques valides dans RFC-2822 . C'est complexe. Par exemple:
" @ "@example.com
est une adresse email valide. Je ne connais aucun regexps qui le fasse complètement; les exemples habituellement donnés nécessitent que les commentaires soient supprimés en premier. J'ai écrit un analyseur de descente récursif pour le faire complètement une fois.
Accepter ou non des formats d'adresses électroniques bizarres et inhabituels dépend, à mon avis, de ce que l'on veut en faire.
Si vous écrivez un serveur de messagerie, vous devez être très précis et extrêmement correct dans ce que vous acceptez. Le & Quot; insane & Quot; l'expression rationnelle citée ci-dessus est donc appropriée.
Pour le reste d'entre nous, cependant, nous souhaitons simplement nous assurer que les informations saisies par un utilisateur dans un formulaire Web paraissent raisonnables et ne comportent aucune sorte d'injection SQL ni de dépassement de tampon.
Franchement, est-ce que quelqu'un se soucie vraiment de laisser quelqu'un entrer une adresse email de 200 caractères avec des commentaires, des nouvelles lignes, des citations, des espaces, des parenthèses ou tout autre charabia lors de l'inscription à une liste de diffusion, un bulletin d'information ou un site Web? La réponse appropriée à de tels clowns est & "Revenez plus tard lorsque vous avez une adresse qui ressemble à nomutilisateur@domaine.tld &".
. "La validation que je fais consiste à faire en sorte qu'il y ait exactement un '@'; qu'il n'y a pas d'espaces, de valeurs NULL ou de nouvelles lignes; que la partie à la droite du '@' a au moins un point (mais pas deux points dans une rangée); et qu'il n'y a pas de guillemets, de parenthèses, de virgules, de deux points, d'exclamations, de points-virgules ou de barres obliques inverses, qui sont tous plus susceptibles de constituer des tentatives de piratage que des éléments d'une adresse électronique réelle.
Oui, cela signifie que je rejette les adresses valides avec lesquelles quelqu'un pourrait essayer de s'inscrire sur mes sites Web - peut-être que je & "mal" & "; rejeter jusqu'à 0,001% des adresses du monde réel! Je peux vivre avec ça.
Les citations et divers autres éléments rarement utilisés mais valides de la RFC compliquent les choses. Je ne connais pas assez ce sujet pour commenter définitivement, à part & "C'est difficile &"; - mais heureusement d’autres personnes ont écrit à propos de cela longuement.
En ce qui concerne une expression rationnelle valide, le module Perl Mail :: Rfc822 :: Address contient une expression régulière qui fonctionnera apparemment - mais uniquement si des commentaires ont déjà été remplacés par des espaces. (Commentaires dans une adresse e-mail? Vous voyez pourquoi c'est plus difficile que l'on pourrait s'y attendre ...)
Bien sûr, les expressions rationnelles simplifiées qui abondent ailleurs valideront presque toutes les adresses e-mail réellement utilisées ...
Certains types d’expression rationnelle peuvent en réalité correspondre aux crochets imbriqués (compatibles avec Perl, par exemple). Cela dit, j'ai vu une expression rationnelle qui prétend correspondre correctement à la RFC 822 et qui consistait en deux pages de texte sans espace. Par conséquent, le meilleur moyen de détecter une adresse e-mail valide est de lui envoyer un e-mail et de voir s'il fonctionne.
Juste pour ajouter une expression régulière moins folle que celle listée par @mmaibaum:
^[a-zA-Z]([.]?([a-zA-Z0-9_-]+)*)?@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$
Il n’est pas à l’abri des balles et ne couvre certainement pas l’ensemble des spécifications de l’e-mail, mais il fait un travail décent en répondant à la plupart des exigences de base. Mieux encore, il est quelque peu compréhensible et peut être modifié.
Tiré d'une discussion sur HouseOfFusion.com , une ressource ColdFusion de classe mondiale.
Un moyen simple et efficace de vérifier les adresses électroniques en Java consiste à utiliser EmailValidator du Commons Validator d'Apache. bibliothèque.
Je vérifiais toujours une adresse électronique dans un formulaire de saisie avec quelque chose comme cela avant d'envoyer un courrier électronique - même si vous ne saisissiez que quelques fautes de frappe. Vous ne voulez probablement pas écrire un scanner automatisé pour & Quot; la livraison a échoué & Quot; mails de notification. : -)
C’est très difficile, car de nombreuses choses peuvent être valides dans une adresse électronique conformément à la spécification relative à la messagerie électronique, RFC 2822 . Les éléments que vous ne voyez pas normalement, tels que +, sont des caractères parfaitement valides pour une adresse e-mail .. selon les spécifications.
Une section entière est consacrée aux adresses électroniques à l'adresse . http://regexlib.com , qui est une excellente ressource. Je vous suggérerais de déterminer quels critères vous importent et d'en trouver un qui corresponde. La plupart des gens n’ont vraiment pas besoin d’un support complet pour toutes les possibilités offertes par la spécification.
Si vous utilisez le .NET Framework, essayez simplement d’instancier un objet MailAddress et de capturer le FormatException s’il explose, ou de retirer le Address s’il réussit. Sans entrer dans le moindre faux-sens quant aux performances de la capture des exceptions (en réalité, s’il s’agit d’un formulaire Web unique, cela ne fera pas une grande différence), la classe MailBnfHelper.ReadMailAddress() du framework .NET subit un processus assez complexe. processus d’analyse complet (il n’utilise pas de RegEx). Ouvrez Reflector et recherchez <=> et <=> pour voir tous les éléments fantaisistes qu’il contient. Une personne plus intelligente que moi a passé beaucoup de temps à compiler cet analyseur chez Microsoft. Je vais l'utiliser lorsque j'enverrai un courrier électronique à cette adresse. Je pourrais donc aussi bien l'utiliser pour valider l'adresse entrante.
Beaucoup ont essayé, et beaucoup se sont approchés. Vous voudrez peut-être lire le article de Wikipédia et certains autres .
En particulier, vous voudrez bien vous rappeler que de nombreux sites Web et serveurs de messagerie ont une validation simplifiée des adresses électroniques. Par conséquent, ils n'implémentent pas pleinement la norme. C’est suffisant pour que le courrier électronique fonctionne tout le temps.
Essayez celui-ci:
"(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])"
Consultez ici pour plus de détails.
Cependant, plutôt que d’appliquer la norme RFC822, il serait peut-être préférable de la regarder sous un autre angle. Peu importe ce que la norme dit si les serveurs de messagerie ne reflètent pas la norme. Je dirais donc qu'il serait préférable d'imiter ce que font les serveurs de messagerie les plus populaires lors de la validation des adresses électroniques.
Cette classe pour Java contient un validateur: http://www.leshazlewood.com/?p=23
Ceci est écrit par le créateur de Shiro (formellement Ki, formellement JSecurity)
Avantages et inconvénients du contrôle de la validité des adresses e-mail:
Il existe deux types de regex qui valident les courriers électroniques:
- Ceux qui sont trop lâches.
-
Ceux qui sont trop stricts.
Il n'est pas possible pour une expression régulière de correspondre à toutes les adresses de messagerie valides et à aucune adresse de messagerie non valide, car certaines chaînes peuvent ressembler à des adresses de messagerie valides, mais ne sont en réalité dirigées vers la boîte de réception de personne. Le seul moyen de vérifier si un e-mail est réellement valide consiste à l'envoyer à cette adresse pour voir si vous obtenez une sorte de réponse. Dans cet esprit, les expressions rationnelles trop strictes pour faire correspondre les courriels ne semblent pas vraiment avoir une raison d'être.
Je pense que la plupart des personnes qui demandent une regex par courrier électronique recherchent la première option, les regex trop lâches. Ils veulent tester une chaîne et voir si elle ressemble à un e-mail. S'il ne s'agit certainement pas d'un e-mail, ils peuvent dire à l'utilisateur: & "Hey, vous êtes censé mettre un e-mail ici. et ce n'est certainement pas un courriel valide. Vous n’avez peut-être pas compris que ce champ s’appliquait à un courrier électronique ou qu’il y avait peut-être une faute de frappe & Quot;.
Si un utilisateur insère une chaîne qui ressemble beaucoup à un courrier électronique valide, mais n'en est pas une, il s'agit d'un problème qui devrait être traité par une autre partie de l'application.
Quelqu'un peut-il expliquer pourquoi?
Oui, il s’agit d’une norme extrêmement complexe qui autorise de nombreuses choses que personne n’utilise vraiment aujourd’hui. :)
Existe-t-il des expressions rationnelles connues et ayant fait leurs preuves qui le font pleinement?
Voici une tentative d'analyse complète de la norme entière ...
http://ex-parrot.com/~pdw/Mail -RFC822-Address.html
Quelles sont les bonnes alternatives à l'utilisation des expressions rationnelles pour faire correspondre les adresses électroniques?
Vous utilisez un framework existant dans la langue que vous utilisez, je suppose? Bien que ceux-ci utiliseront probablement l'expression rationnelle en interne. C'est une chaîne complexe. Les expressions régulières sont conçues pour analyser les chaînes complexes, c'est donc votre meilleur choix.
Modifier : je devrais ajouter que l'expression rationnelle à laquelle j'ai lié était juste pour le plaisir. Je n'approuve pas l'utilisation d'une expression rationnelle complexe comme celle-ci - certaines personnes disent que & "Si votre expression rationnelle est composée de plusieurs lignes, il est garanti qu'un bogue s'y trouve &" ;. J'y ai fait un lien pour illustrer la complexité de la norme.
Pour ajouter à la réponse de Wayne , il existe également une section sur www.regular-expressions.info dédié au courrier électronique, avec quelques exemples.
Vous pouvez toujours vous demander si cela en vaut la peine ou si une quelconque expression rationnelle dont la couverture est inférieure à 100% ne fait que contribuer à créer un faux sentiment de sécurité.
En fin de compte, l'envoi de l'email est ce qui fournira la validation finale réelle. (-Vous saurez si votre serveur de courrier a des bugs; -)
Pour compléter ce message, il existe également pour PHP une fonction intégrée dans le langage permettant de valider les e-mails.
Pour PHP Utilisez la variable filter_var avec le type de validation EMAIL spécifique:)
Plus de regex d'e-mails fous dans php: D
var_dump(filter_var('bob@example.com', FILTER_VALIDATE_EMAIL));
