Como validar um endereço de email em JavaScript


4377

Existe uma expressão regular para validar um endereço de email em JavaScript?



60
acerte isso, muitos sites não gostam do meu endereço de e-mail "firstName@secondName.name", nem todos os domínios de nível superior terminam com 2 ou 3 letras.
21811 Ian Ringrose

41
Qualquer suporte para o uso de regex verifica e-mails contra os quais sou 100%. Estou cansado de saber que meu endereço de email "foo+bar@gmail.com" é inválido. A melhor opção é pedir ao usuário que digite seu e-mail duas vezes e se você DEVE usar um verificador de regex, informe ao usuário que seu endereço de e-mail não parece ser válido e pergunte se ele tem certeza de que o digitou. direita. Vá até o ponto de apontar O QUE não fez check-out na verificação do regexp, mas NÃO os impeça de enviar o formulário.
Soundfx4

17
@ Soundfx4: esta deve ser a resposta e aceita como tal. Testar a correção de um endereço é uma coisa boba de se fazer - a melhor maneira de frustrar os clientes. I solicitar o endereço a ser digitado duas vezes e indício de que há algumas questões possíveis (falta @, ;cometc.) e permitir que o usuário corrigi-los se quiserem (e aceitar o que eles me mandam)
woj

4
Eu concordo totalmente com a resposta dada pelo WoJ. O formato de um endereço de email válido é muito complexo para ser verificado com uma simples expressão regular. A única maneira de ter certeza de que o endereço é válido é testá-lo.
Nicole

Respostas:


4946

Usar expressões regulares é provavelmente o melhor caminho. Você pode ver vários testes aqui (extraídos do cromo )

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());
}

Aqui está o exemplo de expressão regular que aceita unicode:

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

Mas lembre-se de que não se deve confiar apenas na validação do JavaScript. JavaScript pode ser facilmente desativado. Isso também deve ser validado no servidor.

Aqui está um exemplo do acima em ação:

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>


575
Essa expressão regular elimina e-mails válidos em uso. Não use. Google para "RFC822" ou "RFC2822" para obter uma regex adequada.
Randal Schwartz

42
Isso nem aceita os exemplos do RFC 822. Em alguns casos simples, ele não corresponde a a \ @ b @ c.com, a(b)@c.com. Veja o RFC para mais. Aqui está um regex que não rejeita endereços válidos [^ @] + @ [^ @] + \. [^ @] + E protege contra erros comuns.
Vroo

126
@ GoodPerson Eu apenas tentei enviar um e-mail para n @ ai para lhe dizer que eles têm um endereço de e-mail legal. Mas, infelizmente, o Gmail não me deixou. Eu suspeito que quem quer que seja tenha maiores problemas de comunicação com outras pessoas por e-mail do que apenas a validação javascript do meu site! Mas obrigado por enfrentar o desafio.
Ben Roberts

26
Essa é uma solução que parece boa para a maioria dos falantes nativos de inglês, mas falha no teste da Turquia (consulte Joel Spolsky). A maioria das letras unicode é permitida e, por exemplo, na Argentina, endereços como "ñoñó1234@server.com" são perfeitamente normais. joelonsoftware.com/articles/Unicode.html
oligofren

139
Você não pode validar endereços de email, ponto final. O único que pode validar um endereço de email é o provedor do endereço de email. Por exemplo, esta resposta diz os seguintes endereços de email: %2@gmail.com, "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, _@gmail.com, 1@gmail.com , 1_example@something.gmail.comtodos são válidos, mas o Gmail nunca permitirá nenhum desses endereços de email. Você deve fazer isso aceitando o endereço de e-mail e enviando uma mensagem para esse endereço de e-mail, com um código / link que o usuário deve visitar para confirmar a validade.
9118 Kevin Fegan

830

Modifiquei levemente a resposta de Jaymon para pessoas que desejam uma validação realmente simples na forma de:

anystring@anystring.anystring

A expressão regular:

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

Exemplo de função JavaScript:

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


69
Você pode implementar algo 20x, desde que possa causar problemas para alguns usuários e não ser válido no futuro, ou pode pegar a versão do ImmortalFirefly para garantir que eles pelo menos se esforcem para torná-la real. Dependendo do seu aplicativo, é mais provável que alguém se irrite porque você não aceita o email não convencional, em vez de alguém que causa problemas ao inserir endereços de email que realmente não existem (o que eles podem fazer de qualquer maneira, digitando um endereço de e-mail RFC2822 100% válido, mas usando um nome de usuário ou domínio não registrado). Voto a favor!
user83358

82
@ImmortalFirefly, o regex que você forneceu realmente corresponderá name@again@example.com. Tente colar sua linha em um console JavaScript. Acredito que sua intenção era corresponder apenas ao texto inteiro, o que exigiria o início do texto '^' e o final do texto '$'. O que eu estou usando é/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com')
OregonTrail

8
Com base nessa validação, este e-mail é válido: check @ this..com
Ehsan

4
Hum. A Wikipedia diz que esse "very.unusual.@.unusual.com"@example.comé um endereço de email válido. /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('"very.unusual.@.unusual.com"@example.com') // false. Opa
Bacon Bits

3
Isso também não permite @@@.@? : D
hfossli

763

Apenas para completar, aqui você tem outro regex compatível com RFC 2822

O padrão oficial é conhecido como RFC 2822 . Ele descreve a sintaxe que os endereços de email válidos devem aderir. Você pode ( mas não deve - continue a ler ) implementá-lo com esta expressão regular:

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

(...) Obteremos uma implementação mais prática da RFC 2822 se omitirmos a sintaxe usando aspas duplas e colchetes. Ainda corresponderá a 99,99% de todos os endereços de email em uso real hoje.

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

Uma outra alteração que você pode fazer é permitir qualquer domínio de nível superior com código de país com duas letras e apenas domínios de nível superior genérico específicos. Este regex filtra endereços de email falsos comoasdf@adsf.adsf . Você precisará atualizá-lo à medida que novos domínios de nível superior forem adicionados .

[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

Portanto, mesmo seguindo os padrões oficiais, ainda há compromissos a serem feitos. Não copie cegamente expressões regulares de bibliotecas online ou fóruns de discussão. Sempre teste-os com seus próprios dados e com seus próprios aplicativos.

Mina de ênfase


84
NB: "No uso real hoje " pode ter sido válido quando o código foi escrito, em 200x. O código irá provavelmente permanecer em uso além daquele ano específico. (Se eu tivesse um centavo por cada "meh, ninguém nunca usará um TLD com 4 + letras, exceto aqueles específicos" que eu precisei consertar, poderia
encurtar o

7
Para a implementação prática da RFC 2822, a finalização deve ser modificada ligeiramente para evitar extensões de domínio de char único. / [a-z0-9! # $% & '* + \ / =? ^ _ {|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_{|} ~ -] +) * @ (?: [a-z0-9] (?: [a-z0-9 -] * [a-z0-9])? \.) + [a-z0-9] [a-z0-9 -] * [a-z0-9] /
será Farrell em

5
Além disso, a primeira parte deve ser (: [Az com A maiúsculo para evitar falsos negativos quando um usuário capitaliza o seu endereço de e-mail?.
Don Rolando

9
@DonRolling Não faça isso. Isso não significa apenas "A a Z, a a z", mas também significa "[\] ^ _` "porque esses estão entre " Z "e" a ". Use \w, ou melhor, apenas minúscula o endereço de email antes de fazer qualquer coisa com ele, porque essa é a convenção de qualquer maneira.
Kirb

5
"Você precisará atualizá-lo à medida que novos domínios de nível superior forem adicionados." Bem, agora é o bastante - existem mais de 1500 TLDs reconhecidos.
Nathan Osman

377

Uau, há muita complexidade aqui. Se tudo o que você deseja fazer é capturar os erros de sintaxe mais óbvios, eu faria algo assim:

^\S+@\S+$

Geralmente, ele captura os erros mais óbvios que o usuário comete e garante que o formulário esteja correto, o que é a validação do JavaScript.


70
Marcar como +1 e enviar o e-mail e ver o que acontece é a única maneira real de validar um endereço de e-mail. Não é necessário fazer mais do que uma simples correspondência de regex.
kommradHomer

20
Você ainda pode mantê-lo simples, mas faça um pouco mais para garantir que ele tenha um "." em algum lugar após o @ seguido por apenas números ou dígitos, então coisas como eu @ aqui, eu @ aqui @ e eu @ herecom não são válidas ... ^ \ S + @ \ S + [\.] [0-9a-z ] + $
Tim Franklin

14
Acho que os endereços de email podem conter espaços. É provavelmente melhor usar.+@.+
Sam

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

111
@gtournie Ninguém se importa. Ninguém inserirá isso em um campo de email por acidente , e isso é tudo que a validação front-end é para: Impedir que as pessoas digam acidentalmente informações incorretas, como seu nome, em um campo de email.
meagar

330

Há algo que você precisa entender no segundo em que decide usar uma expressão regular para validar emails: provavelmente não é uma boa ideia . Depois que você concorda com isso, existem muitas implementações por aí que podem levá-lo até o meio do caminho, este artigo as resume muito bem.

Em resumo, no entanto, a única maneira de ter certeza absoluta e positiva de que o que o usuário digitou é de fato um email é realmente enviar um email e ver o que acontece. Fora isso, são apenas suposições.


112
-1 por que eu gostaria de gastar meu tempo validando um endereço de email que nem passa no controle regex?
kommradHomer

63
@kommradHomer - um endereço "regex inválido" é quase sempre válido, porque qualquer regex que você usa para validar um endereço de e-mail está quase certamente errado e excluirá endereços de e-mail válidos. Um endereço de email é name_part@domain_parte praticamente qualquer coisa, incluindo um @, é válido no name_part; O endereço foo@bar@machine.subdomain.example.museumé legal, embora deva ser escapado como foo\@bar@machine..... Quando o email chega ao domínio, por exemplo, 'example.com', esse domínio pode rotear o email "localmente" para que nomes de usuário e nomes de host "estranhos" possam existir.
Stephen P

6
O segundo regex na resposta do voyager em stackoverflow.com/a/1373724/69697 é prático para uso e deve ter quase nenhum falso negativo. Concordo com @kommradHomer aqui - por que enviar um e-mail se você não precisar? Compreendo o desagrado reflexivo por expressões incompreensíveis e desejo manter o código simples, mas essas são algumas linhas de código que podem poupar muitos problemas ao servidor, eliminando imediatamente itens definitivamente inválidos. Uma regex por si só é inútil, mas serve como um bom complemento para a validação no servidor.
Ben Regenspan

6
@dmur Eu admito que "quase sempre válido" provavelmente está exagerando, mas tive meus endereços de e-mail (perfeitamente válidos e funcionando) rejeitados com muita frequência por sites, apenas porque tenho um .usdomínio ou porque usei um +à esquerda de os @- muitos lugares corrigiram esses erros flagrantes, mas a parte local (à esquerda de @) pode ser o que o proprietário do domínio desejar. -> "foo@bar.com"@example.com <- é um endereço de email válido.
Stephen P

8
@kommradHomer "Um endereço inválido para regex é% 100 e um endereço inválido." Me desculpe ... com licença? Você sabe quantas vezes me disseram que foo+bar@gmail.com NÃO é um email válido quando, na verdade, É PERFEITAMENTE VÁLIDO ?! Sua lógica é extremamente falha. Enviei formulários com e-mails como tais: este é um correio eletrônico, mas passará pelo seu estúpidoregexcheck@regexchecksareretarded.com E adivinhe? QUE PASSA NA verificação REGEX ... mas NÃO é um email válido (embora tecnicamente seja, mas prometo que não existe ... mas coça o queixo ). Como muitos já disseram, é uma idéia ruim ....
Soundfx4

211

O próprio HTML5 possui validação de email. Se o seu navegador suportar HTML5, você poderá usar o seguinte código.

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

jsFiddle link

A partir da especificação HTML5 :

Um endereço de email válido é uma sequência que corresponde à emailprodução do ABNF a seguir, cujo conjunto de caracteres é 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 >

Esse requisito é uma violação intencional do RFC 5322, que define uma sintaxe para endereços de email que são simultaneamente muito rígidos (antes do caractere "@"), muito vagos (após o caractere "@") e muito relaxados (permitindo comentários) , caracteres de espaço em branco e seqüências de caracteres citadas de maneiras não familiares à maioria dos usuários) para serem úteis aqui.

A seguinte expressão regular compatível com JavaScript e Perl é uma implementação da definição acima.

/^[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
isso é bom, mas o problema é que ele deve estar dentro de uma formtag e enviado por uma submitentrada, que nem todo mundo se dá ao luxo de fazer. Além disso, você não pode realmente estilizar a mensagem de erro.
Jason

3
Adicionei uma resposta abaixo que o liberta do formulário e o envia. Mas sim, os navegadores geralmente também aplicam apenas uma verificação de plausibilidade e não uma validação completa do RFC 822.
Boldewyn

8
@ br1: não é inválido apenas porque não existe um domínio de nível superior “a”. whatif sua intranet tem uma resolução para algum IP?
ovelha voadora

7
Html5 tipo de campo e-mail aceita e-mails como user @ e-mail
Puce

1
Nota do comentário de Puce: a entrada de email em HTML 5 aceita user@email, enquanto, por exemplo, o PHP filter_varnão. Isso pode causar problemas.
texelate

136

Eu descobri que esta é a melhor solução:

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

Permite os seguintes formatos:

1. prettyandsimple@example.com
2. very.common@example.com
3. descartable.style.email.com+symbol@example.com
4. other.email-with-dash@example.com
9. #!$%&'*+-/=?^_`{}|~@example.org
6. "() []:,; @ \\\"! # $% & '* + - / =? ^ _ `{} | ~ .a "@ example.org
7. "" @ example.org (espaço entre as aspas)
8. üñîçøðé@example.com (caracteres Unicode na parte local)
9. üñîçøðé@üñîçøðé.com (caracteres Unicode na parte do domínio)
10. Pelé@example.com (latino)
11. δοκιμή@παράδειγμα.δοκιμή (grego)
12. 我 買 @ 屋企. 香港 (chinês)
13. 甲 斐 @ 黒 川. 日本 (japonês)
14. чебурашка@ящик-с-апельсинами.рф (cirílico)

É claramente versátil e permite todos os caracteres internacionais importantes, ao mesmo tempo em que aplica o formato básico everything@anything.anything. Ele bloqueará espaços tecnicamente permitidos pela RFC, mas são tão raros que fico feliz em fazer isso.


9
É exatamente isso que estou fazendo. Todas essas respostas "complicadas" produzem problemas: elas não permitem IDNs de código insignificante ou usam um conjunto fixo de TLDs ou restringem desnecessariamente o usuário a não usar caracteres como [@ çµ.ö no prefixo de email (antes de @) ou nome de domínio. O JavaScript no front-end (não para uso de causa no back-end) não é suficiente para validar por motivos de segurança. Então, por que não ajudar o usuário a evitar erros de digitação básicos? Os erros de digitação básicos são: esqueça o TLD ou o prefixo do usuário (antes de @) ou a parte do domínio ou o tipo de erro @como .(ou vice-versa). De causa, temos que ser muito mais restritivos no lado do servidor.
Hafenkranich

Por algumas razões estranhas username@domain.com, não funciona com esse padrão
Einstein

2
De acordo com o seu regex, "_.............. kamal@gmail.com" é válido, o que não deve ser!
precisa

1
Aqui está o RegEx indicado com exemplos, se você quiser mexer com esta solução: regex101.com/r/AzzGQU/2
ryanm

7
Este regex está correto. Se alguém estiver digitando seu e-mail assim a@b@c@d.x.y.@.z, talvez ele mereça ter um mau momento? : D
corysimmons

94

Nos navegadores modernos, você pode criar sobre a resposta da @ Sushil com JavaScript puro e o 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);
}

Reuni um exemplo no violino http://jsfiddle.net/boldewyn/2b6d5/ . Combinado com a detecção de recursos e a validação básica do Squirtle's Answer , ele o libera do massacre de expressões regulares e não funciona em navegadores antigos.


4
É uma idéia inteligente para abordar o problema, mas não funciona porque os navegadores também têm validação ruim. Por exemplo, .@avalida como truenas versões atuais do Chrome, Firefox e Safari.
Hank

13
@HenryJackson Infelizmente, neste caso, sim. Isso ocorre porque, de acordo com a RFC, é um endereço de email válido (pense em intranets). Os navegadores seriam grelhados, se validassem muito estreitos e produzissem falsos negativos.
Boldewyn

3
Atualizado para conter a detecção de recursos e a degradação normal, agora não quebra nos novos navegadores, mas usa qualquer regex que você desejar.
Ronny

Ótima solução. Infelizmente, isso é apenas para HTML5 +.
Edward Olamisan

3
Essa é de longe a melhor solução para a pergunta original. Sim, ele usa HTML5, mas a maioria dos aplicativos que exigem esse nível de precisão certamente já estará contando com o HTML5 de alguma outra maneira, portanto, é importante discutir. É impossível determinarmos se o email de alguém é válido sem que ele seja verificado de qualquer maneira; portanto, não devemos investir muito tempo ou esforço para validá-lo. Uma verificação rápida de qualquer sintaxe óbvia ou tentativa de maldade é todo o esforço que deveríamos estar gastando.
Woody Payne

69

Esta é a versão correta do 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);
}

Endereços IDN não são validados (info@üpöü.com)
DAH

66

JavaScript pode corresponder a uma expressão regular:

emailAddress.match( / some_regex /);

Aqui está uma expressão regular RFC22 para 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: Ele usa algumas extensões incompatíveis, incluindo (?>para interromper o retorno e (?<angle><)…(?(angle)>)evitar o fornecimento prolongado |.
Ry-

60

Todos os endereços de email contêm um símbolo 'at' (ou seja, @). Teste essa condição necessária:

email.indexOf("@") > 0

Não se preocupe com algo mais complicado. Mesmo se você pudesse determinar perfeitamente se um email é sintaticamente válido para RFC, isso não informaria se ele pertence à pessoa que o forneceu. Isso é o que realmente importa.

Para testar isso, envie uma mensagem de validação.


3
e se houver mais de um símbolo '@'? outros símbolos restritos? Esta validação não se pode confiar ...
eatmypants

56

A validação correta do endereço de email em conformidade com as RFCs não é algo que pode ser alcançado com uma expressão regular de uma linha. Um artigo com a melhor solução que encontrei no PHP é O que é um endereço de email válido? . Obviamente, foi portado para Java. Eu acho que a função é muito complexa para ser portada e usada em JavaScript. Porta JavaScript / node.js: https://www.npmjs.com/package/email-addresses .

Uma boa prática é validar seus dados no cliente, mas verifique novamente a validação no servidor. Com isso em mente, você pode simplesmente verificar se uma string se parece com um endereço de email válido no cliente e executar uma verificação rigorosa no servidor.

Aqui está a função JavaScript que eu uso para verificar se uma string se parece com um endereço de email válido:

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);
}

Explicação:

  • lastAtPos < lastDotPos: Last @deve ser antes de last, .pois @não pode fazer parte do nome do servidor (tanto quanto eu sei).

  • lastAtPos > 0: Deve haver algo (o nome de usuário do email) antes do último @.

  • str.indexOf('@@') == -1: Não deve haver nenhum @@endereço. Mesmo que @apareça como o último caractere no nome de usuário do e-mail, ele deve ser citado, pois "estaria entre esse @e o último @no endereço.

  • lastDotPos > 2: Deve haver pelo menos três caracteres antes do último ponto, por exemplo a@b.com.

  • (str.length - lastDotPos) > 2: Deve haver caracteres suficientes após o último ponto para formar um domínio de dois caracteres. Não tenho certeza se os colchetes são necessários.


Este fn parece bom, mas é melhor que o regex escrito na resposta superior?
Atul Goyal 15/07

4
Eu duvido. Eu o uso apenas para verificar se uma string se parece com um email e deixar os detalhes no código do servidor.
Miloš Rašić

Ele valida OK qualquer string como 'aaaa', ou seja, sem '@' e '.'
Gennady Shumakher

1
Não deveria. lastIndexOf () deve retornar -1 se não encontrar a agulha.
Miloš Rašić

"Mesmo que @apareça como o último caractere no nome de usuário do e-mail, ele deve ser citado, pois "estaria entre esse @e o último @no endereço". Que tal "@@"@example.com?
Ry-

47

Isso foi roubado de 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
Este filtra cada vez mais popular .museume .traveldomínios (devido a 4 Limite de Caracteres depois .)
bobobobo

4
Mudar {2,4} para {2,6} não será problema
Anton N

11
@ Anton N: Ele tem aproximadamente um bilhão de outros problemas também; o final {2,4}é apenas um indicador útil (como em "quando você vê esse erro, é provável que outros estejam por perto"). O mais básico é a falta de +parte local; essa caixa de comentários é muito pequena para apontar todos os erros cometidos acima.
Piskvor saiu do prédio

37
Por que você não pode simplesmente fazer return filter.test(email.value);?
MT.

3
@AntonN: Agora temos mais de 10 TLDs de caracteres ( xn--clchc0ea0b2g2a9gcd). Ainda não é um problema?
Piskvor saiu do prédio

42

Faça isso:

[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])?

Por quê? É baseado na RFC 2822 , que é um padrão que TODOS os endereços de e-mail DEVEM aderir. E não sei por que você se incomodaria com algo "mais simples" ... você vai copiar e colar mesmo assim;)

Freqüentemente, ao armazenar endereços de email no banco de dados, eu os deixo em minúsculas e, na prática, as regexs geralmente podem ser marcadas como não diferenciando maiúsculas de minúsculas. Nesses casos, isso é um pouco mais curto:

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

Aqui está um exemplo dele sendo usado em JavaScript (com o sinalizador que não diferencia maiúsculas de minúsculas ino final).

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') );

Nota :
tecnicamente, alguns emails podem incluir aspas na seção antes do @símbolo com caracteres de escape dentro das aspas (para que o usuário do email possa ser desagradável e conter itens como @e "..."contanto que esteja escrito entre aspas). NINGUÉM FAZ ISSO NUNCA! É obsoleto. Mas, está incluído no verdadeiro padrão RFC 2822 e é omitido aqui.

Mais informações: http://www.regular-expressions.info/email.html


@ Kondal, o código javascript não diferencia maiúsculas de minúsculas por causa do /isinalizador no final da expressão regular. Menciono o fato de que precisa ser uma comparação que não diferencia maiúsculas de minúsculas, mas deixarei isso mais claro.
Ryan Taylor

Funcionou para mim como um charme
Alex

40

Estou realmente ansioso para resolver este problema. Então eu modifiquei a expressão regular de validação de email acima

  • 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,}))$/

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

para passar os exemplos no endereço de e-mail da Wikipedia .

E você pode ver o resultado aqui .

insira a descrição da imagem aqui


Esta parece ser uma boa solução, ele trabalha com novos TLDs e 1 letra e-mails também
Mark Hughes

Por john..doe@example.comque não deveria estar correto? É uma caixa de canto válida.
Valerio Bozz

24

Você não deve usar expressões regulares para validar uma sequência de entrada e verificar se é um email. É muito complicado e não cobriria todos os casos.

Agora, como você pode cobrir apenas 90% dos casos, escreva algo como:

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

Você pode refiná-lo. Por exemplo, 'aaa @' é válido. Mas no geral você entende. E não se deixe levar ... Uma solução simples de 90% é melhor que uma solução de 100% que não funciona.

O mundo precisa de código mais simples ...


15
Isso permite a entrada de tantos endereços de e-mail inválidos que é um conselho inútil.
Cazlab 6/01/12

3
Não precisa ser impossível depurar. Existem muitos exemplos bons neste segmento que valida mais do que "ele possui um '@'. Seu exemplo permite que" u @ "seja considerado um endereço de email válido. Pelo menos, avalie se existe um domínio ou algo que pode ser um domínio. O seu é um exemplo do que eu chamaria de "codificação agressivamente preguiçosa". Não sei por que você a está defendendo, pois é de longe a resposta com a classificação mais baixa do segmento.
cazlab

3
@cazlab talvez você esteja certo. Afinal, fui rejeitado. Diferentemente de você, acho que nenhum dos códigos acima mostra trechos fáceis de depurar. Minha abordagem 'agressivamente preguiçosa' pelo menos pode ser melhorada, se necessário.
precisa saber é

3
Como isso é diferente de usar regex? (.+)@(.*)faz a mesma coisa, e mais curto.
snostorm

4
+1 - Se o objetivo é garantir que o usuário tenha tentado ao menos inserir um endereço de e-mail, verifique se é possível determinar se o endereço de e-mail definitivamente NÃO é um e-mail. ótima solução. Um bom exemplo seria se você deseja que o nome de usuário de uma pessoa seja um endereço de email. Se o usuário digitar 'sexy_chick_23', esse regex poderá ser usado para avisar que um e-mail é esperado. Se algo digitado parecer um email, mas não for, o usuário nunca receberá o email de 'confirmação' e o processo de inscrição nunca será validado.
Chris Dutrow

23

Basta verificar se o endereço de e-mail inserido é válido ou não está em HTML.

<input type="email"/>

Não há necessidade de escrever uma função para validação.


4
O IE <10 não suporta isso e o navegador do Android também não.
Frank Conijn

7
Voto a favor. IE <10 está morto.
Michael Scheper

19

É difícil obter um validador de email 100% correto. A única maneira real de corrigi-lo seria enviar um email de teste para a conta. Dito isto, existem algumas verificações básicas que podem ajudar a garantir que você esteja recebendo algo razoável.

Algumas coisas para melhorar:

Em vez de novo RegExp, tente escrever o seguinte regexpdesta maneira:

if (reg.test(/@/))

Segundo, verifique se um ponto vem após o @sinal e verifique se há caracteres entre @s e períodos.


19

É assim que o validador de nó faz isso:

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

Use este código dentro da sua função validadora:

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;
}

Caso contrário, você pode usar o jQuery . As regras internas definem:

eMailId: {
    required: true,
    email: true
}

1
abc@xyzé um email perfeitamente válido que não é reconhecido pelo seu regex.
Totó

3
Não, não é. O padrão de email correto é algo@algo.algo, abc @ xyz não corresponde a esse padrão. Portanto, não é um endereço válido.
Orchid


5
Você acessou a página da Wikipedia? Um TLD é um nome de host válido. Assim abc@tldé um endereço de email válido.
Toto

2
A única maneira de validar um endereço de email é enviar um email e aguardar a resposta. Além disso, aqui está um URL onde você pode testar se o seu endereço é compatível com RFC822: mythic-beasts.com/~pdw/cgi-bin/emailvalidate . Você pode ver que abc @ xyz é um endereço válido para o RFC822.
Toto

14

Atualização Regex 2018! tente isso

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');
}

versão typscript concluída

//
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);

mais informações https://git.io/vhEfc


Isso falhou para um email@domain.com padrão
ricks

1
@ RickS isso simplesmente não é verdade. Verifique novamente
malimo 28/11

13

Uma solução que não verifica a existência do TLD está incompleta.

Quase todas as respostas a essas perguntas sugerem o uso do Regex para validar endereços de e-mail. Eu acho que o Regex é bom apenas para uma validação rudimentar. Parece que a verificação de validação de endereços de email é na verdade dois problemas separados:

1- Validação do formato do email: verifique se o email está em conformidade com o formato e o padrão dos emails na RFC 5322 e se o TLD realmente existe. Uma lista de todos os TLDs válidos pode ser encontrada aqui .

Por exemplo, embora o endereço example@example.ccc passe na regex, não é um email válido, porque cccnão é um domínio de nível superior da IANA.

2- Certificando-se de que o email realmente exista: Para isso, a única opção é enviar um email aos usuários .


13

Regex para validar endereço de email

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

Eu não ver o seu regexp em RFC5322: tools.ietf.org/html/rfc5322 - existe algum erro?
Kamil Kiełczewski 20/09

"Melhor regex de todos os tempos"? Possivelmente algum tipo de explicação aqui?
connectyourcharger

Por que você disse que essa é a melhor solução de todas, você pode explicar um pouco mais, por favor?
Nancoder 04/07/19

Não consigo lembrar por que escrevi o "melhor regex de todos os tempos". Desculpa pessoal se isso te incomoda.
Prabhat Kasera

12

Aqui está uma discussão muito boa sobre o uso de expressões regulares para validar endereços de email; " Comparando endereço de email validando expressões regulares "

Aqui está a expressão superior atual, compatível com JavaScript, para fins de referência:

/^[-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 A lista de permissões deixa muito a desejar - principalmente, você perdeu .jobs. Além disso, existem IDNs ativos (a maioria dos quais, admito, só foi oficialmente aprovada após a sua publicação - por exemplo, .中國em junho de 2010; mas a maioria está em andamento há anos).
Piskvor deixou o prédio

2
-1 não usa domínios constantes de nível superior. Sempre haverá (e haverá, por exemplo, 2013) novos tld.
miho

Há centenas confirmadas de novos TLDs. Esta resposta não é válida e nunca deve ser usada.
Dean Meehan

Sim. Eu disse isso em 2011 e direi novamente: uma lista de permissões de domínios "especiais" só piorará com o tempo, à medida que mais TLDs forem aprovados. Existem mais de 100 TLDs completamente válidos que não correspondem à lista de permissões acima: en.wikipedia.org/wiki/List_of_Internet_top-level_domains
Piskvor deixou o prédio

É 2015. Sua expressão não é prática. Você deve anotar esta resposta, mas provavelmente está muito ocupado consertando todas as páginas em que você colocou essa expressão. Direita?
Eric Leroy


12

Ao contrário do squirtle , aqui está uma solução complexa, mas ele faz um excelente trabalho de validação de emails corretamente:

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);
} 

Use assim:

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

10
Você não precisa do == trueseu exemplo.
Luke Alderton

11

Meu conhecimento de expressões regulares não é tão bom. É por isso que eu verifico a sintaxe geral com uma expressão regular simples primeiro e depois as opções mais específicas com outras funções. Essa pode não ser a melhor solução técnica, mas dessa maneira eu sou muito mais flexível e mais rápida.

Os erros mais comuns que encontrei são espaços (especialmente no começo e no fim) e, ocasionalmente, um ponto duplo.

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>

Talvez se você adicionou uma explicação ou descrição para acompanhar? Eu não acho que você realmente precise mostrar nenhum html; todas as pessoas estão preocupadas com o javascript e o regex. Se você reduzir sua resposta apenas ao jacascript e adicionar um pouco de sinopse a seguir, darei um voto positivo.
bgmCoder

9

Eu estava procurando por um Regex em JS que passasse em todos os casos de teste de endereço de email:

  • email@example.com Email válido

  • firstname.lastname@example.com O email contém um ponto no campo de endereço

  • email@subdomain.example.com O email contém ponto com subdomínio

  • firstname+lastname@example.com O sinal de adição é considerado um caractere válido

  • email@192.0.2.123 O domínio é um endereço IP válido

  • email@[192.0.2.123] O colchete em torno do endereço IP é considerado válido

  • “email”@example.com Citações entre e-mail são consideradas válidas

  • 1234567890@example.com Os dígitos no endereço são válidos

  • email@domain-one.example O traço no nome de domínio é válido

  • _______@example.com Sublinhado no campo de endereço é válido

  • email@example.name .name é um nome de domínio de nível superior válido

  • email@example.co.jpPonto no nome de domínio de nível superior também considerado válido (usando co.jpcomo exemplo aqui)

  • firstname-lastname@example.com O traço no campo de endereço é válido

Aqui vamos nós :

http://regexr.com/3f07j

OU regex:

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

8

A expressão regular fornecida pela Microsoft no ASP.NET MVC é

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

Que eu publico aqui caso seja falha - embora sempre tenha sido perfeita para minhas necessidades.


1
Não permite + na parte do nome do email.
Paul Go
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.