Comment valider une adresse e-mail en JavaScript


4381

Existe-t-il une expression régulière pour valider une adresse e-mail en JavaScript?



60
veuillez bien faire, trop de sites Web n'aiment pas mon adresse e-mail "firstName@secondName.name", tous les domaines de premier niveau ne terminent pas 2 ou 3 lettres.
Ian Ringrose

41
Tout support pour l'utilisation de chèques regex pour les e-mails contre lequel je suis à 100%. J'en ai assez qu'on me dise que mon adresse e-mail "foo+bar@gmail.com" n'est pas valide. La meilleure option est de demander à l'utilisateur de taper son e-mail deux fois et si vous DEVEZ utiliser un vérificateur d'expressions régulières, puis de dire à l'utilisateur que son adresse e-mail ne semble pas être valide et de lui demander s'il est sûr de l'avoir tapé droite. Allez même jusqu'à signaler CE QUI n'a pas été vérifié lors de la vérification d'expression régulière, mais ne les empêchez PAS de soumettre le formulaire.
Soundfx4

17
@ Soundfx4: cela devrait être LA réponse, et accepté comme tel. Tester l'exactitude d'une adresse est une chose stupide à faire - la meilleure façon de frustrer les clients. Je demande que l'adresse soit tapée deux fois et laisse entendre qu'il y a des problèmes possibles (manquants @, ;cometc.) et laisse l'utilisateur les corriger s'il le souhaite (et accepte tout ce qu'il m'envoie)
WoJ

4
Je suis totalement d'accord avec la réponse donnée par WoJ. Le format d'une adresse e-mail valide est beaucoup trop complexe pour être vérifié avec une simple expression régulière. La seule façon d'être certain que l'adresse est valide est de l'essayer.
Nicole

Réponses:


4950

L'utilisation d' expressions régulières est probablement la meilleure façon. Vous pouvez voir un tas de tests ici (tirés du chrome )

function validateEmail(email) {
    const re = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
    return re.test(String(email).toLowerCase());
}

Voici l'exemple d'une expression régulière qui accepte unicode:

const re = /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})$/i;

Mais gardez à l'esprit qu'il ne faut pas se fier uniquement à la validation JavaScript. JavaScript peut facilement être désactivé. Cela devrait également être validé côté serveur.

Voici un exemple de ce qui précède en action:

function validateEmail(email) {
  const re = /^(([^<>()[\]\\.,;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
  return re.test(email);
}

function validate() {
  const $result = $("#result");
  const email = $("#email").val();
  $result.text("");

  if (validateEmail(email)) {
    $result.text(email + " is valid :)");
    $result.css("color", "green");
  } else {
    $result.text(email + " is not valid :(");
    $result.css("color", "red");
  }
  return false;
}

$("#validate").on("click", validate);
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

<form>
  <p>Enter an email address:</p>
  <input id='email'>
  <button type='submit' id='validate'>Validate!</button>
</form>

<h2 id='result'></h2>


576
Cette expression régulière élimine les e-mails valides en cours d'utilisation. Ne pas utiliser. Google pour "RFC822" ou "RFC2822" pour obtenir une expression régulière appropriée.
Randal Schwartz

42
Cela n'accepte même pas les exemples de la RFC 822. Dans certains cas simples, cela ne correspond pas à a \ @ b @ c.com, a(b)@c.com. Voir le RFC pour plus. Voici une expression régulière qui ne rejettera aucune adresse valide [^ @] + @ [^ @] + \. [^ @] + Et protège contre les erreurs courantes.
Vroo

126
@GoodPerson J'ai juste essayé d'envoyer un e-mail à n @ ai pour lui dire qu'il a une adresse e-mail sympa. Mais hélas, gmail ne m'a pas laissé faire. Je soupçonne que celui qui a de plus gros problèmes de communication avec les autres par e-mail que la validation javascript de mon site! Mais merci d'avoir relevé le défi.
Ben Roberts

26
C'est une solution qui semble bonne avec la plupart des anglophones natifs, mais elle échoue au test de Turquie (voir Joel Spolsky). La plupart des lettres Unicode sont autorisées, et par exemple en Argentine, des adresses telles que "ñoñó1234@server.com" sont parfaitement normales. joelonsoftware.com/articles/Unicode.html
oligofren

139
Vous ne pouvez pas valider les adresses e-mail, point final. Le seul qui peut valider une adresse e-mail est le fournisseur de l'adresse e-mail. Par exemple, cette réponse indique que ces adresses électroniques %2@gmail.com, "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, _@gmail.com, 1@gmail.com , 1_example@something.gmail.comsont toutes valides, mais Gmail n'autorisera jamais aucune de ces adresses électroniques. Vous devez le faire en acceptant l'adresse e-mail et en envoyant un e-mail à cette adresse e-mail, avec un code / lien que l'utilisateur doit visiter pour confirmer la validité.
Kevin Fegan

830

J'ai légèrement modifié la réponse de Jaymon pour les personnes qui souhaitent une validation très simple sous la forme de:

anystring@anystring.anystring

L'expression régulière:

/\S+@\S+\.\S+/

Exemple de fonction JavaScript:

function validateEmail(email) 
    {
        var re = /\S+@\S+\.\S+/;
        return re.test(email);
    }
    
console.log(validateEmail('anystring@anystring.anystring'));


69
Vous pouvez implémenter quelque chose 20x aussi longtemps qui pourrait causer des problèmes à quelques utilisateurs et ne pas être valide à l'avenir, ou vous pouvez récupérer la version d'ImmortalFirefly pour vous assurer qu'ils font au moins l'effort de la rendre réelle. Selon votre application, il est plus probable que quelqu'un tombe en colère parce que vous n'acceptez pas son e-mail non conventionnel, plutôt que quelqu'un qui cause des problèmes en entrant des adresses e-mail qui n'existent pas vraiment (ce qu'il peut faire de toute façon en entrant une adresse e-mail RFC2822 100% valide mais en utilisant un nom d'utilisateur ou un domaine non enregistré). A voté!
user83358

82
@ImmortalFirefly, l'expression régulière que vous avez fournie correspondra réellement name@again@example.com. Essayez de coller votre ligne dans une console JavaScript. Je crois que votre intention était de ne faire correspondre que le texte entier, ce qui nécessiterait le début du texte «^» et la fin du texte «$». Celui que j'utilise est/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com')
OregonTrail

8
Sur la base de cette validation, cet e-mail est valide: check @ this..com
Ehsan

4
Hm. Wikipedia dit que "very.unusual.@.unusual.com"@example.comc'est une adresse e-mail valide. /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('"very.unusual.@.unusual.com"@example.com') // false. Oops.
Bacon Bits

3
Cela ne le permet-il pas également @@@.@? : D
hfossli

763

Juste pour être complet, vous avez ici une autre expression régulière conforme à la RFC 2822

La norme officielle est connue sous le nom de RFC 2822 . Il décrit la syntaxe à laquelle les adresses e-mail valides doivent adhérer. Vous pouvez ( mais vous ne devriez pas - lire la suite ) l'implémenter avec cette expression régulière:

(?:[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])+)\])

(...) Nous obtenons une implémentation plus pratique de RFC 2822 si nous omettons la syntaxe en utilisant des guillemets doubles et des crochets. Il correspondra toujours à 99,99% de toutes les adresses e-mail actuellement utilisées.

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

Une autre modification que vous pourriez apporter consiste à autoriser tout domaine de premier niveau de code de pays à deux lettres, et uniquement des domaines de premier niveau génériques spécifiques. Cette expression régulière filtre les adresses e-mail factices commeasdf@adsf.adsf . Vous devrez le mettre à jour à mesure que de nouveaux domaines de premier niveau seront ajoutés .

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[A-Z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum)\b

Ainsi, même en suivant les normes officielles, il y a encore des compromis à faire. Ne copiez pas aveuglément les expressions régulières des bibliothèques en ligne ou des forums de discussion. Testez-les toujours sur vos propres données et avec vos propres applications.

Emphase mine


84
NB: "En utilisation réelle aujourd'hui " peut avoir été valide lors de l'écriture du code, en 200x. Le code restera probablement en usage au-delà de cette année spécifique. (Si j'avais un sou pour chaque "meh, personne n'utilisera jamais un TLD à 4 + lettres sauf ceux spécifiques" que j'ai dû réparer, je pourrais accaparer le marché mondial du cuivre et du nickel;))
Piskvor a quitté le bâtiment en

7
Pour la mise en œuvre pratique de RFC 2822, la fin doit être légèrement modifiée pour empêcher les extensions de domaine à caractère unique. / [a-z0-9! # $% & '* + \ / =? ^ _ {|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_{|} ~ -] +) * @ (?: [a-z0-9] (?: [a-z0-9 -] * [a-z0-9])? \.) + [a-z0-9] [a-z0-9 -] * [a-z0-9] /
Farrell le

5
En outre, la première partie devrait être (?: [Az avec un A majuscule pour éviter les faux négatifs lorsqu'un utilisateur capitalise son adresse e-mail.
Don Rolling

9
@DonRolling Ne faites pas ça. Cela ne signifie pas seulement "A à Z, a à z", cela signifie également "[\] ^ _` "car ceux-ci sont entre " Z "et" a ". Utilisez \w, ou mieux, mettez simplement l'adresse e-mail en minuscules avant de faire quoi que ce soit avec, car c'est la convention de toute façon.
kirb

5
"Vous devrez le mettre à jour à mesure que de nouveaux domaines de premier niveau seront ajoutés." Eh bien, tant pis pour ça maintenant - il y a plus de 1500 TLD reconnus.
Nathan Osman

377

Wow, il y a beaucoup de complexité ici. Si tout ce que vous voulez faire est d'attraper les erreurs de syntaxe les plus évidentes, je ferais quelque chose comme ceci:

^\S+@\S+$

Il détecte généralement les erreurs les plus évidentes commises par l'utilisateur et garantit que le formulaire est en grande partie correct, c'est à cela que sert la validation JavaScript.


70
+1 car envoyer un e-mail et voir ce qui se passe est le seul véritable moyen sûr de valider une adresse e-mail, il n'est donc pas nécessaire de faire plus qu'une simple correspondance regex.
kommradHomer

20
Vous pouvez toujours rester simple, mais faites un peu plus pour vous assurer qu'il a un "." quelque part après le @ suivi uniquement de chiffres ou de chiffres, donc des choses comme moi @ ici, moi @ ici @ et moi @ herecom ne sont pas valides ... ^ \ S + @ \ S + [\.] [0-9a-z ] + $
Tim Franklin

14
Je pense que les adresses e-mail peuvent contenir des espaces. Il est probablement préférable d'utiliser.+@.+
Sam

11
/\S+@\S+/.test("áéíóúý@ÁÉÍÓÚÝð") true
gtournie

111
@gtournie Personne ne s'en soucie. Personne ne va entrer cela dans un champ de courrier électronique par accident , et c'est tout ce que la validation frontale est pour: Pour empêcher les gens d'entrer accidentellement le mauvais bit d'informations, comme leur nom, dans un champ de courrier électronique.
meagar

331

Il y a quelque chose que vous devez comprendre à la seconde où vous décidez d'utiliser une expression régulière pour valider les e-mails: ce n'est probablement pas une bonne idée . Une fois que vous avez accepté cela, il existe de nombreuses implémentations qui peuvent vous aider à mi-chemin, cet article les résume bien.

En bref, cependant, la seule façon d'être absolument, positivement sûr que ce que l'utilisateur a entré est en fait un e-mail est d'envoyer réellement un e-mail et de voir ce qui se passe. A part ça, tout n'est que suppositions.


112
-1 Pourquoi voudrais-je passer mon temps à valider une adresse e-mail qui ne passe même pas le contrôle regex?
kommradHomer

63
@kommradHomer - une adresse "regex invalide" est presque toujours valide, car la regex que vous utilisez pour valider une adresse e-mail est presque certainement fausse et exclura les adresses e-mail valides. Une adresse e-mail est name_part@domain_partet pratiquement tout, y compris un @, est valide dans le nom_partie; L'adresse foo@bar@machine.subdomain.example.museumest légale, même si elle doit être échappée comme foo\@bar@machine..... Une fois que l'e-mail atteint le domaine, par exemple "example.com", ce domaine peut acheminer le courrier "localement" afin que des noms d'utilisateur et des noms d'hôtes "étranges" puissent exister.
Stephen P

6
Le deuxième regex dans la réponse de voyager dans stackoverflow.com/a/1373724/69697 est pratique à utiliser et ne devrait presque pas avoir de faux négatifs. Je suis d'accord avec @kommradHomer ici - pourquoi envoyer un e-mail si vous n'êtes pas obligé? Je peux comprendre l'aversion réflexive pour les regex incompréhensibles et le désir de garder le code simple, mais ce sont quelques lignes de code qui peuvent sauver votre serveur beaucoup de problèmes en éliminant immédiatement les éléments définitivement invalides. Une expression régulière à elle seule est inutile, mais sert de bon complément à la validation côté serveur.
Ben Regenspan

6
@dmur Je concède que "presque toujours valide" le surestime probablement, mais mes adresses e-mail (parfaitement valides et fonctionnelles) ont été rejetées trop souvent par des sites Web, simplement parce que j'ai un .usdomaine ou parce que j'ai utilisé un +à gauche de le @- de nombreux endroits ont corrigé ces erreurs flagrantes, mais la partie locale (à gauche de @) peut être tout ce que le propriétaire du domaine veut. -> "foo@bar.com"@example.com <- est une adresse e-mail valide.
Stephen P

8
@kommradHomer "Une adresse non valide d'expression régulière est% 100 une adresse non valide." Je suis désolé ... excusez-moi? Savez-vous combien de fois on m'a dit que foo+bar@gmail.com N'EST PAS un e-mail valide alors qu'en fait IL EST PARFAITEMENT VALABLE?! Votre logique est EXTRÊMEMENT défectueuse. J'ai envoyé des formulaires avec des e-mails en tant que tels: thisisafakeemailbutitwillpassyourstupidregexcheck@regexchecksareretarded.com Et devinez quoi? Cela passe le contrôle REGEX ... mais ce n'est PAS un e-mail valide (bien que techniquement c'est le cas, mais je vous promets qu'il n'existe pas ... mais se gratte le menton ). Comme beaucoup l'ont dit, C'EST UNE MAUVAISE IDÉE ....
Soundfx4

211

HTML5 lui-même a une validation par e-mail. Si votre navigateur prend en charge HTML5, vous pouvez utiliser le code suivant.

<form><input type="email" placeholder="me@example.com" required>
    <input type="submit">
</form>

jsFiddleLien

De la spécification HTML5 :

Une adresse de messagerie valide est une chaîne qui correspond à la emailproduction de l'ABNF suivant, dont le jeu de caractères est Unicode.

email   = 1*( atext / "." ) "@" label *( "." label )
label   = let-dig [ [ ldh-str ] let-dig ]  ; limited to a length of 63 characters by RFC 1034 section 3.5
atext   = < as defined in RFC 5322 section 3.2.3 >
let-dig = < as defined in RFC 1034 section 3.5 >
ldh-str = < as defined in RFC 1034 section 3.5 >

Cette exigence est un violation délibérée de la RFC 5322, qui définit une syntaxe pour les adresses électroniques qui est à la fois trop stricte (avant le caractère "@"), trop vague (après le caractère "@") et trop laxiste (autorisant les commentaires , les espaces blancs et les chaînes entre guillemets d'une manière que la plupart des utilisateurs ne connaissent pas) pour être utiles ici.

L'expression régulière compatible JavaScript et Perl suivante est une implémentation de la définition ci-dessus.

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

29
c'est bien, mais le problème c'est qu'il doit être à l'intérieur d'un formtag et soumis par une submitentrée, ce que tout le monde n'a pas le luxe de faire. De plus, vous ne pouvez pas vraiment styliser le message d'erreur.
Jason

3
J'ai ajouté une réponse ci-dessous qui vous libère du formulaire et de la soumettre. Mais oui, les navigateurs n'appliquent généralement qu'une vérification de plausibilité et non une validation RFC 822 complète.
Boldewyn

8
@ br1: ce n'est pas invalide simplement parce qu'il n'y a pas de domaine de niveau supérieur «a». si votre intranet a une résolution vers une IP?
mouton volant

7
Le type de champ de messagerie html5 accepte les e-mails comme user @ email
Puce

1
Remarque du commentaire de @ Puce: l'entrée de courrier électronique HTML 5 accepte user@emailalors que, par exemple, PHP filter_varne le fait pas. Cela pourrait provoquer des problèmes.
texelate

136

J'ai trouvé que c'était la meilleure solution:

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

Il permet les formats suivants:

1. prettyandsimple@example.com
2. very.common@example.com
3. jetable.style.email.with+symbol@example.com
4. other.email-with-dash@example.com
9. #!$%&'*+-/=?^_`{}|~@example.org
6. "() []:,; @ \\\"! # $% & '* + - / =? ^ _ `{} | ~ .a "@ example.org
7. "" @ example.org (espace entre les guillemets)
8. üñîçøðé@example.com (caractères Unicode dans la partie locale)
9. üñîçøðé@üñîçøðé.com (caractères Unicode dans la partie domaine)
10. Pelé@example.com (latin)
11. δοκιμή@παράδειγμα.δοκιμή (grec)
12. 我 買 @ 屋企. 香港 (chinois)
13. 甲 斐 @ 黒 川. 日本 (japonais)
14. чебурашка@ящик-с-апельсинами.рф (cyrillique)

Il est clairement polyvalent et autorise les personnages internationaux très importants, tout en appliquant le format de base everything@anything.anything. Cela bloquera les espaces qui sont techniquement autorisés par RFC, mais ils sont si rares que je suis heureux de le faire.


9
C'est exactement ce que je fais. Toutes ces réponses "compliquées" génèrent des problèmes: soit elles n'autorisent pas les IDN puny-code, soit elles utilisent un ensemble fixe de TLD, soit elles limitent inutilement l'utilisateur à ne pas utiliser de caractères comme [@ çµ.ö dans leur préfixe email (avant @) ou nom de domaine. JavaScript en frontend (pas pour l'utilisation de cause par le backend) n'est pas suffisant pour valider pour des raisons de sécurité. Alors pourquoi ne pas simplement aider l'utilisateur à éviter les fautes de frappe de base. Les fautes de frappe de base sont: oublier le TLD ou le préfixe utilisateur (avant @) ou la partie de domaine ou le type erroné @comme .(ou vice versa). Il faut bien sûr être beaucoup plus restrictif côté serveur.
Hafenkranich

Pour des raisons étranges, username@domain.comcela ne fonctionne pas avec ce modèle
einstein

2
Selon votre expression régulière "_.............. kamal@gmail.com" est valide, ce qui ne devrait pas l'être!
Kamal Nayan

1
Voici le RegEx indiqué avec des exemples, si vous souhaitez bricoler avec cette solution: regex101.com/r/AzzGQU/2
ryanm

7
Cette expression régulière est correcte. Si quelqu'un entre son e-mail comme ça, a@b@c@d.x.y.@.zalors peut-être qu'il mérite de passer un mauvais moment? : D
corysimmons

94

Dans les navigateurs modernes, vous pouvez vous appuyer sur la réponse de @ Sushil avec du JavaScript pur et le DOM :

function validateEmail(value) {
  var input = document.createElement('input');

  input.type = 'email';
  input.required = true;
  input.value = value;

  return typeof input.checkValidity === 'function' ? input.checkValidity() : /\S+@\S+\.\S+/.test(value);
}

J'ai rassemblé un exemple dans le violon http://jsfiddle.net/boldewyn/2b6d5/ . Combiné avec la détection des fonctionnalités et la validation à nu de Squirtle's Answer , il vous libère du massacre d'expression régulière et ne fonctionne pas sur les anciens navigateurs.


4
C'est une idée intelligente pour résoudre le problème, mais cela ne fonctionne pas car les navigateurs ont également une validation merdique. Par exemple, .@avalide comme truedans les versions actuelles de Chrome, Firefox et Safari.
Hank

13
@HenryJackson Malheureusement, dans ce cas, oui. En effet, selon le RFC, il s'agit d'une adresse e-mail valide (pensez aux intranets). Les navigateurs seraient grillés s'ils valident trop étroitement et produisent de faux négatifs.
Boldewyn

3
Mis à jour pour contenir la détection des fonctionnalités et une dégradation gracieuse, il ne se casse plus sur les nouveaux navigateurs mais utilise les expressions rationnelles que vous aimez.
Ronny

Belle solution. Malheureusement, ce n'est que pour HTML5 +.
Edward Olamisan,

3
C'est de loin la meilleure solution à la question d'origine. Oui, il utilise HTML5, mais la majorité des applications qui nécessitent ce niveau de précision s'appuieront sûrement déjà sur HTML5 d'une autre manière, donc point discutable. Il nous est impossible de déterminer si l'e-mail de quelqu'un est valide sans le faire vérifier de toute façon, nous ne devrions donc pas investir autant de temps ou d'efforts pour le valider. Une vérification rapide de toute syntaxe évidente ou tentative de méchanceté est tout l'effort que nous devons déployer.
Woody Payne

69

Il s'agit de la bonne version du RFC822.

function checkEmail(emailAddress) {
  var sQtext = '[^\\x0d\\x22\\x5c\\x80-\\xff]';
  var sDtext = '[^\\x0d\\x5b-\\x5d\\x80-\\xff]';
  var sAtom = '[^\\x00-\\x20\\x22\\x28\\x29\\x2c\\x2e\\x3a-\\x3c\\x3e\\x40\\x5b-\\x5d\\x7f-\\xff]+';
  var sQuotedPair = '\\x5c[\\x00-\\x7f]';
  var sDomainLiteral = '\\x5b(' + sDtext + '|' + sQuotedPair + ')*\\x5d';
  var sQuotedString = '\\x22(' + sQtext + '|' + sQuotedPair + ')*\\x22';
  var sDomain_ref = sAtom;
  var sSubDomain = '(' + sDomain_ref + '|' + sDomainLiteral + ')';
  var sWord = '(' + sAtom + '|' + sQuotedString + ')';
  var sDomain = sSubDomain + '(\\x2e' + sSubDomain + ')*';
  var sLocalPart = sWord + '(\\x2e' + sWord + ')*';
  var sAddrSpec = sLocalPart + '\\x40' + sDomain; // complete RFC822 email address spec
  var sValidEmail = '^' + sAddrSpec + '$'; // as whole string

  var reValidEmail = new RegExp(sValidEmail);

  return reValidEmail.test(emailAddress);
}

Les adresses IDN ne sont pas validées (info@üpöü.com)
DAH

66

JavaScript peut correspondre à une expression régulière:

emailAddress.match( / some_regex /);

Voici une expression régulière RFC22 pour les e-mails:

^((?>[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+\x20*|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*
"\x20*)*(?<angle><))?((?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+)+|"((?=[\x01-\x
7f])[^"\\]|\\[\x01-\x7f])*")@(((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}|\[(((?(?<
!\[)\.)(25[0-5]|2[0-4]\d|[01]?\d?\d)){4}|[a-zA-Z\d\-]*[a-zA-Z\d]:((?=[\x01-\x7f])
[^\\\[\]]|\\[\x01-\x7f])+)\])(?(angle)>)$

1
@Kato: Il utilise des extensions incompatibles, notamment (?>pour arrêter le retour en arrière et (?<angle><)…(?(angle)>)éviter de fournir une longue |.
Ry-

60

Toutes les adresses e-mail contiennent un symbole «at» (c'est-à-dire @). Testez cette condition nécessaire:

email.indexOf("@") > 0

Ne vous embêtez pas avec quelque chose de plus compliqué. Même si vous pouviez parfaitement déterminer si un e-mail est RFC-syntaxiquement valide, cela ne vous dirait pas s'il appartient à la personne qui l'a fourni. C'est ça qui compte vraiment.

Pour tester cela, envoyez un message de validation.


3
et s'il y aura plus d'un symbole '@'? d'autres symboles restreints? Cette validation n'est pas digne de confiance ...
eatmypants

56

Une validation correcte de l'adresse e-mail conformément aux RFC n'est pas quelque chose qui peut être obtenu avec une expression régulière à une ligne. Un article avec la meilleure solution que j'ai trouvée en PHP est Qu'est-ce qu'une adresse e-mail valide? . De toute évidence, il a été porté sur Java. Je pense que la fonction est trop complexe pour être portée et utilisée en JavaScript. Port JavaScript / node.js: https://www.npmjs.com/package/email-addresses .

Une bonne pratique consiste à valider vos données sur le client, mais revérifiez la validation sur le serveur. Dans cet esprit, vous pouvez simplement vérifier si une chaîne ressemble à une adresse e-mail valide sur le client et effectuer une vérification stricte sur le serveur.

Voici la fonction JavaScript que j'utilise pour vérifier si une chaîne ressemble à une adresse e-mail valide:

function looksLikeMail(str) {
    var lastAtPos = str.lastIndexOf('@');
    var lastDotPos = str.lastIndexOf('.');
    return (lastAtPos < lastDotPos && lastAtPos > 0 && str.indexOf('@@') == -1 && lastDotPos > 2 && (str.length - lastDotPos) > 2);
}

Explication:

  • lastAtPos < lastDotPos: Last @devrait être avant last .car @ne peut pas faire partie du nom du serveur (pour autant que je sache).

  • lastAtPos > 0: Il doit y avoir quelque chose (le nom d'utilisateur de l'e-mail) avant le dernier @.

  • str.indexOf('@@') == -1: Il ne devrait pas y avoir d' @@adresse. Même s'il @apparaît comme le dernier caractère du nom d'utilisateur de l'e-mail, il doit être cité, il "devrait donc être compris entre celui-ci @et le dernier @de l'adresse.

  • lastDotPos > 2: Il doit y avoir au moins trois caractères avant le dernier point, par exemple a@b.com.

  • (str.length - lastDotPos) > 2: Il doit y avoir suffisamment de caractères après le dernier point pour former un domaine à deux caractères. Je ne sais pas si les crochets sont nécessaires.


Ce fn a l'air sympa, mais est-il meilleur que l'expression régulière écrite dans la réponse du haut?
Atul Goyal le

4
J'en doute. Je l'utilise uniquement pour vérifier si une chaîne ressemble à un e-mail et laisser les détails au code côté serveur.
Miloš Rašić

Il valide OK toute chaîne comme 'aaaa', c'est-à-dire sans '@' et '.'
Gennady Shumakher

1
Ça ne devrait pas. lastIndexOf () devrait retourner -1 s'il ne trouve pas l'aiguille.
Miloš Rašić

"Même s'il @apparaît comme le dernier caractère dans le nom d'utilisateur de l'e-mail, il doit être cité de sorte "qu'il se situe entre cela @et le dernier @de l'adresse." Et alors "@@"@example.com?
Ry-

47

Cela a été volé à http://codesnippets.joyent.com/posts/show/1917

email = $('email');
filter = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/;
if (filter.test(email.value)) {
  // Yay! valid
  return true;
}
else
  {return false;}

7
Cela filtre les domaines .museumet les .traveldomaines toujours populaires (en raison de la limite de 4 caractères après .)
bobobobo

4
Changer {2,4} en {2,6} ne sera pas un problème
Anton N

11
@Anton N: Il a également environ un gazillion d'autres problèmes; la finale {2,4}n'est qu'un indicateur utile de celle-ci (comme dans «quand vous voyez cette erreur, d'autres sont susceptibles d'être autour»). Le plus fondamental est le manque de +local; cette zone de commentaire est trop petite pour signaler toutes les erreurs commises ci-dessus.
Piskvor a quitté le bâtiment le

37
Pourquoi tu ne peux pas faire ça return filter.test(email.value);?
MT.

3
@AntonN: Nous avons maintenant plus de 10 TLD de caractères ( xn--clchc0ea0b2g2a9gcd). Toujours pas un problème?
Piskvor a quitté le bâtiment le

42

Faites ceci:

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

Pourquoi? Il est basé sur la RFC 2822 , qui est une norme à laquelle TOUTES les adresses électroniques DOIVENT adhérer. Et je ne sais pas pourquoi vous vous embêtez avec quelque chose de "plus simple" ... vous allez quand même le copier et le coller;)

Souvent, lorsque je stocke des adresses e-mail dans la base de données, je les mets en minuscules et, dans la pratique, les expressions régulières peuvent généralement être marquées insensibles à la casse. Dans ces cas, cela est légèrement plus court:

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

Voici un exemple de son utilisation en JavaScript (avec le drapeau insensible ià la casse à la fin).

var emailCheck=/^[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?$/i;
console.log( emailCheck.test('some.body@domain.co.uk') );

Remarque :
Techniquement, certains e-mails peuvent inclure des guillemets dans la section précédant le @symbole avec des caractères d'échappement à l'intérieur des guillemets (de sorte que votre utilisateur de messagerie peut être désagréable et contenir des éléments comme @et "..."tant qu'il est écrit entre guillemets). PERSONNE NE LE FAIT JAMAIS! C'est obsolète. Mais, il est inclus dans la vraie norme RFC 2822 et omis ici.

Plus d'informations: http://www.regular-expressions.info/email.html


@Kondal le code javascript n'est pas sensible à la casse à cause du /idrapeau à la fin de l'expression régulière. Je mentionne le fait qu'il doit être une comparaison insensible à la casse, mais je vais le dire plus clairement.
Ryan Taylor

A travaillé pour moi comme un charme
Alex

40

J'ai vraiment hâte de résoudre ce problème. J'ai donc modifié l'expression régulière de validation des e-mails ci-dessus

  • Original
    /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

  • Modifié
    /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()\.,;\s@\"]+\.{0,1})+[^<>()\.,;:\s@\"]{2,})$/

passer les exemples l'adresse e-mail Wikipedia .

Et vous pouvez voir le résultat ici .

entrez la description de l'image ici


Cela semble être une bonne solution, cela fonctionne également avec les nouveaux TLD et les e-mails à 1 lettre
Mark Hughes

Pourquoi john..doe@example.comne devrait pas être correct? C'est une valise d'angle valide.
Valerio Bozz

24

Vous ne devez pas utiliser d'expressions régulières pour valider une chaîne d'entrée pour vérifier s'il s'agit d'un e-mail. C'est trop compliqué et ne couvrirait pas tous les cas.

Maintenant que vous ne pouvez couvrir que 90% des cas, écrivez quelque chose comme:

function isPossiblyValidEmail(txt) {
   return txt.length > 5 && txt.indexOf('@')>0;
}

Vous pouvez l'affiner. Par exemple, «aaa @» est valide. Mais dans l'ensemble, vous obtenez l'essentiel. Et ne vous laissez pas emporter ... Une solution simple à 90% vaut mieux qu'une solution à 100% qui ne fonctionne pas.

Le monde a besoin d'un code plus simple ...


15
Cela permet de saisir autant d'adresses e-mail invalides que ce sont des conseils inutiles.
cazlab

3
Il ne doit pas du tout être impossible de déboguer. Il existe de nombreux exemples fins dans ce fil qui valident plus loin que "a-t-il un '@' dedans. Votre exemple permet à" u @ "d'être considéré comme une adresse e-mail valide. Évaluez au moins s'il existe un domaine ou quelque chose qui pourrait être un domaine. Le vôtre est un exemple de ce que j'appellerais "un codage agressivement paresseux." Je ne sais pas pourquoi vous le
défendez

3
@cazlab vous avez peut-être raison. Après tout, j'ai été rejeté. Contrairement à vous, je ne pense pas que le code ci-dessus montre des extraits de code faciles à déboguer. Mon approche «agressivement paresseuse» peut au moins être améliorée si nécessaire.
Zo72

3
En quoi est-ce différent de l'utilisation de regex? (.+)@(.*)fait la même chose, et plus court.
snostorm

4
+1 - Si l'objectif est de s'assurer que l'utilisateur a au moins tenté de saisir une adresse e-mail, vérifier s'il peut être déterminé que l'adresse e-mail n'est certainement PAS un e-mail est un excellente solution. Un bon exemple serait si vous voulez que le nom d'utilisateur d'une personne soit une adresse e-mail. Si l'utilisateur tape «sexy_chick_23», alors cette expression régulière peut être utilisée pour lui indiquer qu'un e-mail est attendu. Si quelque chose est tapé qui ressemble à un e-mail, mais ne l'est pas, l'utilisateur ne recevra jamais l'e-mail de «confirmation» et le processus d'inscription ne sera jamais validé.
Chris Dutrow

23

Vérifiez simplement si l'adresse e-mail saisie est valide ou n'utilise pas HTML.

<input type="email"/>

Il n'est pas nécessaire d'écrire une fonction pour la validation.


4
IE <10 ne le prend pas en charge, pas plus que le propre navigateur d'Android.
Frank Conijn

7
Upvoting. IE <10 est mort.
Michael Scheper

19

Il est difficile d'obtenir un validateur d'e-mails 100% correct. Le seul véritable moyen de le corriger serait d'envoyer un e-mail de test au compte. Cela dit, il existe quelques vérifications de base qui peuvent vous aider à vous assurer que vous obtenez quelque chose de raisonnable.

Quelques points à améliorer:

Au lieu de nouveau RegExp, essayez simplement d'écrire le regexptexte comme ceci:

if (reg.test(/@/))

Ensuite, vérifiez qu'un point vient après le @signe et assurez-vous qu'il y a des caractères entre le @s et le point.


19

Voici comment le validateur de nœuds le fait:

/^(?:[\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])\]))$/

14

Utilisez ce code dans votre fonction de validation:

var emailID = document.forms["formName"]["form element id"].value;
atpos = emailID.indexOf("@");
dotpos = emailID.lastIndexOf(".");
if (atpos < 1 || ( dotpos - atpos < 2 ))
{
    alert("Please enter correct email ID")
    return false;
}

Sinon, vous pouvez utiliser jQuery . Les règles internes définissent:

eMailId: {
    required: true,
    email: true
}

1
abc@xyzest un e-mail parfaitement valide qui n'est pas reconnu par votre expression régulière.
Toto

3
Non ce n'est pas. Le modèle d'e-mail correct est quelque chose@something.something, abc @ xyz ne correspond pas à ce modèle. Donc, ce n'est pas une adresse valide.
Orchid


5
Avez-vous la page wikipedia? Un TLD est un nom d'hôte valide. Il en abc@tldva de même pour une adresse e-mail valide.
Toto

2
La seule façon de valider une adresse e-mail est d'envoyer un e-mail puis d'attendre la réponse. En dehors de cela, voici une URL où vous pouvez tester si votre adresse est conforme à RFC822 : mythic-beasts.com/~pdw/cgi-bin/emailvalidate . Vous pouvez voir que abc @ xyz est une adresse valide pour RFC822.
Toto

14

Mise à jour Regex 2018! essaye ça

let val = 'email@domain.com';
if(/^[a-z0-9][a-z0-9-_\.]+@([a-z]|[a-z0-9]?[a-z0-9-]+[a-z0-9])\.[a-z0-9]{2,10}(?:\.[a-z]{2,10})?$/.test(val)) {
   console.log('passed');
}

version dactylographiée terminée

//
export const emailValid = (val:string):boolean => /^[a-z0-9][a-z0-9-_\.]+@([a-z]|[a-z0-9]?[a-z0-9-]+[a-z0-9])\.[a-z0-9]{2,10}(?:\.[a-z]{2,10})?$/.test(val);

plus d'informations https://git.io/vhEfc


Cela a échoué pour un email@domain.com standard
ricks

1
@RickS, ce n'est tout simplement pas vrai. Veuillez vérifier à nouveau
malimo

13

Une solution qui ne vérifie pas l'existence du TLD est incomplète.

Presque toutes les réponses à ces questions suggèrent d'utiliser Regex pour valider les adresses e-mail. Je pense que Regex n'est bon que pour une validation rudimentaire. Il semble que la vérification de la validation des adresses e-mail soit en fait deux problèmes distincts:

1- Validation du format de l'e-mail: S'assurer que l'e-mail est conforme au format et au modèle des e-mails dans la RFC 5322 et si le TLD existe réellement. Une liste de tous les TLD valides peut être trouvée ici .

Par exemple, bien que l'adresse example@example.cccpasse le regex, ce n'est pas un e-mail valide, car ce cccn'est pas un domaine de premier niveau par IANA.

2- S'assurer que l'e-mail existe réellement: Pour ce faire, la seule option est d'envoyer un e-mail aux utilisateurs .


13

Regex pour la validation de l'adresse e-mail

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

Je ne vois pas votre expression rationnelle dans RFC5322: tools.ietf.org/html/rfc5322 - il y a une erreur?
Kamil Kiełczewski

"Le meilleur regex de tous les temps"? Peut-être une sorte d'explication ici?
connectyourcharger le

Pourquoi avez-vous dit que c'était la meilleure solution de toutes, pouvez-vous expliquer un peu plus s'il vous plaît?
nancoder

Je ne peux pas me rappeler pourquoi j'ai écrit "le meilleur regex jamais". Désolé les gars si cela vous dérange.
Prabhat Kasera

12

Voici une très bonne discussion sur l'utilisation des expressions régulières pour valider les adresses e-mail; " Comparaison des adresses e-mail de validation des expressions régulières "

Voici l'expression top actuelle, compatible JavaScript, à des fins de référence:

/^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+)*\.(aero|arpa|biz|com|coop|edu|gov|info|int|mil|museum|name|net|org|pro|travel|mobi|[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i

9
-1 La liste blanche laisse beaucoup à désirer - notamment, vous avez raté .jobs. En outre, il existe des IDN en direct (dont la plupart, je l'avoue, n'ont été officiellement approuvés qu'après votre poste - par exemple .中國en juin 2010; mais la plupart sont en préparation depuis des années).
Piskvor a quitté le bâtiment le

2
-1 n'utilise pas de domaines de premier niveau constants. Il pourrait toujours y avoir (et il y aura par exemple 2013) de nouveaux tld.
miho

Il y a des centaines de nouveaux TLD confirmés. Cette réponse n'est pas valide et ne doit jamais être utilisée.
Dean Meehan

Ouaip. Je l'ai dit en 2011, et je le répète: une liste blanche de domaines "spéciaux" ne fera qu'empirer avec le temps, car plus de TLD sont approuvés. Il y a plus de 100 TLD complètement valides ne correspondant pas à la liste blanche ci-dessus: en.wikipedia.org/wiki/List_of_Internet_top-level_domains
Piskvor a quitté le bâtiment le

Nous sommes en 2015. Votre expression n'est pas pratique. Vous devriez prendre cette réponse, mais vous êtes probablement trop occupé à corriger toutes les pages sur lesquelles vous mettez cette expression. Droite?
Eric Leroy


12

Contrairement à Squirtle , voici une solution complexe, mais elle fait un excellent travail de validation correcte des e-mails:

function isEmail(email) { 
    return /^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))$/i.test(email);
} 

Utilisez comme ça:

if (isEmail('youremail@yourdomain.com')){ console.log('This is email is valid'); }

10
Vous n'avez pas besoin de == truesur votre exemple.
Luke Alderton

11

Ma connaissance des expressions régulières n'est pas très bonne. C'est pourquoi je vérifie d'abord la syntaxe générale avec une simple expression régulière et vérifie ensuite des options plus spécifiques avec d'autres fonctions. Ce n'est peut-être pas la meilleure solution technique, mais de cette façon, je suis beaucoup plus flexible et plus rapide.

Les erreurs les plus courantes que j'ai rencontrées sont des espaces (en particulier au début et à la fin) et parfois un double point.

function check_email(val){
    if(!val.match(/\S+@\S+\.\S+/)){ // Jaymon's / Squirtle's solution
        // Do something
        return false;
    }
    if( val.indexOf(' ')!=-1 || val.indexOf('..')!=-1){
        // Do something
        return false;
    }
    return true;
}

check_email('check@thiscom'); // Returns false
check_email('check@this..com'); // Returns false
check_email(' check@this.com'); // Returns false
check_email('check@this.com'); // Returns true

10
<form name="validation" onSubmit="return checkbae()">
    Please input a valid email address:<br />

    <input type="text" size=18 name="emailcheck">
    <input type="submit" value="Submit">
</form>

<script language="JavaScript1.2">
    var testresults
    function checkemail(){
        var str = document.validation.emailcheck.value
        var filter = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i
        if (filter.test(str))
            testresults = true
        else {
            alert("Please input a valid email address!")
            testresults = false
        }
        return (testresults)
    }
</script>

<script>
    function checkbae(){
        if (document.layers || document.getElementById || document.all)
            return checkemail()
        else
            return true
    }
</script>

Peut-être que si vous avez ajouté une explication ou une description pour l'accompagner? Je ne pense pas que vous ayez vraiment besoin de montrer du html; tout le monde est concerné par le javascript et l'expression régulière. Si vous réduisez votre réponse au simple JavaScript et ajoutez un petit texte descriptif pour l'accompagner, je vous donnerai un vote positif.
bgmCoder

9

Je cherchais une Regex dans JS qui passe tous les cas de test d'adresse e-mail:

  • email@example.com Email valide

  • firstname.lastname@example.com L'email contient un point dans le champ d'adresse

  • email@subdomain.example.com L'e-mail contient un point avec un sous-domaine

  • firstname+lastname@example.com Le signe plus est considéré comme un caractère valide

  • email@192.0.2.123 Le domaine est une adresse IP valide

  • email@[192.0.2.123] Le crochet autour de l'adresse IP est considéré comme valide

  • “email”@example.com Les citations concernant le courrier électronique sont considérées comme valides

  • 1234567890@example.com Les chiffres de l'adresse sont valides

  • email@domain-one.example Le tiret dans le nom de domaine est valide

  • _______@example.com Le soulignement dans le champ d'adresse est valide

  • email@example.name .name est un nom de domaine de premier niveau valide

  • email@example.co.jpLe point dans le nom de domaine de premier niveau est également considéré comme valide (en utilisant co.jpcomme exemple ici)

  • firstname-lastname@example.com Le tiret dans le champ d'adresse est valide

Et c'est parti :

http://regexr.com/3f07j

OU regex:

Regex = /(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@[*[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+]*/

8

L'expression régulière fournie par Microsoft dans ASP.NET MVC est

/^[\w-]+(\.[\w-]+)*@([a-z0-9-]+(\.[a-z0-9-]+)*?\.[a-z]{2,6}|(\d{1,3}\.){3}\d{1,3})(:\d{4})?$/

Ce que je poste ici au cas où il serait défectueux - bien qu'il ait toujours été parfait pour mes besoins.


1
Ne permet pas les + dans la partie nom de l'e-mail.
Paul Go
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.