Cómo validar una dirección de correo electrónico en JavaScript


4381

¿Existe una expresión regular para validar una dirección de correo electrónico en JavaScript?



6060
por favor, haga esto bien, a muchos sitios web no les gusta mi dirección de correo electrónico "firstName@secondName.name", no todos los dominios de nivel superior terminan con 2 o 3 letras.
Ian Ringrose

41
Cualquier soporte para el uso de cheques regex para correos electrónicos con los que estoy 100% en contra. Estoy cansado de que me digan que mi dirección de correo electrónico "foo+bar@gmail.com" no es válida. La mejor opción es pedirle al usuario que escriba su correo electrónico dos veces y si DEBE usar un comprobador de expresiones regulares, dígale al usuario que su dirección de correo electrónico no parece ser válida y pregúntele si está seguro de haberla escrito. Derecha. Incluso vaya tan lejos como para señalar LO QUE no se verificó en el cheque regexp, pero NO impida que envíen el formulario.
Soundfx4

17
@ Soundfx4: esta debería ser LA respuesta y aceptarse como tal. Probar la exactitud de una dirección es algo tonto , la mejor manera de frustrar a los clientes. Solicito la dirección a ser escrito dos veces y indicio de que hay algunos temas posibles (faltantes @, ;cometc.) y dejar que el usuario correcto si lo desean (y aceptar lo que me mandan)
Woj

44
Estoy totalmente de acuerdo con la respuesta dada por WoJ. El formato de una dirección de correo electrónico válida es demasiado complejo para comprobarlo con una expresión regular simple. La única forma de asegurarse de que la dirección es válida es probarla.
Nicole

Respuestas:


4949

Usar expresiones regulares es probablemente la mejor manera. Puedes ver un montón de pruebas aquí (tomadas de 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());
}

Aquí está el ejemplo de expresión regular que acepta unicode:

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

Pero tenga en cuenta que no se debe confiar solo en la validación de JavaScript. JavaScript se puede deshabilitar fácilmente. Esto también debe validarse en el lado del servidor.

Aquí hay un ejemplo de lo anterior en acción:

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
Esta expresión regular elimina los correos electrónicos válidos en uso. No utilice. Google para "RFC822" o "RFC2822" para obtener una expresión regular adecuada.
Randal Schwartz

42
Esto ni siquiera acepta los ejemplos en RFC 822. Algunos casos simples no coinciden con a \ @ b @ c.com, a(b)@c.com. Vea el RFC para más. Aquí hay una expresión regular que no rechazará ninguna dirección válida [^ @] + @ [^ @] + \. [^ @] + Y protege contra errores comunes.
Vroo

126
@GoodPerson Intenté enviar un correo electrónico a n @ ai para decirle que tienen una dirección de correo electrónico genial. Pero, por desgracia, Gmail no me dejaba. ¡Sospecho que quien sea tiene mayores problemas para comunicarse con otros por correo electrónico que solo la validación de JavaScript de mi sitio! Pero gracias por estar a la altura del desafío.
Ben Roberts el

26
Esta es una solución que parece buena con la mayoría de los hablantes nativos de inglés, pero no pasa la prueba de Turquía (ver Joel Spolsky). La mayoría de las letras Unicode están permitidas y, por ejemplo, en Argentina, direcciones como "ñoñó1234@server.com" son perfectamente normales. joelonsoftware.com/articles/Unicode.html
oligofren

139
No puede validar direcciones de correo electrónico, punto. El único que puede validar una dirección de correo electrónico es el proveedor de la dirección de correo electrónico. Por ejemplo, esta respuesta dice que estas direcciones de correo electrónico %2@gmail.com, "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, _@gmail.com, 1@gmail.com , 1_example@something.gmail.comson todas válidas, pero Gmail nunca permitirá ninguna de estas direcciones de correo electrónico. Debe hacerlo aceptando la dirección de correo electrónico y enviando un mensaje de correo electrónico a esa dirección de correo electrónico, con un código / enlace que el usuario debe visitar para confirmar la validez.
Kevin Fegan

830

He modificado ligeramente la respuesta de Jaymon para las personas que quieren una validación realmente simple en forma de:

anystring@anystring.anystring

La expresión regular:

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

Ejemplo de función de JavaScript:

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


69
Puede implementar algo 20 veces más largo que podría causar problemas a algunos usuarios y no ser válido en el futuro, o puede tomar la versión de ImmortalFirefly para asegurarse de que al menos se esfuercen por hacer que parezca real. Dependiendo de su aplicación, puede ser más probable que alguien se enoje porque no acepta su correo electrónico no convencional, en lugar de alguien que causa problemas al ingresar direcciones de correo electrónico que realmente no existen (lo que pueden hacer de todos modos ingresando una dirección de correo electrónico RFC2822 100% válida pero usando un nombre de usuario o dominio no registrado). ¡Votado!
user83358

82
@ImmortalFirefly, la expresión regular que proporcionó coincidirá realmente name@again@example.com. Intente pegar su línea en una consola de JavaScript. Creo que su intención era hacer coincidir solo el texto completo, lo que requeriría el comienzo del texto '^' y el final del texto '$' operadores. El que estoy usando es/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com')
OregonTrail

8
Según esta validación, este correo electrónico es válido: consulte @ this..com
Ehsan

44
Hm. Wikipedia dice que "very.unusual.@.unusual.com"@example.comes una dirección de correo electrónico válida. /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('"very.unusual.@.unusual.com"@example.com') // false. Ups
Bacon Bits

3
¿Esto no lo permite también @@@.@? : D
hfossli

763

Solo para completar, aquí tiene otra expresión regular compatible con RFC 2822

El estándar oficial se conoce como RFC 2822 . Describe la sintaxis a la que deben adherirse las direcciones de correo electrónico válidas. Se puede ( pero no deberías - sigue leyendo ) implementarlo con esta expresión 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])+)\])

(...) Obtenemos una implementación más práctica de RFC 2822 si omitimos la sintaxis usando comillas dobles y corchetes. Todavía coincidirá con el 99.99% de todas las direcciones de correo electrónico en uso real hoy.

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

Un cambio adicional que podría realizar es permitir cualquier dominio de nivel superior de código de país de dos letras y solo dominios genéricos específicos de nivel superior. Esta expresión regular filtra direcciones de correo electrónico falsas comoasdf@adsf.adsf . Deberá actualizarlo a medida que se agreguen nuevos dominios de nivel superior .

[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

Por lo tanto, incluso cuando se siguen las normas oficiales, todavía hay que hacer concesiones. No copie ciegamente expresiones regulares de bibliotecas en línea o foros de discusión. Siempre pruébelos con sus propios datos y con sus propias aplicaciones.

El énfasis es mío


84
NB: "En uso real hoy " puede haber sido válido cuando se escribió el código, en 200x. El código será probablemente se mantendrá en uso más allá de ese año específico. (Si tuviera una moneda de diez centavos por cada "meh, nadie usaría nunca un TLD de 4+ letras excepto aquellos específicos" que tuve que arreglar, podría arrinconar el mercado mundial de cobre y níquel;))
Piskvor dejó el edificio

77
Para la implementación práctica de RFC 2822, el final debe modificarse ligeramente para evitar extensiones de dominio de un solo carácter. / [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

55
Además, la primera parte debería ser (?: [Az con una A mayúscula para evitar falsos negativos cuando un usuario capitaliza su dirección de correo electrónico.
Don Rolling

99
@DonRolling No hagas eso. Eso no solo significa "A a Z, a a z", sino que también significa "[\] ^ _` "porque están entre " Z "y" a ". Utilice \w, o mejor, simplemente en minúscula la dirección de correo electrónico antes de hacer algo con ella porque esa es la convención de todos modos.
Kirb

55
"Deberá actualizarlo a medida que se agreguen nuevos dominios de nivel superior". Bueno, mucho por eso ahora: hay más de 1500 TLD reconocidos.
Nathan Osman

377

Wow, hay mucha complejidad aquí. Si todo lo que quiere hacer es detectar los errores de sintaxis más obvios, haría algo como esto:

^\S+@\S+$

Por lo general, detecta los errores más obvios que comete el usuario y asegura que el formulario es en su mayoría correcto, de eso se trata la validación de JavaScript.


70
+1 ya que enviar un correo electrónico y ver lo que sucede es la única forma segura de validar una dirección de correo electrónico, no hay necesidad de hacer más que una simple coincidencia de expresiones regulares.
kommradHomer

20
Puede mantenerlo simple pero hacer un poco más para asegurarse de que tenga un "." en algún lugar después de la @ seguido de solo números o dígitos, así que cosas como yo @ aquí, yo @ aquí @ y yo @ herecom no son válidas ... ^ \ S + @ \ S + [\.] [0-9a-z ] + $
Tim Franklin

14
Creo que las direcciones de correo electrónico pueden contener espacios. Probablemente sea mejor usar.+@.+
Sam

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

111
@gtournie A nadie le importa. Nadie va a ingresar eso en un campo de correo electrónico por accidente , y eso es todo, la validación de front-end es para: evitar que las personas ingresen accidentalmente la información incorrecta, como su nombre, en un campo de correo electrónico.
meagar

330

Hay algo que debes entender en el momento en que decidas usar una expresión regular para validar los correos electrónicos: probablemente no sea una buena idea . Una vez que haya llegado a un acuerdo con eso, hay muchas implementaciones que pueden llevarlo hasta la mitad, este artículo las resume muy bien.

En resumen, sin embargo, la única forma de estar absolutamente seguro de que lo que ingresó el usuario es en realidad un correo electrónico es enviar un correo electrónico y ver qué sucede. Aparte de eso, todo son solo conjeturas.


112
-1 ¿por qué querría pasar mi tiempo validando una dirección de correo electrónico que ni siquiera pasa el control de expresiones regulares?
kommradHomer

63
@kommradHomer: una dirección "regex inválida" casi siempre es válida, porque cualquier regex que use para validar una dirección de correo electrónico es casi seguramente incorrecta y excluirá las direcciones de correo electrónico válidas. Una dirección de correo electrónico es name_part@domain_party prácticamente cualquier cosa, incluida una @, es válida en name_part; La dirección foo@bar@machine.subdomain.example.museumes legal, aunque se debe escapar como foo\@bar@machine..... Una vez que el correo electrónico llega al dominio, por ejemplo, 'example.com', ese dominio puede enrutar el correo "localmente" para que puedan existir nombres de usuario y nombres de host "extraños".
Stephen P

66
La segunda expresión regular en la respuesta del viajero en stackoverflow.com/a/1373724/69697 es práctica de usar y casi no debería tener falsos negativos. Estoy de acuerdo con @kommradHomer aquí, ¿por qué enviar un correo electrónico si no es necesario? Puedo entender el disgusto reflexivo por expresiones regulares incomprensibles y deseo de mantener el código simple, pero este es un par de líneas de código que pueden ahorrarle muchos problemas a su servidor al eliminar inmediatamente los elementos que definitivamente no son válidos. Una expresión regular por sí sola no es útil, pero sirve como un buen complemento para la validación del servidor.
Ben Regenspan

66
@dmur reconozco que "casi siempre es válido" probablemente lo exagere, pero los sitios web han rechazado mis direcciones de correo electrónico (perfectamente válidas y funcionales) con demasiada frecuencia, simplemente porque tengo un .usdominio o porque usé un +a la izquierda de los @- muchos lugares se han corregido estos errores flagrantes, pero la parte local (a la izquierda de la @) pueden ser cualquier cosa el dueño del dominio quiere. -> "foo@bar.com"@example.com <- es una dirección de correo electrónico válida.
Stephen P

8
@kommradHomer "Una dirección inválida regex es% 100 una dirección inválida". ¿Lo siento, discúlpame? ¿Sabes cuántas veces me han dicho que foo+bar@gmail.com NO es un correo electrónico válido cuando de hecho ES PERFECTAMENTE VÁLIDO? Tu lógica es EXTREMADAMENTE defectuosa. He enviado formularios con correos electrónicos como este: thisisafakeemailbutitwillwytttididregexcheck@regexchecksareretarded.com ¿Y adivina qué? QUE PASA el cheque REGEX ... pero NO es un correo electrónico válido (aunque técnicamente lo es, pero te prometo que no existe ... pero se rasca la barbilla ). Como muchos han dicho, ES UNA MALA IDEA ...
Soundfx4

211

HTML5 en sí tiene validación de correo electrónico. Si su navegador admite HTML5, puede usar el siguiente código.

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

Enlace jsFiddle

De la especificación HTML5 :

Una dirección de correo electrónico válida es una cadena que coincide con la emailproducción del siguiente ABNF, cuyo juego de caracteres es 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 >

Este requisito es una violación intencional de RFC 5322, que define una sintaxis para direcciones de correo electrónico que es simultáneamente demasiado estricta (antes del carácter "@"), demasiado vaga (después del carácter "@") y demasiado laxa (permitiendo comentarios , caracteres de espacios en blanco y cadenas citadas de maneras desconocidas para la mayoría de los usuarios) para que sean de utilidad práctica aquí.

La siguiente expresión regular compatible con JavaScript y Perl es una implementación de la definición anterior.

/^[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
esto es bueno, pero el problema con esto es que debe estar dentro de una formetiqueta y enviado por una submitentrada, que no todos pueden darse el lujo de hacer. Además, realmente no puede diseñar el mensaje de error.
Jason

3
Agregué una respuesta a continuación que lo libera del formulario y lo envía. Pero sí, los navegadores generalmente solo aplican alguna verificación de plausibilidad y no una validación completa de RFC 822.
Boldewyn

8
@ br1: no es inválido solo porque no existe un dominio de nivel superior "a". ¿Qué pasa si su intranet tiene una resolución para alguna IP?
ovejas voladoras

77
El tipo de campo de correo electrónico html5 acepta correos electrónicos como usuario @ correo electrónico
Puce

1
Nota del comentario de @ Puce: la entrada de correo electrónico HTML 5 acepta user@emailmientras que, por ejemplo, PHP filter_varno. Esto puede causar problemas.
texelate

136

He encontrado que esta es la mejor solución:

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

Permite los siguientes formatos:

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

Es claramente versátil y permite los personajes internacionales más importantes, a la vez que impone el formato básico anything@anything.anything. Bloqueará espacios que técnicamente están permitidos por RFC, pero son tan raros que estoy feliz de hacer esto.


99
Esto es exactamente lo que estoy haciendo. Todas estas respuestas "complicadas" producen problemas: no permiten IDN de código insignificante o usan un conjunto fijo de TLD o restringen innecesariamente al usuario para que no use caracteres como [@ çµ.ö en su prefijo de correo electrónico (antes de @) o nombre de dominio. JavaScript en la interfaz de usuario (no para uso de causa de fondo) no es suficiente para validar por razones de seguridad. Entonces, ¿por qué no solo ayudar al usuario a evitar errores tipográficos básicos? Los errores tipográficos básicos son: olvidar TLD o prefijo de usuario (antes de @) o parte de dominio o tipo de error @como .(o viceversa). De hecho, tenemos que ser mucho más restrictivos en el lado del servidor.
Hafenkranich

Por alguna extraña razón username@domain.comno funciona con este patrón
einstein

2
Según su expresión regular "_.............. kamal@gmail.com" es válido, ¡lo cual no debería ser!
Kamal Nayan

1
Aquí está el RegEx indicado con ejemplos, si desea jugar con esta solución: regex101.com/r/AzzGQU/2
ryanm

77
Esta expresión regular es correcta. Si alguien ingresa su correo electrónico como a@b@c@d.x.y.@.zentonces, ¿tal vez merecen pasar un mal rato? : D
corysimmons

94

En los navegadores modernos, puede construir sobre la respuesta de @ Sushil con JavaScript puro y 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);
}

He reunido un ejemplo en el violín http://jsfiddle.net/boldewyn/2b6d5/ . Combinado con la detección de características y la validación básica de Squirtle's Answer , lo libera de la masacre de expresiones regulares y no interfiere en los navegadores antiguos.


44
Esta es una idea inteligente para resolver el problema, pero no funciona porque los navegadores también tienen una validación deficiente. Por ejemplo, .@avalida como trueen las versiones actuales de Chrome, Firefox y Safari.
Hank

13
@HenryJackson Desafortunadamente, en este caso sí. Esto se debe a que, según el RFC, es una dirección de correo electrónico válida (piense en las intranets). Los navegadores se asarían si validan demasiado y producen falsos negativos.
Boldewyn

3
Actualizado para contener la detección de funciones y la degradación elegante, ahora no se rompe en los nuevos navegadores, sino que utiliza cualquier expresión regular que desee.
Ronny

Buena solución Lamentablemente, esto es solo para HTML5 +.
Edward Olamisan

3
Esta es, con mucho, la mejor solución a la pregunta original. Sí, usa HTML5, pero la mayoría de las aplicaciones que requieren este nivel de precisión seguramente ya dependerán de HTML5 de alguna otra manera, de modo que es discutible. Es imposible para nosotros determinar si el correo electrónico de alguien es válido sin lograr que lo verifiquen de todos modos, por lo que realmente no deberíamos invertir tanto tiempo o esfuerzo en validarlo. Una comprobación rápida de cualquier sintaxis obvia o intento de travesura es todo el esfuerzo que deberíamos dedicar.
Woody Payne

69

Esta es la versión correcta de 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);
}

Las direcciones IDN no están validadas (info@üpöü.com)
DAH

66

JavaScript puede coincidir con una expresión regular:

emailAddress.match( / some_regex /);

Aquí hay una expresión regular RFC22 para correos electrónicos:

^((?>[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: Utiliza algunas extensiones incompatibles, incluso (?>para detener el retroceso y (?<angle><)…(?(angle)>)evitar proporcionar una extensión prolongada |.
Ry-

60

Todas las direcciones de correo electrónico contienen un símbolo 'at' (es decir, @). Pruebe esa condición necesaria:

email.indexOf("@") > 0

No te molestes con nada más complicado. Incluso si pudiera determinar perfectamente si un correo electrónico es válido sintácticamente RFC, eso no le diría si pertenece a la persona que lo suministró. Eso es lo que realmente importa.

Para probar eso, envíe un mensaje de validación.


3
¿Qué pasa si habrá más de un símbolo '@'? otros símbolos restringidos? No se puede confiar en esta validación ...
eatmypants

56

La validación correcta de la dirección de correo electrónico de conformidad con los RFC no es algo que se pueda lograr con una expresión regular de una línea. Un artículo con la mejor solución que he encontrado en PHP es ¿Qué es una dirección de correo electrónico válida? . Obviamente, se ha portado a Java. Creo que la función es demasiado compleja para ser portada y utilizada en JavaScript. Puerto JavaScript / node.js: https://www.npmjs.com/package/email-addresses .

Una buena práctica es validar sus datos en el cliente, pero verifique la validación en el servidor. Con esto en mente, simplemente puede verificar si una cadena se parece a una dirección de correo electrónico válida en el cliente y realizar una verificación estricta en el servidor.

Aquí está la función de JavaScript que uso para verificar si una cadena se parece a una dirección de correo válida:

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

Explicación:

  • lastAtPos < lastDotPos: El último @debe ser anterior al último .desde@ que no puede ser parte del nombre del servidor (que yo sepa).

  • lastAtPos > 0: Debe haber algo (el nombre de usuario del correo electrónico) antes del último @.

  • str.indexOf('@@') == -1: No debe haber @@en la dirección. Incluso si @aparece como el último carácter en el nombre de usuario del correo electrónico, debe citarse, por "lo que estaría entre ese @y el último @en la dirección.

  • lastDotPos > 2: Debe haber al menos tres caracteres antes del último punto, por ejemplo a@b.com.

  • (str.length - lastDotPos) > 2: Debe haber suficientes caracteres después del último punto para formar un dominio de dos caracteres. No estoy seguro si los corchetes son necesarios.


Este fn se ve bien, pero ¿es mejor que la expresión regular escrita en la respuesta superior?
Atul Goyal

44
Lo dudo. Lo uso solo para verificar si una cadena parece un correo electrónico y dejar los detalles en el código del lado del servidor.
Miloš Rašić

Valida OK cualquier cadena como 'aaaa', es decir, sin '@' y '.'
Gennady Shumakher

1
No debería lastIndexOf () debería devolver -1 si no encuentra la aguja.
Miloš Rašić

"Incluso si @aparece como el último carácter en el nombre de usuario del correo electrónico, debe citarse, por "lo que estaría entre ese @y el último @en la dirección". ¿Qué hay de "@@"@example.com?
Ry-

47

Esto fue robado 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;}

77
Esto filtra los dominios .museumy los populares .travel(debido al límite de 4 caracteres después .)
bobobobo

44
Cambiar {2,4} a {2,6} no será un problema
Anton N

11
@Anton N: Tiene aproximadamente una gran cantidad de otros problemas también; el final {2,4}es simplemente un indicador útil del mismo (como en "cuando ve ese error, es probable que haya otros"). La más básica es la falta +en la parte local; este cuadro de comentarios es demasiado pequeño para señalar todos los errores cometidos anteriormente.
Piskvor salió del edificio el

37
¿Por qué no puedes simplemente hacer return filter.test(email.value);?
MT.

3
@AntonN: Ahora tenemos más de 10 TLD de caracteres ( xn--clchc0ea0b2g2a9gcd). ¿Todavía no es un problema?
Piskvor salió del edificio el

42

Hacer esto:

[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é? Se basa en RFC 2822 , que es un estándar que TODAS las direcciones de correo electrónico DEBEN cumplir. Y no estoy seguro de por qué te molestarías con algo "más simple" ... vas a copiarlo y pegarlo de todos modos;)

A menudo, al almacenar direcciones de correo electrónico en la base de datos, las pongo en minúsculas y, en la práctica, las expresiones regulares generalmente se pueden marcar sin distinción entre mayúsculas y minúsculas. En esos casos esto es un poco más corto:

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

Aquí hay un ejemplo de su uso en JavaScript (con el distintivo de mayúsculas y minúsculas ial 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 :
Técnicamente, algunos correos electrónicos pueden incluir comillas en la sección anterior al @símbolo con caracteres de escape dentro de las comillas (por lo que su usuario de correo electrónico puede ser desagradable y contener cosas como @y "..."siempre que esté escrito entre comillas). NADIE HACE ESTO NUNCA! Es obsoleto Pero, ESTÁ incluido en el verdadero RFC 2822 estándar , y se omite aquí.

Más información: http://www.regular-expressions.info/email.html


@Kondal, el código JavaScript no distingue entre mayúsculas y minúsculas debido a la marca al /ifinal de la expresión regular. Menciono el hecho de que debe ser una comparación entre mayúsculas y minúsculas, pero lo dejaré más claro.
Ryan Taylor

Funcionó para mí como un encanto
Alex

40

Tengo muchas ganas de resolver este problema. Así que modifiqué la expresión regular de validación de correo electrónico anterior

  • 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 pasar los ejemplos en la dirección de correo electrónico de Wikipedia .

Y puedes ver el resultado aquí .

ingrese la descripción de la imagen aquí


Parece una buena solución, también funciona con nuevos TLD y correos electrónicos de 1 carta
Mark Hughes

¿Por john..doe@example.comqué no debería ser correcto? Es un caso de esquina válido.
Valerio Bozz

24

No debe usar expresiones regulares para validar una cadena de entrada para verificar si es un correo electrónico. Es demasiado complicado y no cubriría todos los casos.

Ahora, dado que solo puede cubrir el 90% de los casos, escriba algo como:

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

Puedes refinarlo. Por ejemplo, 'aaa @' es válido. Pero en general se entiende la esencia. Y no se deje llevar ... Una solución simple al 90% es mejor que una solución al 100% que no funciona.

El mundo necesita un código más simple ...


15
Esto permite la entrada de tantas direcciones de correo electrónico inválidas que es un consejo inútil.
cazlab

3
No tiene que ser imposible depurar en absoluto. Hay muchos buenos ejemplos en este hilo que se validan más allá de "¿tiene una '@'? Su ejemplo permite que" u @ "se considere una dirección de correo electrónico válida. Al menos evalúe si hay un dominio o algo que podría ser un dominio. El suyo es un ejemplo de lo que yo llamaría "codificación agresivamente perezosa". No estoy seguro de por qué lo defiende, ya que es, con mucho, la respuesta con la calificación más baja en el hilo.
cazlab

3
@cazlab tal vez tengas razón. Después de todo, he sido rechazado. A diferencia de usted, no creo que ninguno de los códigos anteriores muestre fragmentos fáciles de depurar. Mi enfoque 'agresivamente perezoso' al menos puede mejorarse si es necesario.
Zo72

3
¿En qué se diferencia esto del uso de expresiones regulares? (.+)@(.*)hace lo mismo, y más corto.
snostorm

44
+1: si el objetivo es asegurarse de que el usuario haya intentado al menos ingresar una dirección de correo electrónico, verificando si puede determinarse que la dirección de correo electrónico definitivamente NO es un correo electrónico Gran solución. Un buen ejemplo sería si desea que el nombre de usuario de una persona sea una dirección de correo electrónico. Si el usuario escribe 'sexy_chick_23', esta expresión regular se puede usar para avisarles de que se espera un correo electrónico. Si se escribe algo que parece un correo electrónico, pero no lo es, entonces el usuario nunca recibirá el correo electrónico de "confirmación" y el proceso de registro nunca será validado.
Chris Dutrow

23

Simplemente verifique si la dirección de correo electrónico ingresada es válida o no utiliza HTML.

<input type="email"/>

No hay necesidad de escribir una función para la validación.


44
IE <10 no es compatible con esto, ni tampoco el navegador de Android.
Frank Conijn

77
Votación a favor. IE <10 está muerto.
Michael Scheper

19

Es difícil obtener un validador de correo electrónico 100% correcto. La única forma real de hacerlo correctamente sería enviar un correo electrónico de prueba a la cuenta. Dicho esto, hay algunas comprobaciones básicas que pueden ayudar a garantizar que esté obteniendo algo razonable.

Algunas cosas para mejorar:

En lugar de nuevo RegExp, solo trata de escribirlo regexpasí:

if (reg.test(/@/))

En segundo lugar, verifique que haya un punto después del @signo y asegúrese de que haya caracteres entre los @puntos y los puntos.


19

Así es como lo hace el validador de nodos :

/^(?:[\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 de su función de validación:

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

De lo contrario, puede usar jQuery . Las reglas internas definen:

eMailId: {
    required: true,
    email: true
}

1
abc@xyzes un correo electrónico perfectamente válido que no es reconocido por su expresión regular.
Toto

3
No, no es. El patrón de correo electrónico correcto es something@something.something, abc @ xyz no coincide con ese patrón. Entonces, no es una dirección válida.
Orchid


55
¿Tienes la página de Wikipedia? Un TLD es un nombre de host válido. Entonces, abc@tldes una dirección de correo electrónico válida.
Toto

2
La única forma de validar una dirección de correo electrónico es enviar un correo electrónico y luego esperar la respuesta. Además de esto, aquí hay una url donde puede probar si su dirección cumple con RFC822: mythic-beasts.com/~pdw/cgi-bin/emailvalidate . Puede ver que abc @ xyz es una dirección válida para RFC822.
Toto

14

Regex actualización 2018! prueba esto

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

versión de typscript completa

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

más información https://git.io/vhEfc


Esto falló para un correo electrónico estándar@dominio.com
ricks

1
@ RickS esto simplemente no es cierto. Por favor verifique nuevamente
malimo

13

Una solución que no verifica la existencia del TLD es incompleta.

Casi todas las respuestas a estas preguntas sugieren usar Regex para validar las direcciones de correo electrónico. Creo que Regex solo es bueno para una validación rudimentaria. Parece que la validación de verificación de direcciones de correo electrónico es en realidad dos problemas separados:

1- Validación del formato de correo electrónico: asegurarse de que el correo electrónico cumpla con el formato y el patrón de los correos electrónicos en RFC 5322 y si el TLD realmente existe. Puede encontrar una lista de todos los TLD válidos aquí .

Por ejemplo, aunque la dirección example@example.cccpasará la expresión regular, no es un correo electrónico válido, porqueccc IANA no es un dominio de nivel superior.

2- Asegurarse de que el correo electrónico realmente existe: para hacer esto, la única opción es enviar un correo electrónico a los usuarios .


13

Regex para validar la dirección de correo electró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])+

No veo su expresión regular en RFC5322: tools.ietf.org/html/rfc5322 , ¿hay algún error?
Kamil Kiełczewski

¿"La mejor expresión regular de la historia"? ¿Posiblemente algún tipo de explicación aquí?
connectyourcharger

¿Por qué dijiste que esa es la mejor solución de todas? ¿Puedes explicar un poco más por favor?
nancoder

No puedo recordar por qué he escrito "la mejor expresión regular de la historia". Lo siento chicos si eso te molesta.
Prabhat Kasera

12

Aquí hay una muy buena discusión sobre el uso de expresiones regulares para validar direcciones de correo electrónico; " Comparación de la dirección de correo electrónico que valida expresiones regulares "

Aquí está la expresión superior actual, que es compatible con JavaScript, para fines de referencia:

/^[-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

99
-1 La lista blanca deja mucho que desear, en particular, te perdiste .jobs. Además, hay IDN en vivo (la mayoría de los cuales, lo admito, solo fueron aprobados oficialmente después de su publicación, por ejemplo, .中國en junio de 2010; pero la mayoría han estado en proceso durante años).
Piskvor salió del edificio el

2
-1 no use dominios constantes de nivel superior. Siempre (y habrá, por ejemplo, 2013) podría agregarse nuevo tld.
miho

Se confirmaron cientos de nuevos TLD. Esta respuesta no es válida y nunca debe usarse.
Dean Meehan

Sip. Lo dije en 2011, y lo diré nuevamente: una lista blanca de dominios "especiales" solo empeorará con el tiempo, a medida que se aprueben más TLD. Hay más de 100 TLD completamente válidos que no coinciden con la lista blanca anterior: en.wikipedia.org/wiki/List_of_Internet_top-level_domains
Piskvor salió del edificio el

Es 2015. Tu expresión no es práctica. Debería tomar esta respuesta, pero probablemente esté demasiado ocupado arreglando todas las páginas en las que pone esta expresión. ¿Derecha?
Eric Leroy


12

En contraste con Squirtle , aquí hay una solución compleja, pero hace un excelente trabajo al validar correctamente los correos electrónicos:

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 así:

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

10
No necesitas el == trueen tu ejemplo.
Luke Alderton

11

Mi conocimiento de expresiones regulares. no es tan bueno. Es por eso que primero verifico la sintaxis general con una expresión regular simple y luego verifico opciones más específicas con otras funciones. Puede que esta no sea la mejor solución técnica, pero de esta manera soy mucho más flexible y rápido.

Los errores más comunes que he encontrado son espacios (especialmente al principio y al final) y ocasionalmente un doble punto.

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>

¿Tal vez si agregaste una explicación o descripción para acompañarlo? No creo que realmente necesites mostrar ningún html; a todas las personas les preocupa el javascript y la expresión regular. Si reduce su respuesta solo al jacascript y agrega un pequeño comentario para acompañarlo, le daré un voto positivo.
bgmCoder

9

Estaba buscando un Regex en JS que pasa todos los casos de prueba de dirección de correo electrónico:

  • email@example.com Email valido

  • firstname.lastname@example.com El correo electrónico contiene un punto en el campo de dirección

  • email@subdomain.example.com El correo electrónico contiene puntos con subdominio

  • firstname+lastname@example.com El signo más se considera un carácter válido.

  • email@192.0.2.123 El dominio es una dirección IP válida

  • email@[192.0.2.123] El corchete alrededor de la dirección IP se considera válido

  • “email”@example.com Las cotizaciones alrededor del correo electrónico se consideran válidas

  • 1234567890@example.com Los dígitos en la dirección son válidos

  • email@domain-one.example El guión en el nombre de dominio es válido

  • _______@example.com El guión bajo en el campo de dirección es válido

  • email@example.name .name es un nombre de dominio de nivel superior válido

  • email@example.co.jp El punto en el nombre de dominio de nivel superior también se considera válido (usando co.jp como ejemplo aquí)

  • firstname-lastname@example.com El guión en el campo de dirección es válido

Aquí vamos :

http://regexr.com/3f07j

O regex:

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

8

La expresión regular proporcionada por Microsoft dentro de ASP.NET MVC es

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

Que publico aquí en caso de que sea defectuoso, aunque siempre ha sido perfecto para mis necesidades.


1
No permite + en el nombre del correo electrónico.
Paul Go
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.