Quels sont les caractères autorisés dans une adresse électronique ?

Question

Je ne demande pas la validation complète de l'email.

Je veux juste savoir quels sont les caractères autorisés dans le champ user-name y server les parties de l'adresse électronique. C'est peut-être trop simplifié, les adresses électroniques peuvent peut-être prendre d'autres formes, mais je m'en moque. Je ne m'intéresse qu'à cette forme simple : user-name@server (par exemple, wild.wezyr@best-server-ever.com) et les caractères autorisés dans les deux parties.

Answer 1

Voir RFC 5322 : Format des messages Internet et, dans une moindre mesure, RFC 5321 : Protocole de transfert de courrier simple .

RFC 822 couvre également les adresses électroniques, mais il traite surtout de leur 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 une bonne article sur les adresses e-mail :

La partie locale de l'adresse électronique peut utiliser n'importe lequel de ces caractères ASCII :

• les lettres latines majuscules et minuscules A a Z y a a z ;
• chiffres 0 a 9 ;
• caractères spéciaux !#$%&'*+-/=?^_`{|}~ ;
• point . à condition qu'il ne s'agisse pas du premier ou du dernier caractère sauf s'il est cité, et à condition également qu'il n'apparaisse pas consécutivement sauf s'il est cité (par ex. John..Doe@example.com n'est pas autorisé mais "John..Doe"@example.com est autorisé) ;
• l'espace et "(),:;<>@[\] 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.com y (comment)john.smith@example.com sont toutes deux équivalentes à john.smith@example.com .

En plus des caractères ASCII, à partir de 2012 vous pouvez utiliser les services internationaux caractères ci-dessus U+007F encodé en UTF-8, comme décrit dans le fichier d'aide aux utilisateurs. RFC 6532 spec et expliqué sur Wikipedia . Notez qu'à partir de 2019, ces normes sont toujours marquées comme étant proposées, mais sont déployées lentement. Les changements dans cette spécification ont essentiellement ajouté les 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 tels que !# y @: .

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

El domain la partie est définie comme suit :

Les normes Internet (Request for Comments) relatives aux protocoles stipulent que les étiquettes des noms d'hôtes des composants ne peuvent contenir que les lettres ASCII suivantes a par le biais de z (sans tenir compte de la casse), les chiffres 0 par le biais de 9 et le trait d'union ( - ). La spécification originale des noms d'hôtes dans RFC 952 En vertu de la directive sur l'étiquetage, les étiquettes ne peuvent pas commencer par un chiffre ou un trait d'union et ne doivent pas se terminer par un trait d'union. Toutefois, une spécification ultérieure ( RFC 1123 ) permet aux étiquettes de noms d'hôtes de commencer par des chiffres. Aucun autre symbole, caractère de ponctuation ou espace n'est autorisé.

Answer 2

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

Pour éviter les rejets faussement positifs d'adresses électroniques réelles dans le monde actuel et futur, et depuis n'importe où dans le monde, vous devez connaître au moins le concept de haut niveau suivant RFC 3490 Il s'agit de "Internationalizing Domain Names in Applications (IDNA)". Je sais que les gens des États-Unis et de l'Australie ne sont pas souvent au courant, mais c'est déjà le cas. utilisation répandue et en augmentation rapide dans le monde entier (principalement dans les régions non anglophones).

L'essentiel est que vous pouvez maintenant 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 déploré plus haut, même les simples adresses +ident de style qmail sont souvent rejetées à tort). Mais il y a un RFC, il y a une spécification, elle est maintenant soutenue par l'IETF et l'ICANN, et - plus important encore - il y a un nombre important et croissant d'implémentations supportant cette amélioration qui sont actuellement en service.

Je ne savais pas grand-chose de cette évolution jusqu'à ce que je retourne au Japon et que je commence à voir des adresses électroniques 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 dépassées des hackers sur les forums Internet, votre validateur de courrier électronique finira par rejeter des adresses électroniques que les utilisateurs non anglophones s'attendent de plus en plus à voir fonctionner. Pour ces utilisateurs, cette validation sera tout aussi ennuyeuse que le formulaire banal et sans cervelle que nous détestons tous, celui qui ne peut pas gérer un + ou un nom de domaine en trois parties ou autre.

Je ne dis pas que ce n'est pas une corvée, mais la liste complète des caractères "autorisés dans certaines/toutes/aucune condition" est (presque) tous les caractères dans toutes les langues. Si vous voulez "accepter toutes les adresses électroniques valides (et beaucoup d'autres non valides)", vous devez tenir compte des IDN, ce qui rend inutile une approche basée sur les caractères (désolé), à moins que vous ne commenciez par convertir les adresses e-mail internationalisées (mort depuis septembre 2015, anciennement comme ceci -une alternative fonctionnelle est aquí ) à Punycode .

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

Answer 3

Wikipedia a un bon article sur ce sujet y le spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe spe sp ici . De Wikipédia :

La partie locale de l'adresse électronique peut utiliser n'importe lequel de ces caractères ASCII :

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

En outre, les chaînes de caractères entre guillemets (par exemple : "John Doe"@example.com) sont autorisées, ce qui permet d'utiliser des caractères qui seraient autrement interdits, mais qui 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 dont la partie locale requiert (ou utilise) la forme chaîne citée".

Answer 4

Vous pouvez commencer par article de wikipédia :

• Lettres anglaises majuscules et minuscules (a-z, A-Z)
• Chiffres de 0 à 9
• Caractères ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• Caractère . (point, point, point final) à condition qu'il ne soit pas le premier ou le dernier caractère, et à condition également qu'il n'apparaisse pas deux fois ou plus consécutivement.

Answer 5

Nom :

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

Serveur :

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.