Quels caractères sont autorisés dans une adresse e-mail?


641

Je ne demande pas de validation complète par e-mail.

Je veux juste savoir quels sont les caractères autorisés user-nameet les serverparties de l'adresse e-mail. Cela peut être simplifié à l'extrême, peut-être que les adresses e-mail peuvent prendre d'autres formes, mais je m'en fiche. Je pose des questions sur ce simple formulaire: user-name@server(par exemple wild.wezyr@best-server-ever.com) et les caractères autorisés dans les deux parties.


185
Le +est autorisé. Cela me rend fou lorsque les sites Web ne le permettent pas parce que mon e-mail contient un +et tant de sites ne le permettent pas.
Dan Herbert

42
Je pense qu'il est important de donner des liens vers les spécifications, car vous voulez vraiment bien faire les choses, et c'est là que la spécification entre en jeu. Si vous êtes trop paresseux pour lire et comprendre la spécification, veuillez laisser la vérification des caractères autorisés dans les adresses e-mail aux gens qui se soucient de ce truc.
jhwist

9
Question précédente couvrant le même matériau: stackoverflow.com/questions/760150/ . Le plus triste est que, même si cette question a presque 8 mois de plus que celle-ci, la question la plus ancienne a de bien meilleures réponses. Presque toutes les réponses ci-dessous étaient déjà obsolètes lors de leur publication initiale. Voir l'entrée Wikipedia (et ne vous inquiétez pas, elle a des références officielles pertinentes ).
John Y

10
Contrairement à plusieurs réponses, les espaces sont autorisés dans la partie locale des adresses e-mail, si citées. "hello world"@example.comest valable.
user253751

3
@LaraRuffleColes - Pour Gmail, lorsque vous créez un compte de messagerie, il ne vous permet pas de créer des adresses contenant un signe "+". Le signe "+" ("Plus-adressage") permet à toute personne possédant une adresse Gmail d'ajouter un signe "+" suivi d'une "chaîne" à la fin de son nom d'utilisateur pour créer une adresse e-mail "alternative" ("alias"). à utiliser pour leur compte. Exemple: "example@gmail.com", "example+tag@gmail.com". Une utilisation typique (et probablement "principale") de cela est de pouvoir créer des adresses e-mail alias pour votre compte qui vous permettent de baliser et de filtrer les e-mails entrants, théoriquement filtrés par l'expéditeur.
Kevin Fegan

Réponses:


797

Voir RFC 5322: Format de message Internet et, dans une moindre mesure, RFC 5321: Simple Mail Transfer Protocol .

La RFC 822 couvre également les adresses e-mail, mais elle traite principalement de sa structure:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

Et comme d'habitude, Wikipedia a un article décent sur les adresses e-mail :

La partie locale de l'adresse e-mail peut utiliser l'un de ces caractères ASCII:

  • lettres latines majuscules et minuscules Avers Zet avers z;
  • chiffres 0à 9;
  • caractères spéciaux !#$%&'*+-/=?^_`{|}~;
  • point ., à condition qu'il ne soit pas le premier ou le dernier caractère à moins d'être cité, et à condition qu'il n'apparaisse pas consécutivement à moins d'être cité (par exemple, John..Doe@example.comn'est pas autorisé mais "John..Doe"@example.comest autorisé);
  • l'espace et les "(),:;<>@[\]caractères sont autorisés avec des restrictions (ils ne sont autorisés qu'à l'intérieur d'une chaîne entre guillemets, comme décrit dans le paragraphe ci-dessous, et en outre, une barre oblique inverse ou un guillemet double doit être précédé d'une barre oblique inverse);
  • les commentaires sont autorisés avec des parenthèses à chaque extrémité de la partie locale; par exemple john.smith(comment)@example.comet (comment)john.smith@example.comsont tous deux équivalents à john.smith@example.com.

En plus des caractères ASCII, à partir de 2012, vous pouvez utiliser les caractères internationaux ciU+007F - dessus , encodés en UTF-8 comme décrit dans la spécification RFC 6532 et expliqué sur Wikipédia . Notez qu'à partir de 2019, ces normes sont toujours marquées comme proposées, mais sont déployées lentement. Les changements dans cette spécification ont essentiellement ajouté des caractères internationaux en tant que caractères alphanumériques valides (atext) sans affecter les règles sur les caractères spéciaux autorisés et restreints comme !#et @:.

Pour la validation, voir Utilisation d'une expression régulière pour valider une adresse e-mail .

La domainpièce est définie comme suit :

Les normes Internet (demande de commentaires) pour les protocoles stipulent que les étiquettes de nom d'hôte de composant ne peuvent contenir que les lettres ASCII à atravers z(de manière non sensible à la casse), les chiffres à 0travers 9et le tiret ( -). La spécification d'origine des noms d'hôtes dans la RFC 952 , stipulait que les étiquettes ne pouvaient pas commencer par un chiffre ou par un trait d'union et ne devaient pas se terminer par un trait d'union. Cependant, une spécification ultérieure ( RFC 1123 ) a permis aux étiquettes de nom d'hôte de commencer par des chiffres. Aucun autre symbole, caractère de ponctuation ou espace vide n'est autorisé.


15
@WildWzyr, ce n'est pas si simple. Les adresses e-mail ont beaucoup de règles pour ce qui est autorisé. Il est plus simple de se référer à la spécification que de les énumérer toutes. Si vous voulez le Regex complet, cliquez ici pour avoir une idée de pourquoi ce n'est pas si simple: regular-expressions.info/email.html
Dan Herbert

6
il n'y a pas de liste simple, ce n'est pas parce que vous voulez quelque chose de simple qu'il en sera ainsi. certains personnages ne peuvent se trouver qu'à certains endroits et pas à d'autres. vous ne pouvez pas avoir ce que vous voulez tout le temps.

15
@WildWezyr Eh bien, le caractère point final est autorisé dans la partie locale. Mais pas au début ni à la fin. Ou avec un autre point final. Donc, la réponse N'EST PAS aussi simple qu'une simple liste de caractères autorisés, il existe des règles sur la façon dont ces caractères peuvent être utilisés - .ann..other.@example.comn'est pas une adresse e-mail valide, mais l' ann.other@example.comest, même si les deux utilisent les mêmes caractères.
Mark Pim, du

14
N'oubliez pas non plus qu'avec l'arrivée des noms de domaine internationalisés, la liste des caractères autorisés explosera.
Chinmay Kanchi

50
Ce n'est plus la réponse valable, en raison des adresses internationalisées. Voir la réponse de Mason.
ZacharyP

329

Fais attention! Il y a beaucoup de pourriture des connaissances dans ce fil (des choses qui étaient vraies et qui ne le sont plus).

Pour éviter les rejets faussement positifs des adresses e-mail réelles dans le monde actuel et futur, et de n'importe où dans le monde, vous devez connaître au moins le concept de haut niveau de la RFC 3490 , "Internationalisation des noms de domaine dans les applications (IDNA)". Je sais que les gens aux États-Unis et en A ne sont souvent pas au courant de cela, mais il est déjà largement utilisé et en augmentation rapide dans le monde (principalement les parties non dominées par l'anglais).

L'essentiel est que vous pouvez désormais utiliser des adresses comme mason @ 日本 .com et wildwezyr@fahrvergnügen.net. Non, ce n'est pas encore compatible avec tout ce qui existe (comme beaucoup l'ont regretté ci-dessus, même les adresses simples de style qmail + ident sont souvent rejetées à tort). Mais il y a un RFC, il y a une spécification, il est maintenant soutenu par l'IETF et l'ICANN, et - plus important encore - il y a un nombre important et croissant d'implémentations soutenant cette amélioration qui sont actuellement en service.

Je ne savais pas grand-chose sur ce développement moi-même jusqu'à ce que je retourne au Japon et que je commence à voir des adresses e-mail comme hei @ や る .ca et des URL Amazon comme celle-ci:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ク ス - デ ジ タ ル カ メ ラ - ポ ー タ ブ ル オ ー デ ィ オ / b / ref = topnav_storetab_e? ie = UTF8 & node = 3210981

Je sais que vous ne voulez pas de liens vers des spécifications, mais si vous vous fiez uniquement aux connaissances obsolètes des pirates sur les forums Internet, votre validateur de messagerie finira par rejeter les adresses e-mail que les utilisateurs non anglophones s'attendent de plus en plus à travailler. Pour ces utilisateurs, une telle validation sera tout aussi ennuyeuse que la forme banale mortelle que nous détestons tous, celle qui ne peut pas gérer un + ou un nom de domaine en trois parties ou autre.

Donc, je ne dis pas que ce n'est pas un problème, mais la liste complète des caractères "autorisés dans certaines conditions / tout / aucun" est (presque) tous les caractères dans toutes les langues. Si vous souhaitez "accepter toutes les adresses e-mail valides (et beaucoup aussi non valides)", vous devez prendre en compte l'IDN, ce qui rend fondamentalement une approche basée sur les caractères inutile (désolé), sauf si vous convertissez d' abord les adresses e-mail internationalisées en Punycode .

Après cela, vous pouvez suivre (la plupart) les conseils ci-dessus.


17
Droite; dans les coulisses, les noms de domaine sont toujours juste ASCII. Mais, si votre application Web ou votre formulaire accepte les entrées saisies par l'utilisateur, elle doit effectuer le même travail que le navigateur Web ou le client de messagerie lorsque l'utilisateur saisit un nom d'hôte IDN: pour convertir l'entrée utilisateur en un formulaire compatible DNS. Validez ensuite. Sinon, ces adresses e-mail internationalisées ne passeront pas votre validation. (Les convertisseurs comme celui que j'ai lié ne modifient que les caractères non ASCII qui leur sont donnés, il est donc sûr de les utiliser sur des adresses e-mail non internationalisées (celles-ci sont juste retournées non modifiées).)
Mason

2
Pour les développeurs Javascript , je recherche maintenant des méthodes pour le faire, et Punycode.js semble être la solution la plus complète et la plus raffinée.
wwaawaw

5
Notez que le courrier électronique internationalisé (tel que défini actuellement) ne convertit pas les adresses non ASCII à l'aide de punycode ou similaire, mais étend plutôt de grandes parties du protocole SMTP lui-même pour utiliser UTF8.
IMSoP

2
Suis-je en train de manquer quelque chose ou cela ne répond-il pas à la question? Je lis «l'autre réponse est fausse, vous devez accepter plus de caractères» mais ne parvient pas à indiquer quels caractères supplémentaires. Je ne pouvais pas non plus (facilement) voir dans ce RFC s'il s'agissait de tous les points de code Unicode ou simplement du BMP.
Samuel Harmer

3
Cela semble être sur la bonne voie pour être la bonne réponse. Je parie que cela gagnerait beaucoup plus de votes si vous incluiez des détails sur les personnages réservés et autorisés.
Sean

59

Le format de l'adresse e-mail est le suivant: local-part@domain-part (max. 64 @ 255 caractères, plus 256 au total).

Le local-partet domain-partpourrait avoir un ensemble différent de caractères autorisés, mais ce n'est pas tout, car il y a plus de règles.

En général, la partie locale peut avoir ces caractères ASCII:

  • minuscules lettres latines: abcdefghijklmnopqrstuvwxyz,
  • majuscules lettres latines: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • chiffres: 0123456789,
  • caractères spéciaux: !#$%&'*+-/=?^_`{|}~,
  • point: .(pas le premier ou le dernier caractère ou répété sauf si cité),
  • ponctuations spatiales telles que: "(),:;<>@[\](avec certaines restrictions),
  • commentaires: ()(sont autorisés entre parenthèses, par exemple (comment)john.smith@example.com).

Partie du domaine:

  • minuscules lettres latines: abcdefghijklmnopqrstuvwxyz,
  • majuscules lettres latines: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • chiffres: 0123456789,
  • trait d'union: -(pas le premier ou le dernier caractère),
  • peut contenir une adresse IP entourée de crochets: jsmith@[192.168.2.1]ou jsmith@[IPv6:2001:db8::1].

Ces adresses e-mail sont valides:

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com (partie locale d'une lettre)
  • "much.more unusual"@example.com
  • "very.unusual.@.unusual.com"@example.com
  • "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
  • example-indeed@strange-example.com
  • admin@mailserver1 (nom de domaine local sans domaine de premier niveau)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org (espace entre les guillemets)
  • example@localhost (envoyé par localhost)
  • example@s.solutions(voir la liste des domaines de premier niveau Internet )
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

Et ces exemples de non valide:

  • Abc.example.com(pas de @caractère)
  • A@b@c@example.com(un seul @est autorisé en dehors des guillemets)
  • a"b(c)d,e:f;gi[j\k]l@example.com (aucun des caractères spéciaux de cette partie locale n'est autorisé en dehors des guillemets)
  • just"not"right@example.com (les chaînes entre guillemets doivent être séparées par des points ou le seul élément constituant la partie locale)
  • this is"not\allowed@example.com (les espaces, les guillemets et les barres obliques inverses ne peuvent exister que dans les chaînes entre guillemets et précédés d'une barre oblique inverse)
  • this\ still\"not\allowed@example.com (même s'ils sont échappés (précédés d'une barre oblique inverse), les espaces, les guillemets et les barres obliques inverses doivent toujours être contenus par des guillemets)
  • john..doe@example.com(double point avant @); (avec mise en garde: Gmail laisse passer cela)
  • john.doe@example..com(double point après @)
  • une adresse valide avec un espace de tête
  • une adresse valide avec un espace de fin

Source: adresse e-mail sur Wikipedia


RFC2822 regex de Perl pour valider les e-mails:

(?:(?:\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*)

Le regexp complet pour les adresses RFC2822 n'était que de 3,7k.

Voir aussi: RFC 822 Email Address Parser en PHP .


Les définitions officielles des adresses e-mail sont les suivantes:

  • RFC 5322 (sections 3.2.3 et 3.4.1, obsolètes RFC 2822), RFC 5321, RFC 3696,
  • RFC 6531 (caractères autorisés).

En relation:


5
Comme mise en garde supplémentaire pour les futurs implémenteurs de cette expression régulière: ne le faites pas. Vérifiez simplement qu'il suit le format something@something.somethinget appelez-le un jour.
Chris Sobolewski

Bien que quelque chose comme ça ne soit pas maintenable, c'est un bon exercice pour décoder et réellement comprendre ce qu'il fait
unjankify

@ChrisSobolewski autorise plusieurs choses des deux côtés du '@'
Jasen

J'ai essayé de l'implémenter dans postfix via la table d'accès pcre sous une restriction check_recipient_access, en transformant d'abord les 3 longs pcres (à partir de la page liée) en une ligne chacun et en complétant et en suivant ainsi: /^[...pcre ..] $ / DUNNO, puis en ajoutant une dernière ligne /.*/ REJECT, mais cela autorise toujours des adresses e-mail non valides. Postfix 3.3.0; perl 5, version 26, subversion 1 (v5.26.1).
scoobydoo

3
Je dis folie. Qui l'utiliserait jamais en production. Il y a un point où l'expression régulière ne devrait plus être utilisée. C'est bien au-delà de ce point.
tomuxmon

22

Wikipedia a un bon article à ce sujet , et les spécifications officielles sont ici . De Wikipdia:

La partie locale de l'adresse e-mail peut utiliser l'un de ces caractères ASCII:

  • Lettres anglaises majuscules et minuscules (az, AZ)
  • Chiffres 0 à 9
  • Personnages ! # $% & '* + - / =? ^ _ `{| } ~
  • Personnage . (point, point, point final) à condition qu'il ne s'agisse pas du premier ou du dernier caractère, et à condition également qu'il n'apparaisse pas deux fois ou plus consécutivement.

De plus, les chaînes entre guillemets (par exemple: "John Doe" @ example.com) sont autorisées, autorisant ainsi des caractères qui seraient autrement interdits, mais ils n'apparaissent pas dans la pratique courante. La RFC 5321 prévient également qu '"un hôte qui s'attend à recevoir du courrier DEVRAIT éviter de définir des boîtes aux lettres où la partie locale requiert (ou utilise) le formulaire de chaîne entre guillemets".


@WildWezyr Noms d'hôte valides, qui peuvent être une adresse IP, un FQN ou quelque chose pouvant être résolu par un hôte de réseau local.
JensenDied

Les chaînes citées étaient essentielles pour passer par une passerelle, rappelez-vous Banyan Vines?
mckenzm

13

Google fait une chose intéressante avec ses adresses gmail.com. Les adresses gmail.com n'autorisent que les lettres (az), les chiffres et les points (qui sont ignorés).

par exemple, pikachu@gmail.com est identique à pi.kachu@gmail.com, et les deux adresses e-mail seront envoyées à la même boîte aux lettres. PIKACHU@gmail.com est également livré dans la même boîte aux lettres.

Donc, pour répondre à la question, cela dépend parfois de l'implémenteur de la quantité de normes RFC qu'ils souhaitent suivre. Le style d'adresse gmail.com de Google est compatible avec les normes. Ils le font de cette façon pour éviter toute confusion où différentes personnes prendraient des adresses e-mail similaires, par exemple

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

Le lien wikipedia est une bonne référence sur ce que les adresses e-mail permettent généralement. http://en.wikipedia.org/wiki/Email_address


2
Oui, c'est une excellente réponse pour expliquer pourquoi Gmail ne permet pas de créer des e-mails avec cela. Mais vous pouvez envoyer et recevoir des e-mails {john'doe}@my.serversans problème. Testé également avec le serveur hMail.
Piotr Kula

Vous pouvez tester votre client en envoyant un e-mail à {piotr'kula}@kula.solutions- Si cela fonctionne, vous obtiendrez un bon formulaire de réponse automatique. Sinon, rien ne se passera.
Piotr Kula

3
Gmail suit la RFC 6530 en ce sens que toutes les adresses e-mail possibles autorisées par Gmail sont valides selon la RFC. Gmail choisit simplement de restreindre davantage l'ensemble des adresses autorisées avec des règles supplémentaires, et de créer des adresses autrement similaires avec des points dans la partie locale, éventuellement suivis de "+" et de caractères alphanumériques, également.
Teemu Leisti

Google limite les critères de création de compte ... J'imagine qu'ils nettoient la chaîne de compte de messagerie entrante de la "ponctuation" supplémentaire et du signe de chaîne d'alias en fin de chaîne afin que le courrier puisse être acheminé vers le compte approprié. Peasy facile. Ce faisant, ils ne permettent effectivement pas aux gens de créer des adresses e-mail juste à la manière de sorte que les adresses valides créées passent souvent des validations simples et les plus complexes.
BradChesney79

Ce n'est pas seulement gmail, certains fournisseurs ont des "filtres de relais" qui rejettent certaines chaînes entre guillemets, contenant notamment "=" comme s'il s'agissait de délimiteurs. Il s'agit d'empêcher les utilisateurs de configurer des passerelles et d'imbriquer des adresses de spam dans la chaîne privée citée. "@" est valide mais "= @ =" n'est pas (considéré) valide.
mckenzm

12

Vous pouvez commencer à partir d'un article wikipedia :

  • Lettres anglaises majuscules et minuscules (az, AZ)
  • Chiffres 0 à 9
  • Personnages ! # $% & '* + - / =? ^ _ `{| } ~
  • Personnage . (point, point, point final) à condition qu'il ne s'agisse pas du premier ou du dernier caractère, et à condition également qu'il n'apparaisse pas deux fois ou plus consécutivement.

11

Nom:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

Serveur:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

4
Et pour <>et []? Par exemple "()<>[]:,;@\\\"!#$%&'-/=?^_{} | ~ .a "@ example.org`?
kenorb

20
Veuillez citer des sources. Sans sources, cela ressemble à une conjecture.
Mathieu K.

15
Ceci est obsolète et n'a peut-être jamais été correct.
Jason Harrison

9

Vérifiez @ et. puis envoyez un e-mail pour qu'ils vérifient.

Je ne peux toujours pas utiliser mon adresse e-mail .name sur 20% des sites sur Internet parce que quelqu'un a raté sa validation par e-mail ou parce qu'elle est antérieure à la validité des nouvelles adresses.


9
Même. n'est pas strictement nécessaire; J'ai entendu parler d'au moins un cas d'une adresse e-mail dans un domaine de premier niveau (spécifiquement ua). L'adresse était <nom> @ua - pas de point!

C'est à peu près le moyen le plus simple de ne pas gâcher votre validation, car presque tout est autorisé, et si quelque chose n'est pas autorisé, le serveur du destinataire vous le fera savoir.
Avamander

5

La réponse courte est qu'il y a 2 réponses. Il y a une norme pour ce que vous devez faire. c'est-à-dire un comportement sage qui vous évitera des ennuis. Il existe une autre norme (beaucoup plus large) pour le comportement que vous devez accepter sans problème. Cette dualité fonctionne pour l'envoi et l'acceptation de courriels mais a une large application dans la vie.

Pour un bon guide des adresses que vous créez; voir: http://www.remote.org/jochen/mail/info/chars.html

Pour filtrer les e-mails valides, transmettez simplement tout ce qui est suffisamment compréhensible pour voir la prochaine étape. Ou commencez à lire un tas de RFC, attention, voici des dragons.


Le lien a disparu. Quel contenu y avait-il?
ygoe

5

Une bonne lecture à ce sujet .

Extrait:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

1
Je me posais des questions sur le '@' avant la partie domaine. Cela peut-il être utilisé?
Saiyaff Farouk

@SaiyaffFarouk selon les spécifications, oui. Cependant, la plupart des fournisseurs de messagerie ne l'autoriseront probablement pas dans le cadre de leur propre validation
Luke Madhanga

ce blog répertorie Joe.\\Blow@example.comsans guillemets. Est-ce réellement valable? Cela ne semble pas clair étant donné les réponses ici, mais je pose la question parce que j'ai vu des cas (très rares) de chaînes de messagerie DNS SoA rname qui contiennent des barres obliques inverses.
wesinat0r

5

La réponse acceptée fait référence à un article de Wikipédia lors de la discussion de la partie locale valide d'une adresse e-mail, mais Wikipédia n'est pas une autorité à ce sujet.

IETF RFC 3696 est une autorité en la matière et doit être consultée à la section 3. Restrictions sur les adresses e-mail à la page 5:

Les adresses électroniques contemporaines consistent en une "partie locale" séparée d'une "partie de domaine" (un nom de domaine complet) par un signe at ("@"). La syntaxe de la partie domaine correspond à celle de la section précédente. Les préoccupations identifiées dans cette section concernant le filtrage et les listes de noms s'appliquent également aux noms de domaine utilisés dans un contexte de messagerie. Le nom de domaine peut également être remplacé par une adresse IP entre crochets, mais ce formulaire est fortement déconseillé, sauf à des fins de test et de dépannage.

La partie locale peut apparaître en utilisant les conventions de citation décrites ci-dessous. Les formulaires cités sont rarement utilisés dans la pratique, mais sont nécessaires à des fins légitimes. Par conséquent, ils ne doivent pas être rejetés dans les routines de filtrage, mais doivent plutôt être transmis au système de messagerie pour évaluation par l'hôte de destination.

La règle exacte est que tout caractère ASCII, y compris les caractères de contrôle, peut apparaître entre guillemets ou dans une chaîne entre guillemets. Lorsque la citation est nécessaire, le caractère barre oblique inverse est utilisé pour citer le caractère suivant. Par exemple

  Abc\@def@example.com

est une forme valide d'adresse e-mail. Des espaces vides peuvent également apparaître, comme dans

  Fred\ Bloggs@example.com

Le caractère barre oblique inverse peut également être utilisé pour se citer, par exemple,

  Joe.\\Blow@example.com

Outre les guillemets utilisant le caractère barre oblique inverse, des caractères de guillemet double conventionnels peuvent être utilisés pour entourer les chaînes. Par exemple

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

sont des formes alternatives des deux premiers exemples ci-dessus. Ces formulaires cités sont rarement recommandés et sont rares dans la pratique, mais, comme indiqué ci-dessus, ils doivent être pris en charge par les applications qui traitent les adresses e-mail. En particulier, les formes citées apparaissent souvent dans le contexte d'adresses associées à des transitions à partir d'autres systèmes et contextes; ces exigences transitoires existent toujours et, comme un système qui accepte une adresse e-mail fournie par l'utilisateur ne peut pas "savoir" si cette adresse est associée à un système hérité, les formulaires d'adresse doivent être acceptés et transmis dans l'environnement de messagerie.

Sans guillemets, les parties locales peuvent être constituées de n'importe quelle combinaison de
caractères alphabétiques, de chiffres ou de l'un des caractères spéciaux

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

La période (".") peut également apparaître, mais ne peut pas être utilisée pour démarrer ou terminer la partie locale, ni deux périodes consécutives ou plus. Autrement dit, tout caractère graphique (impression) ASCII autre que le signe at ("@"), la barre oblique inverse, les guillemets doubles, les virgules ou les crochets peuvent apparaître sans guillemets. Si l'un de cette liste de caractères exclus doit apparaître, ils doivent être cités. Des formes telles que

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

sont valides et sont vus assez régulièrement, mais tous les caractères énumérés ci-dessus sont autorisés.

Comme d'autres l'ont fait, je soumets une expression régulière qui fonctionne à la fois pour PHP et JavaScript pour valider les adresses e-mail:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

3

Comme on peut le trouver dans ce lien Wikipedia

La partie locale de l'adresse e-mail peut utiliser l'un de ces caractères ASCII:

  • lettres latines majuscules et minuscules Avers Zet avers z;

  • chiffres 0à 9;

  • caractères spéciaux !#$%&'*+-/=?^_`{|}~;

  • point ., à condition qu'il ne soit pas le premier ou le dernier caractère à moins d'être cité, et à condition qu'il n'apparaisse pas consécutivement à moins d'être cité (par exemple, John..Doe@example.comn'est pas autorisé mais "John..Doe"@example.comest autorisé);

  • l'espace et les "(),:;<>@[\]caractères sont autorisés avec des restrictions (ils ne sont autorisés qu'à l'intérieur d'une chaîne entre guillemets, comme décrit dans le paragraphe ci-dessous, et en outre, une barre oblique inverse ou un guillemet double doit être précédé d'une barre oblique inverse);

  • les commentaires sont autorisés avec des parenthèses à chaque extrémité de la partie locale; par exemple john.smith(comment)@example.comet (comment)john.smith@example.comsont tous deux équivalents à john.smith@example.com.

En plus des caractères ASCII ci-dessus, les caractères internationaux supérieurs à U + 007F, codés en UTF-8, sont autorisés par la RFC 6531 , bien que les systèmes de messagerie puissent restreindre les caractères à utiliser lors de l'attribution de parties locales.

Une chaîne entre guillemets peut exister en tant qu'entité séparée par des points dans la partie locale, ou elle peut exister lorsque les guillemets les plus à l'extérieur sont les caractères les plus à l'extérieur de la partie locale (par exemple, abc."defghi".xyz@example.comou "abcdefghixyz"@example.comsont autorisés. Inversement, ce abc"defghi"xyz@example.comn'est pas le cas, ni l'un ni l'autre abc\"def\"ghi@example.com). Cependant, les chaînes et les caractères cités ne sont pas couramment utilisés. La RFC 5321 prévient également qu '"un hôte qui s'attend à recevoir du courrier DEVRAIT éviter de définir des boîtes aux lettres où la partie locale requiert (ou utilise) le formulaire de chaîne entre guillemets".

La partie locale postmasterest traitée spécialement, elle ne respecte pas la casse et doit être transmise à l'administrateur de messagerie du domaine. Techniquement, toutes les autres parties locales sont sensibles à la casse jsmith@example.comet JSmith@example.comspécifient donc différentes boîtes aux lettres; cependant, de nombreuses organisations traitent les lettres majuscules et minuscules comme équivalentes.

Malgré le large éventail de caractères spéciaux techniquement valables; les organisations, les services de messagerie, les serveurs de messagerie et les clients de messagerie dans la pratique ne les acceptent souvent pas tous. Par exemple, Windows Live Hotmail autorise uniquement la création d'adresses e-mail à l'aide des caractères alphanumériques, des points ( .), des traits de soulignement ( _) et des tirets ( -). Le conseil commun est d'éviter d'utiliser certains caractères spéciaux pour éviter le risque d'e-mails rejetés.


0

La réponse est (presque) ALL(ASCII 7 bits).
Si les règles d'inclusion sont "... autorisées sous certaines conditions / toutes / aucune ..."

En examinant simplement l'une des nombreuses règles d'inclusion possibles pour le texte autorisé dans la partie "texte de domaine" de la RFC 5322 en haut de la page 17, nous trouvons:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

les trois seuls caractères manquants dans cette description sont utilisés dans le domaine littéral [], pour former une paire entre guillemets \, et le caractère d'espace blanc (% d32). Avec cela, toute la plage 32-126 (décimale) est utilisée. Une exigence similaire apparaît comme "qtext" et "ctext". De nombreux caractères de contrôle sont également autorisés / utilisés. Une liste de ces caractères de contrôle apparaît à la page 31 section 4.1 de la RFC 5322 en tant que obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

Tous ces caractères de contrôle sont autorisés comme indiqué au début de la section 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

Et une telle règle d'inclusion est donc "trop ​​large". Ou, dans un autre sens, la règle attendue est "trop ​​simpliste".


0

Par souci de simplicité, je désinfecte la soumission en supprimant tout le texte entre guillemets doubles et les guillemets environnants associés avant la validation, en mettant le kibosh sur les soumissions d'adresse e-mail en fonction de ce qui n'est pas autorisé. Juste parce que quelqu'un peut avoir le John .. "Le * $ hizzle * Bizzle" .. L'adresse Doe@wwhat.com ne signifie pas que je dois l'autoriser dans mon système. Nous vivons dans le futur où il faudra peut-être moins de temps pour obtenir une adresse e-mail gratuite que pour faire un bon travail en essuyant vos fesses. Et ce n'est pas comme si les critères de courrier électronique n'étaient pas collés juste à côté de l'entrée indiquant ce qui est et ce qui n'est pas autorisé.

Je désinfecte également ce qui n'est pas spécifiquement autorisé par divers RFC après que le matériel cité est supprimé. La liste des caractères et modèles spécifiquement interdits semble être une liste beaucoup plus courte à tester.

Interdit:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

Dans l'exemple donné:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

L'envoi d'un e-mail de confirmation au résultat restant lors d'une tentative d'ajout ou de modification de l'adresse e-mail est un bon moyen de voir si votre code peut gérer l'adresse e-mail soumise. Si l'e-mail réussit la validation après autant de cycles de désinfection que nécessaire, lancez cette confirmation. Si une demande revient du lien de confirmation, le nouvel e-mail peut être déplacé du statut de purgatoire ou de stockage || temporaire || pour devenir un véritable e-mail stocké de première classe.

Une notification d'échec ou de réussite du changement d'adresse e-mail peut être envoyée à l'ancienne adresse e-mail si vous voulez être prévenant. Les configurations de compte non confirmées peuvent tomber du système en tant que tentatives infructueuses entièrement après un laps de temps raisonnable.

Je n'autorise pas les e-mails stinkhole sur mon système, peut-être que c'est simplement jeter de l'argent. Mais, 99,9% du temps, les gens font juste ce qu'il faut et ont un e-mail qui ne repousse pas les limites de conformité au bord du gouffre en utilisant des scénarios de compatibilité avec les cas limites. Faites attention aux DDoS regex, c'est un endroit où vous pouvez avoir des ennuis. Et cela est lié à la troisième chose que je fais, je mets une limite à la durée pendant laquelle je suis prêt à traiter un seul e-mail. Si elle doit ralentir ma machine pour être validée, elle ne dépasse pas la logique du point de terminaison de mon API de données entrantes.

Edit: Cette réponse a continué à être teintée d'être "mauvaise", et peut-être qu'elle le méritait. Peut-être que c'est encore mauvais, peut-être pas.


2
Je pense que cette réponse est rejetée parce que c'est une opinion, et elle ne répond pas à la question. En outre, les utilisateurs qui obtiennent leur adresse e-mail en silence ne recevront jamais d'e-mails de votre part. Vous feriez mieux de les informer que leur adresse e-mail n'est pas acceptée.
vcarel

2
Je soupçonne que les downvotes sont parce qu'il y a trop d'idées ici. La liste non autorisée, bien qu'il s'agisse de tests unitaires utiles, doit être précédée de ce qui est autorisé. L'approche de programmation semble relativement fine, mais elle conviendrait probablement mieux après avoir répertorié les spécifications avec lesquelles vous travaillez, etc. Juste mes 2 cents.
HoldOffHunger

@vcarel - Oh, absolument. La validation côté utilisateur frontal les informerait des règles (disponibles dans l'info-bulle) qu'ils enfreignaient. Vous avez raison - c'est une opinion globale. Cependant, la question ci-dessus est posée par quelqu'un qui demande à X une question Y à coup sûr. C'est un guide et ça marche ... non seulement ça marche, ça marche bien. Je ne laisse pas les adresses e-mail de conneries dans mes systèmes où je prends les décisions.
BradChesney79

@HoldOffHunger Je peux voir que l'idée globale n'est pas exprimée de manière aussi cohérente qu'elle pourrait l'être, je peux réviser un autre jour où j'ai plus de temps pour mieux exprimer cela. Merci pour la perspicacité.
BradChesney79

-1

Dans mon PHP, j'utilise cette vérification

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[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_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

essayez-le vous-même http://phpfiddle.org/main/code/9av6-d10r


-1

J'ai créé cette expression régulière selon les directives RFC:

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

1
Cette version améliore l'expression régulière en vérifiant la longueur des domaines / sous-domaines. Prendre plaisir! ^ [\\ w \\. \\! _ \\% # \\ $ \\ & \\ '= \\? \ * \\ + \\ - \\ / \\ ^ \ `\\ {\\ | \\} \\ ~] + @ (?: [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])? (?: \\. [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])?) *) $
Mau

-2

Gmail n'autorisera que le signe + en tant que caractère spécial et dans certains cas (.), Mais aucun autre caractère spécial n'est autorisé sur Gmail. Les RFC indiquent que vous pouvez utiliser des caractères spéciaux, mais vous devez éviter d'envoyer des messages à Gmail avec des caractères spéciaux.

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.