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

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

pour éviter les rejets faussement positifs d'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 RFC 3490 ,"Internationalizing Domain Names in Applications (IDNA)". Je sais que les gens en nous et souvent ne sont pas sur ce sujet, mais il est déjà en à grande échelle et rapidement de l'augmentation de l'utilisation à travers le monde (principalement les non-anglais dominé pièces).

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é ci-dessus, même les adresses simples qmail-style +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 fait important--il y a un nombre important et croissant de mises en œuvre appuyant cette amélioration qui sont actuellement en service.

Je ne savais pas grand chose de ce développement moi-même jusqu'à ce que je suis revenu au Japon et ai commencé à voir des adresses e-mail comme hei@やる.ca et Amazon URLs comme ceci:

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

je te connais ne voulez pas de liens vers des spécifications, mais si vous vous fiez uniquement sur les connaissances dépassées des pirates sur les forums Internet, votre validateur e-mail finira par rejeter les adresses e-mail que les utilisateurs non-anglais s'attendent de plus en plus à travailler. Pour ces utilisateurs, une telle validation sera tout aussi gênante que la forme de mort cérébrale que nous détestons tous, celle qui ne peut pas gérer un + ou un nom de domaine en trois parties ou quoi que ce soit.

donc je ne dis pas que ce n'est pas un problème, mais la liste complète des personnages "permis sous certaines/tout/none conditions" est (presque) tous les caractères de toutes les langues. Si vous voulez "accepter toutes les adresses e-mail valides (et beaucoup d'invalides aussi)", alors vous devez prendre en compte 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 avoir fait cela, vous pouvez suivre (la plupart du temps) les conseils ci-dessus.

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

les local-part et domain-part pourraient avoir un ensemble différent de caractères autorisés, mais ce n'est pas tout, car il y a plus de règles à cela.

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

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

domaine partie:

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

ces adresses e - mail sont valables:

• 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 à 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é de localhost)
• example@s.solutions (voir la liste des domaines de premier niveau )
• user@com
• user@localserver
• user@[IPv6:2001:db8::1]

et ces exemples d'invalides:

• Abc.example.com (pas de "1519370920 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 citées 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 antislashes ne peuvent exister qu'à l'intérieur d'une chaîne de caractères et précédés d'un antislash)
• this\ still\"not\allowed@example.com (même si elle est échappée (précédée d'un antislash), les espaces, les guillemets et les antislashes 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
• une adresse valide avec un espace arrière

Source: adresse de Courriel Wikipedia

Perl's RFC2822 regex for validating e-mails:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-"151900920"
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\".\[\] 
"151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|
\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"
(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\
".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[
\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\".\[\] "151900920"0-
1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([
^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\"
.\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\
]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\
[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\
r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 
"151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]
|\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\".\[\] "151900920"
00-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?
:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".
\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]
]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\
".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\
]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\
".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".
\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] "151900920"0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

le regexp complet pour les adresses RFC2822 était un simple 3,7 K.

Voir aussi: RFC 822 Adresse Email Parser PHP .

les définitions formelles des adresses e-mail sont dans:

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

connexes:

• La vraie puissance des expressions régulières

Wikipedia a un bon article sur ce , et la spécification officielle est ici . De Wikipdia:

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

• majuscules et minuscules lettres anglaises (a-z, A-Z)
• chiffres 0 à 9
• caractères ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• caractère . (Point, Point, Point) pourvu qu'il ne s'agisse pas du Premier ou du dernier caractère, et pourvu aussi qu'il n'apparaisse pas deux fois ou plus consécutivement.

en outre, Cité-chaînes (c'est-à-dire: "John Doe"@example.com) sont autorisés, permettant ainsi des caractères qui seraient autrement interdits, mais qui n'apparaissent pas dans la pratique courante. RFC 5321 avertit également que "un hôte qui s'attend à recevoir du courrier devrait éviter définition des boîtes aux lettres où la partie locale nécessite (ou utilise) la forme de chaîne Citée".

nom:

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

Serveur:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

vous pouvez commencer de article de wikipedia :

• majuscules et minuscules lettres anglaises (a-z, A-Z)
• chiffres 0 à 9
• caractères ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• caractère . (Point, Point, Point) pourvu qu'il ne s'agisse pas du Premier ou du dernier caractère, et pourvu aussi qu'il n'apparaisse pas deux fois ou plus consécutivement.

Google faire une chose intéressante avec leur gmail.com adresses. gmail.com les adresses n'autorisent que les lettres (A-z), les nombres et les périodes(qui sont ignorées).

p.ex., pikachu@gmail.com est le même que pi.kachu@gmail.com, et les deux adresses email 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, il dépend parfois de l'exécuteur sur la quantité des normes RFC qu'ils envie de suivre. Google gmail.com le style d'adresse est compatible avec les standards. Ils le font de cette façon pour éviter la confusion où des personnes différentes 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 Wikipédia est une bonne référence sur ce que les adresses e-mail permettent généralement. http://en.wikipedia.org/wiki/Email_address

Check for @ and . et ensuite envoyer un email pour vérifier.

Je ne peux toujours pas utiliser mon .nom adresse e-mail sur 20% des sites sur internet parce que quelqu'un a foiré leur validation e-mail, ou parce qu'il est antérieur à la validité des nouvelles adresses.

La réponse courte est qu'il y a 2 réponses. Il y a une norme pour ce que vous devriez faire. ie comportement qui est sage et de vous garder hors de l'ennui. Il y a une autre norme (beaucoup plus large) pour le comportement que vous devriez accepter sans créer de problèmes. Cette dualité fonctionne pour l'envoi et acceptation de courrier électronique, 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, il suffit de transmettre tout ce qui est suffisamment compréhensible pour voir une prochaine étape. Ou commencer à lire un tas de RFC, attention, voici dragons.

Une bonne lecture sur le matière .

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

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é en la matière.

IETF RFC 3696 est une autorité sur cette question, et doivent être consultés à la section 3. Restrictions sur les adresses email à la page 5:

les adresses e-mail contemporaines se composent d'un la partie" séparé de un "nom de domaine" (un nom de domaine pleinement qualifié) par un arobase ("@"). La syntaxe de la partie Domaine correspond à celle de la précédente section. Les préoccupations soulevées dans cette section au sujet du filtrage et de la des listes de noms s'appliquent aux noms de domaine utilisé dans un e-mail contexte bien. Le nom de domaine peut également être remplacé par une adresse IP crochets, mais c'est fortement déconseillé sauf pour les les tests et la résolution de problèmes.

la partie locale peut apparaître en utilisant les conventions de citation décrites dessous. Les formulaires cités sont rarement utilisés dans la pratique, mais sont nécessaires pour certaines fins légitimes. Par conséquent, ils ne devraient pas être rejetées dans routines de filtrage mais, devrait plutôt être passé au système de courrier électronique pour l'évaluation par l'hôte de destination.

la règle exacte est que tout caractère ASCII, y compris le contrôle caractères, apparaissent la cité, ou dans une chaîne entre guillemets. Lorsque l'on cite être nécessaire, le caractère barre oblique est utilisée pour citer les suivantes caractère. Par exemple

  Abc\@def@example.com

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

  Fred\ Bloggs@example.com

le caractère antislash peut aussi être utilisé pour citer lui-même, par exemple,

  Joe.\Blow@example.com

en plus de citer en utilisant le caractère backslash, conventionnel les caractères à guillemets doubles 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 cités les formes sont rarement recommandé, et sont rares dans la pratique, mais, comme doivent être appuyées par des demandes qui sont en cours de traitement adresse. En particulier, les formes citées apparaissent souvent dans les contexte des adresses associées aux transitions d'autres systèmes ces exigences transitoires se posent encore et, depuis un système qui accepte une adresse email fournie par l'utilisateur ne peut pas "savoir" si cette adresse est associée à un système d'héritage, l' les formulaires d'adresse doivent être acceptés et transmis dans l'environnement de courriel.

sans guillemets, les parties locales peuvent être constituées de n'importe quelle combinaison de

les caractères alphabétiques, chiffres, ou l'un des caractères spéciaux

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

(".") peut également apparaître, mais ne peut pas être utilisé pour commencer ou fin le partie locale, ni deux ou plusieurs périodes consécutives ne peuvent apparaître. Autrement dit, tout caractère graphique (d'impression) ASCII autre que l'arobase ("@"), la barre oblique inverse, des guillemets, des virgules ou des crochets peut apparaître sans citation. Si l'une de ces listes d'exclus des personnages apparaissent, ils doivent être indiqués. Formulaires tels que

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

sont valables et sont vus assez régulièrement, mais l'un des caractères énumérés ci-dessus sont autorisés.

comme d'autres l'ont fait, je soumets un regex qui fonctionne à la fois pour PHP et JavaScript pour valider les adresses email:

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

comme peut être trouvé dans ce lien Wikipédia

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

• lettres latines majuscules et minuscules A à Z et a à z ;

• chiffres 0 à 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 exemple John..Doe@example.com n'est pas autorisé mais "John..Doe"@example.com est autorisé);

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

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

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

une chaîne de caractères Citée peut exister en tant qu'entité séparée par des points à l'intérieur de la partie locale, ou elle peut exister lorsque les guillemets les plus extérieurs sont les caractères les plus extérieurs de la partie locale (par exemple, abc."defghi".xyz@example.com ou "abcdefghixyz"@example.com sont autorisés. À l'inverse, abc"defghi"xyz@example.com ne l'est pas; abc\"def\"ghi@example.com ne l'est pas non plus ). Les chaînes de caractères et les caractères cités sont pas couramment utilisés. RFC 5321 avertit é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 nécessite (ou utilise) la forme de chaîne Citée".

la partie locale postmaster est traitée spécialement-elle est insensible à la casse, et doit être transmise à l'administrateur du courriel de domaine. Techniquement, toutes les autres parties locales sont sensibles à la casse, donc jsmith@example.com et JSmith@example.com spécifient différentes les 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 qui sont techniquement valables; les organisations, les services de courrier, les serveurs de courrier et les clients de courrier en pratique souvent n'acceptent pas tous. Par exemple, Windows Live Hotmail ne permet la création d'adresses e-mail qu'en utilisant des caractères alphanumériques, point ( . ), underscore ( _ ) et un trait d'Union ( - ). Le conseil commun est de évitez d'utiliser certains caractères spéciaux pour éviter le risque de courriels rejetés.

, La réponse est (presque) ALL (ASCII 7 bits).

Si les règles d'inclusion est "...permis sous certaines/tout/none conditions..."

simplement en regardant l'une des règles d'inclusion possibles pour le texte autorisé dans la partie "texte du domaine" dans 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 seules barres manquantes dans cette description sont utilisées dans domain-literal [] , pour former une paire de guillemets \ , et le caractère d'espace blanc (%d32). Avec cela on utilise toute la gamme 32-126 (décimal). Une exigence similaire apparaît sous la forme de "qtext" et "ctext". Nombre de caractères de contrôle sont également autorisés. Une liste de ces variables de contrôle apparaît à la page 31 section 4.1 de la RFC 5322 comme 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 règle d'inclusion est donc "trop large". Ou, en d'autres sens, l'espérance de la règle est "trop simpliste".

dans mon PHP j'utilise ce contrôle

<?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

j'ai créé ce regex selon les directives du RFC:

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

pour ceux qui s'intéressent à la validation de domaines internationaux, il existe un outil .NET disponible ici (non affilié à la société):

http://cobisi.com/email-validation/.net-component - conforme à une longue liste de RFC:

IETF standards (RFC 1123, RFC 2821, RFC 2822, RFC 3490, RFC 3696, RFC 4291, RFC 5321, RFC 5322 et RFC 5336), avec prise en charge des mots cités, littérales du domaine, les noms de domaine non ASCII (IDNA) et les boîtes aux lettres, et commentaires

par souci de simplicité, je nettoie la soumission en enlevant tout le texte entre guillemets doubles et ceux associés entourant les guillemets doubles avant validation, en mettant le kibosh sur les soumissions d'adresses de courriel basées sur ce qui est interdit. Juste parce que quelqu'un peut avoir le John ... "The*$hizzle*Bizzle"..Doe@whatever.com l'adresse ne veut pas dire que je dois l'autoriser dans mon système. Nous vivons dans le futur où il prend peut-être moins de temps pour obtenir une adresse de messagerie que pour faire un bon travail d'essuyage vos fesses. Et ce n'est pas comme si les critères d'email n'étaient pas collés juste à côté de l'entrée disant ce qui est et n'est pas autorisé.

je nettoie aussi ce qui est spécifiquement interdit par divers RFC après que le matériel cité est enlevé. La liste des caractères et des motifs spécifiquement rejetés semble être une liste beaucoup plus courte à tester.

refusé:

    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

confirmer l'Envoi d'un message par courriel à l'restes suite à une tentative d'ajouter ou de modifier l'adresse e-mail est un bon moyen de voir si votre code peut gérer l'adresse de courriel soumise. Si le courriel passe la validation après autant de cycles de désinfection que nécessaire, puis tirer sur cette confirmation. Si une demande revient du lien de confirmation, alors le nouveau courriel peut être déplacé du statut||temporaire||purgatoire de détention ou de stockage pour devenir un vrai, Bonafide email de première classe stocké.

un avis de changement d'adresse de courriel échec ou de succès peut être envoyé à l'ancienne adresse de courriel si vous voulez être prévenant. Les configurations de compte non confirmées pourraient tomber hors du système comme des tentatives ratées entièrement après une quantité raisonnable de temps.

Je n'autorise pas les e-mails stinkhole sur mon système, peut-être que c'est juste jeter de l'argent. Mais, 99,9% du temps les gens font juste la bonne chose et ont un email qui ne pousse pas les limites de conformité à la brink utilisant des scénarios de compatibilité de cas de bord. Faites attention aux DDoS regex, c'est un endroit où vous pouvez avoir des problèmes. Et c'est la troisième chose que je fais, j'ai mis une limite sur combien de temps je suis prêt à traiter un e-mail. S'il a besoin de ralentir ma machine pour être validé-- il ne va pas au-delà de la logique des paramètres de l'API de données entrantes.

Edit: cette réponse a continué à être annelée pour être "mauvais", et peut-être qu'elle le méritait. Peut-être que c'est toujours mauvais, peut-être pas.

Gmail permettra seulement + signe comme caractère spécial et dans certains cas (.) mais tout autre caractère spécial N'est pas autorisé chez Gmail. RFC dit que vous pouvez utiliser des caractères spéciaux, mais vous devriez éviter d'envoyer du courrier à Gmail avec des caractères spéciaux.