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

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

Expresión regular para validar la dirección de correo electrónico en javascript?

Mostrar la mejor respuesta

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.

El hecho de que la débil coincidencia de patrones de Javascript no pueda validar completamente una dirección de correo compatible con RFC no significa que nunca pueda resolver esto con un solo patrón. De hecho, puede, y aquí hay dos soluciones que lo hacen.

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. Correcto. 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.

Avatar WoJ

@ Soundfx4: esta debería ser LA respuesta y aceptarse como tal. La comprobación de la exactitud de una dirección es una tontería : la mejor manera de frustrar a los clientes. Solicito que la dirección se escriba dos veces y sugiero que hay algunos problemas posibles (faltan @ , ;com , etc.) y dejo que el usuario los corrija si lo desea (y acepta lo que sea me envian)

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 verificarlo con una simple expresión regular. La única forma de asegurarse de que la dirección es válida es probarla.

patrón = "[a-zA-Z0-9 ._% + -] + @ (?: [a-zA-Z0-9 -] + \.) + [a-zA-Z] {2,4} ‌ "No me parece tan malo (el '4' debería haberse actualizado hace años). Pero estoy de acuerdo en que decirle a la gente que no saben su propia dirección es malo. ¡No es tan malo como decirme que no sé mi propio nombre, que también ha sucedido!

¿Realmente necesitas Javascript para hacer esto (que no deberías estar haciendo)? Aunque tenían dos errores en la expresión, me parece que se mencionó un método mucho más simple en stackoverflow.com/questions/52030222/…

JavaScript puede coincidir con una expresión regular:

emailAddress.match( / some_regex /);
 

Aquí hay una RFC22 expresión regular 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)>)$
 

Parece que el nodo no puede compilar esta expresión regular

Avatar Ry-

@Kato: utiliza algunas extensiones incompatibles, que incluyen (?> para detener el retroceso y (?<angle><)…(?(angle)>) para evitar proporcionar un largo | .

Usar expresiones regulares es probablemente la mejor manera. Puede ver un montón de pruebas aquí (tomado de cromo )

function validateEmail(email) {
    var 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:

var 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) {
  var 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() {
  var $result = $("#result");
  var 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>  

Avatar Jon

¿Alguien podría explicar a qué se enfrentará y qué no? (Dadas algunas de las respuestas adicionales a continuación.) Sería bueno saber un poco más de información para determinar qué 'solución' usar para un proyecto.

+1: Lo único que esto no deja pasar son las IP en lugar de los dominios. Acepta dominios que comienzan o terminan con un guión, y dominios de más de 64 caracteres de longitud, pero aparte de esto, hace un buen trabajo. Salud.

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.

@Randall: ¿Puedes dar un ejemplo de una dirección de correo electrónico que esto no permita?

Esto funciona bien para mí, aunque obtengo un error de compilación ('[') sin escape cuando lo uso con Appcelerator. Sin embargo, no parece causar ningún problema con la validación.

Tenga en cuenta que cualquier IDN tendrá que estar codificado antes de que esta expresión regular los acepte; cualquier IDN de nivel superior válido será rechazado incluso en forma de punycode (ya que el prefijo xn- no coincidirá con [a-zA-Z] ).

¿Por qué en la línea var re = ... ESLint dice: Escapado ']', sin escape '[', los espacios son difíciles de contar, use {2}?

Hay un caso de prueba completo de direcciones de correo electrónico en isemail.info/_system/is_email/test/?all ... (consulte isemail.info para obtener más detalles).

Hay una sección sobre validación RFC2822 en la parte inferior de esta página: regular-expressions.info/email. html

Avatar P.M

a.ert#@example.com pasa :-)

Esto ni siquiera acepta los ejemplos en RFC 822. En algunos casos simples, no coincide 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.

@BenRoberts n @ ai - dirección de correo electrónico válida, en uso, falla

@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.

Me pregunto por qué cuando ingresé lname_fname#@yahoo.com, ¿aceptó el correo electrónico? ¿Qué significa '#' está permitido?

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

El guión bajo (_) debería validarse en primer lugar, supongo.

Ejemplos de direcciones de correo electrónico válidas que están marcadas como inválidas son postbox @ com y user @ [IPv6: 2001: db8: 1ff :: a0b: dbd0] ver es.wikipedia.org/wiki/Email_address#Valid_email_addresses

@Ben es el método genérico integrado en una expresión regular. developer.mozilla.org/en-US/ docs / Web / JavaScript / Reference / ...

Esto pasa por ı@a.aa (ese primer personaje es extraño), que recientemente estropeó nuestro sistema.

@rossipedia ejemplo de direcciones de correo válidas que no analiza? por ejemplo: !#$%&'*+-/=?^_`{}|~@example.org , o postbox@com , o " "@example.org tomado de wikipedia

Para todas las personas que comentan que esto es "suficientemente bueno": miren, simplemente piensan que este problema está mal. Está bien. Es una elección que puede hacer para sus usuarios. No estoy enojado con eso. Pero, ya sabes, técnicamente hablando, estás demostrablemente demostrablemente equivocado.

está roto por nhjh@d.vn.hjhhhkkk :(

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.com son 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.

Para obtener más información sobre qué coincide correctamente (en), consulte la siguiente lista emailtester.pieterhordijk.com/test -pattern / MTA4

@BenRoberts MyFakeEmail@dnedomain.com no existe. Y sin embargo, la expresión regular lo dejará pasar.

Según Wikipedia, también puede existir unicode en el nombre de dominio. var re = ...|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/; debe ser var re = ...|(([^<>()[\]\\.,;:\s@\"]+\.)+[a-zA-Z]{2,}))$/;

Esto valida: "foo@10.0.0.0.com"

Existen otros factores además de RFC822 para determinar cuál puede ser una dirección de correo electrónico; por ejemplo, a@a es RFC822 válido, pero ICANN prohíbe los dominios 'sin punto', por lo que debe considerarse inválido.

Si necesita usar esto con la API de patrones HTML5 en lugar de usar type="email" , necesitará codificar las comillas, por ejemplo. <input pattern="^(([^<>()[\]\\.,;:\s@\&quot;]+(\.[^<>()[\]\\.,;:\s@‌​\&quot;]+)*)|(\&quot‌​;.+\&quot;))@((\[[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,})‌​)$" id="email" name="email" type="text">

En estos días, Javascript se puede ejecutar en un servidor, por lo que para aquellos que piensan que esto solo es relevante para la validación del lado del cliente, están equivocados. Y para aquellos que dicen que no es posible validar un correo electrónico, creo que les falta el punto de validación en general. NUNCA escribirás la validación de un formulario para asegurarte de que todo sea 100% perfecto por dos razones principales: 1. Llevaría más tiempo del que valdría la pena escribir la lógica y 2. Siempre habrá un caso marginal donde los datos incorrectos podría ser enviado La razón por la que validamos es para alentar el envío adecuado de datos y evitar errores.

esto falla para 'ajey@gmail.comsadasd'

Cuidado, esto no es válido: re.test("username+something@gmail.com")

También no válido: test@something.melbourne y otros TLD nuevos.

김지후 @ 삼성. 닷컴 no funcionará aquí, ni ninguna de las nuevas direcciones de caracteres no latinos.

esto no es válido para test + google.com re debería ser: var 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,})) $ /;

Ahora que tenemos dominios como .ninja .photography, etc., agregaría {2,} a la última comprobación: /^([\w-font>+(?:\.[\w-font>+)*)@ ((?: [\ w -] + \.) * \ w [\ w -] {0,66}) \. ([az] ‌ {2,} (?: \. [az] {2} )?) ‌ $ / i

La prueba de @BenRoberts \\\ @ mailinator.com queda en el frío por esta expresión regular :(

@Brian - Gmail y Apple Mail dejan al pobre chico en el frío ... :(

Obviamente no puede validar una dirección de correo electrónico con JavaScript o RegEx. Pero creo que la respuesta demuestra "Aquí hay una forma algo válida de saber si la mezcla de caracteres ingresados ​​en un cuadro de texto de correo electrónico es muy probablemente un formato de correo electrónico. Creo que le da a alguien que haría esta pregunta lo suficiente como para trabajar. Si son de hecho, al validar el correo electrónico turco, deben entender sus límites. De lo contrario, úselo hasta que encuentre un inconveniente e itere, ¡como lo hace cualquier otro programador!

Avatar PSR

Esta validación falla para los ID de correo electrónico de alias de gmail. Ej: firstname.lastname+test@gmail.com

Esa respuesta no acepta un correo electrónico válido de gmail como "foo+bar@gmail.com"

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. Correcto. 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.

En cuanto a "no valida", la primera expresión regular arroja aproximadamente la mitad de esto: es. wikipedia.org/wiki/… , p. ej. piskvor@example.lighting ; tenga en cuenta que se crearon más TLD más allá del tamaño de \.[a-z]{2,8} desde 2011. (Esa es una lista de TLD aprobados por la IANA; no me importa si alguien considera frívolo a .horse , solo me importa si es canónico, y lo es). Editar: Ajá, veo que la expresión regular ha cambiado por completo en marzo.

Esta expresión regular utiliza grupos de captura, ya que no son necesarios en este contexto y puede conducir a problemas de rendimiento.

Prueba 1.2@gmail.com . la expresión regular coincidiría :(

la expresión regular también coincide con d^&fvf#3d@frf.fffffefefe , que supongo que no es una ID de correo electrónico válida.

stream@2x-fab0f8.png = verdadero :)

me's@mess.co.uk.in is valid :) debería ser?

Esta expresión debe actualizarse para no respetar la dirección de correo electrónico utilizando direcciones IP en lugar de nombres de dominio, incluso si son técnicamente correctos.

@ AndersLindén Usando el siguiente enlace para la prueba de la unidad y si la dirección IP no es válida, también tenga en cuenta que no cumple con lo siguiente: correo electrónico @ [123.123.123.123] codefool.tumblr.com/post/15288874550/…

@nwolybug El caso de uso de tener direcciones IP como parte de las direcciones de correo electrónico es tan limitado que debería omitirse.

--@ooo.ooo es una dirección de correo electrónico válida.

No funciona para Abc@10.42.0.1 y Loïc.Accentué@voilà.fr

@Liberateur Como debería. voilà.fr no es un nombre de dominio válido. En particular, el à debe estar codificado con punycode en el nombre de dominio. No sé la codificación real de punycode, pero algo como Loïc.Accentué@voil--xa.fr validará ... como debería.

¿Hice algo mal: nuevo RegExp ('^ (([^ <> () [] \.,;: \ S @ \ "] + (\. [^ <> () [] \. ‌,; : \ s @ \ "] +) *) | (\". + \ ‌ ")) @ (([^ <> () [] \. ‌,;: \ s @ \"] + \. ) + [^ <> () ‌ [] \.,;: \ S @ \ "] {2, ‌}) $ ',' i '). Test ('test@test.com') return false ?

Esta no es una expresión regular válida, por ejemplo, æææ@gmail.com pasa la expresión regular

No funciona con findEmailInStr ("sdf ll \ ud83c \ uddeb \ ud83c \ uddf7email@gmail.com sdkf")

@ AndersLindén - P: ¿Qué es peor que un código con errores que les dice a las personas que no conocen su propia dirección? R: Decirle a alguien que debe rechazar INTENCIONALMENTE direcciones válidas.

Todos estos patrones muestran una línea roja ondulada debajo de algunos caracteres. ¿por qué?

Gracias por compartir, pero su código no es estándar para "RFC822" o "RFC2822".

Esta expresión regular rechaza direcciones de correo electrónico válidas en un nombre de dominio internacionalizado.

Recomiendo encarecidamente utilizar la expresión regular sugerida por WDC html.spec .whatwg.org / multipage / input.html # valid-e-mail-addre‌ ss

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.

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

La versión modificada de Squirtle a continuación parece ser la solución más efectiva en la página. Puede validar todo lo que quiera, pero aún puedo ingresar una dirección de correo electrónico "@ gmaaaail.com".

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, por lo que cosas como yo @ aquí, yo @ aquí @ y yo @ herecom no son válidas ... ^ \ S + @ \ S + [\.] [0-9a-z ] + $

Avatar Sam

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

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

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

@ MladenJanjetović Sí, la respuesta indica específicamente que esto no está completo. Sin embargo, es la mejor respuesta. Nadie necesita una validación de correo electrónico "completa" en el front-end. Debe detectar los errores tipográficos obvios y luego enviar un correo electrónico de confirmación.

@meagar Puedes estar seguro de que la gente comete ese tipo de errores;)

@TimmyFranks Bad regex. Además del punto menor, no necesita escapar del punto entre paréntesis, invalida los caracteres en mayúscula que son válidos, por lo que obtendrá usuarios enojados (¡yo, ya que me gusta usarlos cuando escribo mis direcciones!) ... Además, es demasiado restrictivo ya que foo @ [192.168.1.12] es una dirección de correo electrónico válida ...

@TimmyFranks En una nota más positiva, tienes razón en el comentario sobre a @ b @ (un error tipográfico que podría ocurrir) y en el anclaje de la expresión regular. Una mejora (aún muy permisiva) sería /^.+@\S*(?!@).$/ . El punto ni siquiera es necesario: una dirección en una red local puede ser foo @ machinename (¡tenemos este caso en nuestra red!).

Es tan molesto que cada vez que mencionas la validación del correo electrónico, tienes al 99% de las personas que vuelan fuera de control sobre cómo no es preciso usar una expresión regular, etc. ¡Gente, no estamos tratando de averiguar si esta es una dirección de correo electrónico real! ¡Estamos tratando de determinar si la sintaxis es correcta!

| _ @ _ | - ¿correo electrónico válido?

Si bien me encanta la simplicidad como un enfoque de "verificación de sentido", solo una observación de que envolverlo con ^ ... $ como sigue ^ \ S + @ \ S + $ es una mejora con respecto a lo anterior, ya que requiere una dirección de correo completa para cumplir, no solo parte de eso.

Modificación leve para cubrir más casos como "asd @ asd" \S+@{1}\S+\.{1}\S+

@meagar ("áéíóúý @ ÁÉÍÓÚÝð") son tan posibles de ingresar al campo de texto mientras se usan los teclados de los teléfonos móviles.

/\S+@\S+/ también funciona en campos en blanco ... ¡no es bueno!

Hay algo que debe entender en el momento en que decida usar una expresión regular para validar correos electrónicos: Probablemente no sea una buena idea . Una vez que haya llegado a un acuerdo con eso, hay muchas implementaciones que pueden llegar a la mitad del camino, esto el artículo los 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.

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

@PaoloBergantino quiero decir que, ¿por qué debería intentar enviar un correo para verificar una dirección de correo obviamente incorrecta? incluso si necesito "estar absolutamente seguro de que lo que el usuario ingresó es en realidad un correo electrónico", solo verificaría las direcciones de correo electrónico que coincidan con la expresión regular

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

La segunda expresión regular en la respuesta del viajero en stackoverflow.com/a/1373724/69697 es práctica para su uso y casi no debería ser falsa 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.

@StephenP tiene razón. Es prácticamente imposible encontrar una expresión regular que coincida con todos los correos electrónicos válidos. Además, los formatos de dirección de correo electrónico pueden cambiar.

@kommradHomer - "¿por qué querría pasar mi tiempo validando un ..." ¿Eh? ¿Pasar el tiempo? ¡Por supuesto que no, tonto! Escribirías un código para hacer eso por ti. Y luego sabría si tenía una dirección válida sin riesgo de alienar a los usuarios. ¡Eso es muy bonito! O puede poner mala cara y definitivamente usar una solución rota. No estoy enojado con eso. Son tus usuarios.

@StephenP "una dirección 'regex inválida' es casi siempre válida, porque cualquier regex que use para validar una dirección de correo electrónico es casi seguramente incorrecta y excluirá direcciones de correo electrónico válidas" Creo que este argumento es lógicamente defectuoso. Las personas ingresan todo tipo de cosas no válidas en los formularios.

@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, solo porque tengo un dominio .us o porque Usé un + a la izquierda del @ : muchos lugares han solucionado estos errores atroces, pero la parte local (a la izquierda de @) puede ser cualquier cosa el propietario del dominio quiere. -> "foo@bar.com"@example.com <- es una dirección de correo electrónico válida.

¿No hay absolutamente ninguna manera de saber si una dirección de correo electrónico es válida sin enviar un correo electrónico? ¿No hay ningún tipo de registro central en DNS en el que se acumulen todas las direcciones de correo electrónico utilizadas y, por lo tanto, se pueda consultar la existencia de una dirección de correo electrónico determinada?

@Cupidvogel: Por desgracia, no vivimos en ese mundo.

@ AttitudeMonger: una base de datos de este tipo podría contener miles de millones de miles de millones de direcciones de correo electrónico, por lo que la búsqueda sería lenta. Tampoco hay forma de forzar el registro de direcciones de correo electrónico para mantener un registro actualizado, ni para que los usuarios se aseguren de que su dirección de correo electrónico esté registrada. Por lo tanto, cualquier registro central de este tipo fallará y, en última instancia, será peor que una expresión regular (o simplemente enviando un correo electrónico y viendo si se entrega y recibe una respuesta).

@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: thisisafakeemailbutitwillwytttididgegexcheck @ regexcheck‌ sareretarded.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 ...

Creo que a esta discusión le falta la distinción entre una dirección de correo electrónico sintácticamente válida y una que realmente recibe correo. La otra cosa que estamos pasando por alto es que en realidad hay una especificación técnica para lo que califica como una dirección de correo electrónico válida. El problema es que la mayoría de los sitios web crean su propia lógica de validación basada en suposiciones ingenuas, en lugar de implementar los requisitos.

Lo siento, pero esta no es una gran respuesta. -1 "y ver qué pasa"? ¿Cómo vas a saber si un usuario recibió el correo electrónico o no? Además, algo podría ser un correo electrónico sintácticamente válido incluso si nadie posee un buzón con esa dirección. Además, si está validando la entrada del usuario, no debería hacer llamadas de red lentas como parte de la validación. Además ...

Esto filtra los dominios .museum y .travel cada vez más populares (debido al límite de 4 caracteres después de . )

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

@Anton N: Tiene aproximadamente una gran cantidad de otros problemas también; el {2,4} final 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 de + en la parte local; este cuadro de comentarios es demasiado pequeño para señalar todos los errores cometidos anteriormente.

Avatar MT.

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

@Piskvor: después de agregar el + y eliminar una barra invertida redundante y ditto plus al final, no puedo encontrar nada malo en ello. Vea esta demostración: codepen.io/anon/pen/lzJtB?editors=100. Si aún encuentra alguna deficiencia, me complacerá saber cuál.

@FrankConijn: Bueno, para empezar, eche un vistazo a esta lista y luego dígame: ¿cómo va a tratar esa expresión regular las direcciones en el TLD de Singapur (.新加坡 ) como válidas, por ejemplo? en.wikipedia.org/wiki/List_of_Internet_top-level_domains Este no es el Internet de su abuelo. más; e incluso el internet de tu abuelo permitió una gama de caracteres mucho, mucho más amplia en la parte local. En otras palabras, esta expresión regular es demasiado estricta e informará falsos negativos en direcciones de correo electrónico completamente válidas.

@AntonN: ahora tenemos más de 10 caracteres de TLD (xn--clchc0ea0b2g2a9gcd ). ¿Todavía no es un problema?

Esto me gusta más: var re = /^[0-9a-zA-Z.,+\-_]+@[0-9a-zA-Z.\-]+\.[a-zA-Z]+$/; Para mí, si una dirección de correo electrónico contiene caracteres unicode, prácticamente indica un error. (también soy de un país de habla inglesa no nativo, así que estoy lidiando con tales errores a diario). Por lo tanto, es una buena idea filtrar los caracteres acentuados.

Esto permite: tes.t. @ example.com

/^[a-zA-Z0-9font>([a-zA-Z0-9_\.\-font>)+[a-zA-Z0-9font>\@(([a-zA-Z0-9\- ] ‌) + \.) + ([A-zA-Z0-9] {2‌, 6}) + $ / esto no permite: tes.t. @ example.com o .tes.t. @ ejemplo.com

Siguiendo la expresión regular:

/^([\w]+)(.[\w]+)*@([\w]+)(.[\w]{2,3}){1,2}$/;
 

Eso no coincide con el RFC.

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 un nuevo RegExp , simplemente intente escribir el regexp de esta manera:

if (reg.test(/@/))
 

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

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. Puedes ( pero no debes - sigue leyendo ) impleméntelo 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 hacer 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 como asdf@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 si se siguen los estándares 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.

Énfasis mío

NB: "En uso real hoy " puede haber sido válido cuando se escribió el código, en 200x. El código probablemente seguirá 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;))

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] /

Además, la primera parte debe ser (?: [A-z con una A mayúscula para evitar falsos negativos cuando un usuario capitaliza su dirección de correo electrónico.

Utilizando la "implementación práctica", me encontré con un problema en Safari: si la parte de la dirección que coincide después de @ es de 32 caracteres o más, la prueba de expresiones regulares fallará. Esto se debe a este límite del analizador webkit: github.com/WebKit/webkit/blob/master/Source/JavaScriptCore/… ‌. Tenga en cuenta que este es solo el caso al definir la expresión regular de la siguiente manera: var email_re = new RegExp("[a-z ...0-9])?", "i"); (en lugar de var email_re = new RegExp(/[a-z ...0-9])?/i); Agregar un \` before each de escape adicional también soluciona el problema. + @ Cal por sugerir esta solución!

Con la especificación, d._.___d@gmail.com no es un correo electrónico válido, pero aún así detecta que es correcto.

@DonRolling No hagas eso. Eso no solo significa "A a Z, a a z", sino que también significa "[\] ^ _` "porque esos son entre " Z "y" a ". Use \w , o mejor, simplemente ponga 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.

Estoy usando este con la siguiente modificación: [a-z0-9! # $% & '* + / =? ^ _ {|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_ {|} ~ -] +) ‌ * @ (? : [a-z0-9] (?: [a-z‌ 0-9 -] * [a-z0-9])? \.) + ‌ (?: [a-zA-Z] {2} | com | o‌ rg | net | gov | mil | biz | i‌ nfo | mobi | nombre | aero | j‌ obs | museo) \ b Modificación agregada az para el final para permitir .au, .it y muchos niveles superiores dominios de país que usan dos caracteres en minúscula. Me gustaría saber por qué esto no estaba incluido.

@willFarrell, además de evitar dominios de nivel superior de un solo carácter (alguien@ejemplo.c), ¿no deberíamos también evitar dominios de un solo carácter (alguien@e.com)? eso le da [a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]‌​+)*@(?:[a-z0-9][a-z0‌​-9-]*[a-z0-9]\.)+[a-‌​z0-9][a-z0-9-]*[a-z0‌​-9] . Además, tenga cuidado con lo que Markdown le está haciendo a su expresión regular, ¡se ha comido algunos de sus backticks ("` ")! ¡También el tuyo @nwolybug!

La segunda expresión regular "99.99% correspondiente" no evita me@domain.fr. o .me@domain.fr , que puede ser un simple error de escritura y no es válido, supongo que si el punto "aparece como primer o último carácter " ¿derecho?

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

Descubrí que tenía que cambiar todo a-z a a-zA-Z.

@MadeInMoon Tampoco evita espacios y múltiples signos @. asdasd asdasd @asdasd@gmail.com es válido

Esto permite espacios como todas las siguientes cadenas sdf @ fdsfsdf sdfsdfdf @ klk@com.c

permite %20f3v34g34@gvvre.com? No creo que sea válido comenzar con%

El del medio no permite direcciones locales: P hello@localhost = false

Buena respuesta. Creo que la implementación práctica de RFC 2822 es mejor como validación de expresiones regulares. Porque solo el proveedor de servicios de correo electrónico puede decir que las direcciones de correo electrónico son válidas o no. Lo que podemos hacer con regex es verificar las validaciones generales. Nadie puede validar al 100% todas las direcciones de correo electrónico utilizando expresiones regulares. Porque diferentes proveedores de correo electrónico tienen sus diferentes métodos de validación.

Aquí hay una muy buena discusión sobre el uso de expresiones regulares para validar direcciones de correo electrónico; " Comparación de direcciones de correo electrónico Validación de 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
 

-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).

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

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

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

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. ¿Derecho?

Aparentemente, eso es todo:

/^([\w\!\#$\%\&\'\*\+\-\/\=\?\^\`{\|\}\~]+\.)*[\w\!\#$\%\&\'\*\+\-\/\=\?\^\`{\|\}\~]+@((((([a-z0-9]{1}[a-z0-9\-]{0,62}[a-z0-9]{1})|[a-z])\.)+[a-z]{2,6})|(\d{1,3}\.){3}\d{1,3}(\:\d{1,5})?)$/i
 

Tomado de http://fightingforalostcause.net/misc/2006/compare- email-regex.php el 1 de octubre de 2010.

Pero, por supuesto, eso ignora la internacionalización.

Se olvidaron de escapar del @ .

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. JavaScript / node.js port: 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 parece 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 parece 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 . ya que @ no puede ser parte del nombre del servidor (hasta ahora como sé).

  • 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 para que " esté 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?

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.

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

No debería lastIndexOf () debería devolver -1 si no encuentra la aguja.

Avatar Ry-

"Incluso si @ aparece como el último carácter en el nombre de usuario del correo electrónico, debe citarse para que " esté entre ese @ y el último @ en la dirección ". ¿Qué pasa con "@@"@example.com ?

"@@"@example.com es válido.

test @ .ds también es válido (?)

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

jsFiddle enlace

De la especificación HTML5 :

  

Una dirección de correo electrónico válida es una cadena que coincide con la producción de email del siguiente ABNF, cuyo conjunto 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 las direcciones de correo electrónico que es a la vez 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 de citas de maneras desconocidas) para la mayoría de los usuarios) para ser de uso práctico 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])?)*$/
 

esto es bueno, pero el problema con esto es que debe estar dentro de una etiqueta form y enviado por una entrada submit , que no todos pueden darse el lujo de hacer. Además, realmente no puede diseñar el mensaje de error.

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.

Avatar tim

también algunas personas (como yo) ya no usan etiquetas input y confían en contenteditable en las etiquetas estándar div .

a@a.a se valida en FF22

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

El tipo de campo de correo electrónico HTML5 acepta correos electrónicos como usuario @ correo electrónico

Este regex es el que uso y puedes verlo pasando todos los Pruebas de cromo mencionadas en la respuesta aceptada aquí .

Tenga en cuenta el comentario de @ Puce: la entrada de correo electrónico HTML 5 acepta user@email mientras que, por ejemplo, el filter_var de PHP no. Esto puede causar problemas.

Nunca es una buena idea confiar solo en la validación del lado del cliente. Hay muchas formas de introducir valores incorrectos en la aplicación del servidor.

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 entiendes 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 ...

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

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

Una de las mejores respuestas para esta pregunta. Nunca debe bloquear a ningún usuario debido a una dirección de correo electrónico "extraña". Siempre es mejor intentar enviar un correo a la dirección y solicitar al usuario que haga clic en un enlace de activación, si desea asegurarse de que un correo electrónico sea válido.

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

+1: si el objetivo es asegurarse de que el usuario haya intentado al menos ingresar una dirección de correo electrónico, verificando si se puede determinar 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.

@cazlab: ¿Cuál es su caso de uso para saber si la dirección de correo electrónico del usuario es válida sin enviarles un correo electrónico y ver qué sucede? ¿De qué crees que una expresión regular puede protegerte?

@lwburk si no desea enviar correos electrónicos innecesariamente al éter. "its @ u" pasaría esta "validación". No considero este ejemplo como una validación, lo siento.

+1, aunque el txt.length > 0 && es redundante debido a la segunda prueba. En cualquier caso, el punto es dar un poco de retroalimentación rápida al usuario, al mismo tiempo que evita algunos golpes al servidor cuando sea posible. Nadie que sepa algo en realidad depende únicamente de JavaScript para su validación.

+1 no porque me guste su solución (como dice @cookiemonster, la longitud> 0 es una prueba tonta ya que un correo electrónico RFC mínimo válido es de al menos 3 caracteres, una dirección de correo electrónico REAL enrutable de Internet es al menos 5) pero estoy de acuerdo , siempre se prefiere una solución simple, y la ÚNICA forma de validar verdaderamente un correo electrónico es enviar un correo electrónico. Siempre me encanta leer estos argumentos semánticos entre soplones que pueden emitir estándares y no pueden codificar en el mundo real para salvar sus vidas. ¡Gracias!

He modificado ligeramente la respuesta de Jaymon para las personas que desean 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);
}
 

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!

@ImmortalFirefly, la expresión regular que proporcionó coincidirá con 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')

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

una de mis direcciones de correo electrónico es damiann @ dragon, esto no permite el caso de máquinas que son visibles para el servidor web / correo electrónico directamente.

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

¿No permite esto también @@@.@ ? :RE

Avatar tk_

'/\S+@\S+\.\S+/.test('name@example.-com') '' verdadero '

Creo que la peor parte de esta solución simple es que solo prueba que el patrón está contenido . Por supuesto, no queremos terminar con una expresión regular exagerada, pero al menos hacerlo relevante y agregar esos controles de inicio y fin: /^...$/ - No es que fuera más difícil de escribir ... Descartar los signos @ adicionales también son una buena idea

OregonTrail sus expresiones regulares pasan a@b._com , a@b_.com para ser verdad

He combinado las respuestas en la página para lograr el espíritu de validación front-end: detectar errores comunes de los usuarios. Aquí está mi expresión regular: /^[^\s@#!]+@[^\s@.#!]+.[^\s@.]+$/ es un poco más complejo, pero específicamente requiere uno y solo uno @ y . en ese orden y evita los caracteres # y ! a cada lado del @ . Solo excluyo esos porque es posible golpearlos accidentalmente al presionar @ . no es exhaustivo, pero atrapa a @ b..com o a@#b.com, etc.

En contraste con squirtle , esta es una solución compleja, pero hace un trabajo excelente y valioso 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);
} 
 

Usar así:

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

No necesita el == true en su ejemplo.

La solución de Sectrean funciona muy bien, pero estaba fallando mi linter . Entonces agregué algunos escapes:

function validateEmail(email){ 
     var 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); 
}
 

validateEmail ("e_mail@sth.com") y validateEmail ("e.mail@sth.com") ambos devuelven el valor false

function validateEmail(elementValue){        
    var emailPattern = /^[a-zA-Z0-9._]+[a-zA-Z0-9]+@[a-zA-Z0-9]+\.[a-zA-Z]{2,4}$/;  
    return emailPattern.test(elementValue);   
  }   
 

Devuelve verdadero si la dirección de correo electrónico es válida. De lo contrario, devolverá falso.

Haz 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 correo electrónico TODO estándar las direcciones DEBEN adherirse. 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 i al 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 y cuando esté escrito entre comillas). NADIE HACE ESTO NUNCA! Es obsoleto Pero, ESTÁ incluido en el verdadero RFC 2822 , y se omite aquí.

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

@Kondal, el código de JavaScript no distingue entre mayúsculas y minúsculas debido al indicador /i al final 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.

Funcionó para mí como un encanto

En los navegadores modernos puedes construir sobre la respuesta de @ Sushil con JavaScript puro y el 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 , te libera de la masacre de expresiones regulares y no molesta en navegadores antiguos.

Esta es una idea inteligente para resolver el problema, pero no funciona porque los navegadores también tienen una validación deficiente. P.ej. .@a se valida como true en las versiones actuales de Chrome, Firefox y Safari.

@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.

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.

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

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.

Curiosamente, este código devuelve verdadero para cadenas vacías. Lo edité para agregar una comprobación de cadena nula y vacía.

Sí, porque se permiten valores vacíos si no se requiere una entrada. También puede establecer input.required = true para el mismo efecto.

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

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ápida.

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
 

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

@BGM: ¿Prefieres tener una hermosa función que no funciona?

@Piskvor No, prefiero tener una función hermosa que funcione. ¿Que pasa contigo?

@BGM: adelante y edite, entonces. La respuesta es, después de todo, marcada como "wiki de la comunidad".

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

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.

IE <10 no admite esto, y tampoco el navegador de Android.

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

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 con RFC, eso no le indicarí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.

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

Perfecto, esta respuesta fue simple, solo una validación de capa adicional. ya tiene una capa en la parte frontal, así que esto ayuda, gracias

Esta es, de lejos, la mejor respuesta de la OMI. Lo suficientemente bueno como para captar la mayoría de las entradas accidentales (es decir, la mayoría de las cosas que no son direcciones de correo electrónico) sin falsos negativos.

Si usa Closure, puede usar el tipo goog.format.EmailAddress incorporado:

  

http: //docs.closure-library.googlecode.com/git/class_goog_format_EmailAddress.html

Por ejemplo:

goog.format.EmailAddress.isValidAddrSpec("blah@blah.com")
 

Tenga en cuenta que al leer la fuente (vinculada anteriormente) puede ver que los comentarios indican que IDN no son compatibles y que solo apunta a cubrir la mayoría direcciones:

// This is a fairly naive implementation, but it covers 99% of use cases.
// For more details, see http://en.wikipedia.org/wiki/Email_address#Syntax
// TODO(mariakhomenko): we should also be handling i18n domain names as per
// http://en.wikipedia.org/wiki/Internationalized_domain_name
 

Así es como node-validator lo hace:

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

W3Schools proporciona un buen script simple y eficiente para validar un correo electrónico:

function validateEmail(email) {
    var atpos=email.indexOf("@");
    var dotpos=email.lastIndexOf(".");
    if (atpos < 1 || dotpos < atpos+2 || dotpos+2 >= email.length) {
        alert("Not a valid e-mail address");
        return false;
    }
    return true;
}
 

Tenga en cuenta que tendrá que eliminar espacios si los hay, con algo como esto:

.replace(/ /g,'')
 

Fuente: Validación de formulario JavaScript

abc@xyz es un correo electrónico perfectamente válido que su expresión regular no reconoce.

No es mi expresión regular, es la expresión regular de w3schools, y para una simple validación de correo electrónico, siempre que prefiera ser demasiado restrictivo que no lo suficiente, simplemente funciona. Si desea el paquete completo, use la solución de Voyager.

Sin embargo, bastante horrible, validará muchos correos electrónicos incorrectos, es decir, algo como d @@. Com será válido.

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
}
 

abc@xyz es un correo electrónico perfectamente válido que su expresión regular no reconoce.

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.

Digo que el correo electrónico tiene: dominio local-parte @. Y ahí está '.' en la parte del dominio

¿Puede citar un correo electrónico válido válido de tipo something @ something?

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

Bueno, nunca me he encontrado con ese correo electrónico, la verificación anterior funciona bien conmigo. Si no lo desea, simplemente elimine los dotpos y la cláusula relacionada. Entonces funcionará para abc @ xyz. Sugeriría verificar el correo electrónico con un enlace si desea estar tan seguro. davidcel.is/blog/2012/09 / 06 / ...

Y la API de validación de JQuery tampoco acepta correos electrónicos de tipo abc @ xyz

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.

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.

No permite + en el nombre del correo electrónico.

<pre>
**The personal_info part contains the following ASCII characters.
1.Uppercase (A-Z) and lowercase (a-z) English letters.
2.Digits (0-9).
3.Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
4.Character . ( period, dot or fullstop) provided that it is not the first or last character and it will not come one after the other.**
</pre>
*Example of valid email id*
<pre>
yoursite@ourearth.com
my.ownsite@ourearth.org
mysite@you.me.net
xxxx@gmail.com
xxxxxx@yahoo.com
</pre>
<pre>
xxxx.ourearth.com [@ is not present] 
xxxx@.com.my [ tld (Top Level domain) can not start with dot "." ]
@you.me.net [ No character before @ ]
xxxx123@gmail.b [ ".b" is not a valid tld ]
xxxx@.org.org [ tld can not start with dot "." ]
.xxxx@mysite.org [ an email should not be start with "." ]
xxxxx()*@gmail.com [ here the regular expression only allows character, digit, underscore and dash ]
xxxx..1234@yahoo.com [double dots are not allowed
</pre>
**javascript mail code**

    function ValidateEmail(inputText)
    {
    var mailformat = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/;
    if(inputText.value.match(mailformat))
    {
    document.form1.text1.focus();
    return true;
    }
    else
    {
    alert("You have entered an invalid email address!");
    document.form1.text1.focus();
    return false;
    }
    }
 

Muy simple en JavaScript . sigue este código.

function validate(){
    var email = document.getElementById('Email');
    var filter = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/;

    if (!filter.test(email.value))
    {
        alert('Please Enter the valid email address');
        email.focus;
        return false;
    }
    else
{
        return true;
    }
 
Código

HTML para esto:

form name="form"
     enctype="multipart/form-data"
     name="form"
     action="register.php"
     method="POST" onsubmit="return validate();" >
    <input type="text" placeholder="Enter ur Email Id" id="Email" name="Email" />
    <input type="submit" id="submit" value="save" name="Like" class="button" />
</form>
 

Este filtro invalida muchas direcciones de correo electrónico válidas comunes ... Por ejemplo: user+tag@gmail.com

Uno de mis compañeros de trabajo compartió esta expresión regular conmigo. Me gusta mucho.

function isValidEmailAddress (email) {
    var validEmail = false;
    if (email) {
        email = email.trim().toLowerCase();
        var pattern = /^[\w-']+(\.[\w-']+)*@([a-zA-Z0-9]+[a-zA-Z0-9-]+(\.[a-zA-Z0-9-]+)*?\.[a-zA-Z]{2,6}|(\d{1,3}\.){3}\d{1,3})(:\d{4})?$/;
        validEmail = pattern.exec(email);
    }

    return validEmail;
}

if (typeof String.prototype.trim !== 'function') {
    String.prototype.trim = function() {
        return this.replace(/^\s+|\s+$/g, '');
    };
}
 

function validatecontactEmail(email) { 

 if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(email))  
  {  
    return (true)  
  }  

    return (false)  

}
 

¿Qué tal solo return /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(email) ?

Aquí hay una función que uso para la validación de correo electrónico front-end. (La expresión regular vino de parsley.js)

<!DOCTYPE html>
<html>
<head>
    <title>Our Company</title>
    <style>
        .form-style {
            color: #ccc;
        }
    </style>
</head>
<body>
    <h1>Email Validation Form Example</h1>
    <input type="text" name="email" id="emailInput" class="form-style">
    <script>
        function validateEmail(emailAddress) {
            var regularExpression = /^((([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]))){2,6}$/i;
             return regularExpression.test(emailAddress);
        }

        function showEmailValidationState(event) {
            if (validateEmail(event.target.value)) {
                document.getElementById("emailInput").style.color = 'black';
            }
        }
    document.getElementById("emailInput").addEventListener("keyup", showEmailValidationState);
    </script>
</body>
</html>
 

Me encantan las expresiones regulares, pero no para la validación de correo electrónico. ¡Diviértete depurando eso si alguien encuentra un problema con él!

He estado utilizando la validación de 3 etapas para el correo electrónico. Primero, uso HTML5 con type = email required. El segundo es una expresión regular JS que se muestra arriba, luego el último es el lado del servidor.

@ ceros, salvo que use type="text" aquí, no type="email" : - /

Sí, eso es correcto, encuentro la validación HTML5 molesta.

Si está utilizando AngularJS, simplemente agregue type="email" al elemento de entrada:

  

https://docs.angularjs.org/api/ng/ input / input% 5Bemail% 5D

En caso de que no haya un elemento de entrada, se puede crear dinámicamente:

var isEmail = $compile('<input ng-model="m" type="email">')($rootScope.$new()).
    controller('ngModel').$validators["email"];

if (isEmail('email@gmail.com')) {
  console.log('valid');
} 
 

Pero, ¿qué es esta función de analizador de correo electrónico? ¿Podría publicarlo para que uno pueda usarlo sin angular?

Sí, si va a publicar una respuesta de recuadro negro, desenterre el RegEx detrás de la función del analizador de correo electrónico y muéstrenos qué está usando.

Regex de validación para correo electrónico:

var rex_email = /^(([^<>()[\]\\.,;:\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,}))$/;

if(email=="") {
    window.plugins.toast.showShortBottom( "Please enter the details. ", function(a) {
        console.log('toast success: ' + a);
    }, function(b) { });
} else if(!rex_email.test(email)) {
    window.plugins.toast.showShortBottom( "Please enter the valid email id. ", function(a) {
        console.log('toast success: ' + a);
    }, function(b) { });
}
 

Esto funcionará para direcciones de correo electrónico básicas muy comunes, pero hay ciertos casos extremos en los que esto rechazará direcciones de correo electrónico válidas. Si ha leído las otras 36 (!) Respuestas aquí, ya lo habría sabido.

Sé que no es regex pero de cualquier manera ...

Este es un ejemplo con el nodo y el paquete npm email-existencia esta es la verificación final si correo electrónico existe y si está en la forma correcta :)

Esto hará ping al correo electrónico si responde si no recibe respuesta, devolverá falso o si no es verdadero.

function doesEmailExist(email) {
    var emailExistence = require('email-existence');
    return emailExistence.check(email,function (err,status) {
            if (status) {
                return status;
            }
            else {
                throw new Error('Email does not exist');
            }
        });
}
 

Siguiendo las validaciones de expresiones regulares:

  • No hay caracteres espaciales antes de @
  • (-) y (.) no deben estar juntos después de @ No hay caracteres especiales después de @ 2 caracteres deben ser antes de @ La longitud del correo electrónico debe ser inferior a 128 caracteres
function validateEmail(email) {
var chrbeforAt = email.substr(0, email.indexOf('@'));
if (!($.trim(email).length > 127)) {
    if (chrbeforAt.length >= 2) {
        var re = /^(([^<>()[\]{}'^?\\.,!|//#%*-+=&;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?/;
        //var re = /[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?/;
        return re.test(email);
    } else {
        return false;
    }
} else {
    return false;
}
}
 

Terminé usando este, funciona mejor para mis necesidades y principalmente secuestré la parte del usuario y usé algo más para la coincidencia después del signo @ porque necesitaba que mi implementación solo permitiera a los usuarios de un dominio específico. ¡Pero este es inteligente!

Siguiendo las validaciones de expresiones regulares:

  • No hay caracteres espaciales antes de @
  • (-) y (.) no deberían estar juntos después de @
  • No se necesitan caracteres especiales después de @ 2 caracteres antes de @
  • La longitud del correo electrónico debe ser inferior a 128 caracteres

    function validateEmail(email) {
        var chrbeforAt = email.substr(0, email.indexOf('@'));
        if (!($.trim(email).length > 127)) {
            if (chrbeforAt.length >= 2) {
                var re = /^(([^<>()[\]{}'^?\\.,!|//#%*-+=&;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?/;
                return re.test(email);
            } else {
                return false;
            }
        } else {
            return false;
        }
    }
    

\b[a-z][\w\d_\.]+@\w+\.[a-z]{2}[a-z]?\.?[a-z]{,2}\s
 

Permite:

abcxyz123@qwert.com    
abc123xyz@asdf.co.in   
abc1_xyz1@gmail1.com   
abc.xyz@gmail.com.in
 

Buen intento: 2 actualizaciones aquí: para rangos de coincidencia, proporcionamos {min,max} . Un min en blanco es un error, pero puede tener un max en blanco. Quiero decir que [a-z]{,2} está mal, escriba como {0,2} . Además: su expresión regular muestra kamal@_gmail.com como válido, ¡lo cual no lo es!

el mejor: D (compatible con RFC y sin error "demasiado complejo"):

function    isMail(mail)
{
    pattuser = /^([A-Z0-9_%+\-!#$&'*\/=?^`{|}~]+\.?)*[A-Z0-9_%+\-!#$&'*\/=?^`{|}~]+$/i;
    pattdomain = /^([A-Z0-9-]+\.?)*[A-Z0-9-]+(\.[A-Z]{2,9})+$/i;

    tab = mail.split("@");
    if (tab.length != 2)
        return false;
    return (pattuser.test(tab[0]) && pattdomain.test(tab[1]));
}
 

El usuario permite espacios, ¿qué es exactamente lo que está permitiendo allí?

tienes razón, olvidé que no los estoy aceptando en este

Si quiere usar Jquery y quiere tener un enfoque moderno, use la máscara de entrada JQuery con validación.

http://bseth99.github.io/projects/ jquery-ui / 5-jquery-masks.html

Demostración de cuán simple es la máscara de entrada jquery aquí: http://codepen.io/anon/pen/ gpRyBp

Ejemplo de máscara de entrada simple para ejemplo de fecha NO validación completa

 <input id="date" type="text" placeholder="YYYY-MM-DD"/>
 

y el script:

 $("#date").mask("9999-99-99",{placeholder:"YYYY-MM-DD"});
 

La mejor práctica es usar la etiqueta de correo electrónico HTML5 incorporada.

<input type="email" name="email">
 

o la sintaxis de correo electrónico común como reconocimiento de @ y. de la cadena se da a continuación.

^[a-zA-Z0-9_\-.]+@[a-zA-Z0-9\-]+\.[a-zA-Z0-9\-.]+$
 
  

Tenga en cuenta que esto aún generaría correo electrónico no válido que aún coincidirá   la expresión regular, es casi imposible atraparlos a todos, pero esto lo hará   mejorar un poco la situación.

De acuerdo con su expresión regular "_.............. kamal@gmail.com" es válido, ¡lo cual no debería ser!

Eso es lo que dije en la nota

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, al tiempo 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.

Permite los siguientes formatos:

, pero son tan raros que estoy feliz de hacer esto. 

Permite los siguientes formatos:

1.  prettyandsimple@example.com
2.  very.common@example.com
3.  disposable.style.email.with+symbol@example.com
4.  other.email-with-dash@example.com
9.  #!$%&'*+-/=?^_`{}|~@example.org
6.  "()[]:,;@\\\"!#$%&'*+-/=?^_`{}| ~.a"@example.org
7.  " "@example.org (space between the quotes)
8.  üñîçøðé@example.com (Unicode characters in local part)
9.  üñîçøðé@üñîçøðé.com (Unicode characters in domain part)
10. Pelé@example.com (Latin)
11. δοκιμή@παράδειγμα.δοκιμή (Greek)
12. 我買@屋企.香港 (Chinese)
13. 甲斐@黒川.日本 (Japanese)
14. чебурашка@ящик-с-апельсинами.рф (Cyrillic)

It's clearly versatile and allows the all-important international characters, while still enforcing the basic anything@anything.anything format. It will block spaces which are technically allowed by RFC 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, al tiempo 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.

Permite los siguientes formatos:

, pero son tan raros que estoy feliz de hacer esto. 

Esto es exactamente lo que estoy haciendo. Todas estas respuestas "complicadas" producen problemas: o 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 el frontend (no para uso de causa de backend) 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 escribir mal @ como . (o viceversa). De hecho, tenemos que ser mucho más restrictivos en el lado del servidor.

Por alguna extraña razón, username@domain.com no funciona con este patrón

De acuerdo con su expresión regular "_.............. kamal@gmail.com" es válido, ¡lo cual no debería ser!

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

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

Probado para regex.test ("john-appleseed@mac.com") y regex.test ("anna-haro@mac.com"). El primero mostró falso y el último verdadero, así que algo está mal con la expresión regular que mencionas.

@ spa900 ambos me dan la verdad

Esta expresión regular evita nombres de dominio duplicados como abc@abc.com.com.com.com, solo permitirá el dominio dos veces como abc@abc.co.in. Tampoco permite la introducción desde un número como 123abc@abc.com

regexp: /^([a-zA-Z])+([a-zA-Z0-9_.+-])+\@(([a-zA-Z])+\.+?(com|co|in|org|net|edu|info|gov|vekomy))\.?(com|co|in|org|net|edu|info|gov)?$/,  
 

Todo lo mejor !!!!!

¿Por qué querrías usar algo como esto? La especificación de estándares de dirección de correo electrónico sugiere que las direcciones de correo electrónico pueden comenzar con dígitos y pueden contener múltiples caracteres de punto tanto en el dominio como en la parte lcoal. ¡Esta respuesta parece ser algo que ha creado para un escenario completamente personalizado, donde discrimina efectivamente a las personas por tener direcciones de correo electrónico que no le gustan! Para ampliar ligeramente, las direcciones de correo electrónico también pueden contener direcciones IP, por lo que esto es potencialmente más restrictivo de lo que se describe.

Es cierto !!!!!! Pero diferentes personas pueden tener diferentes requisitos y es por eso que escribimos validaciones ... ¿no es así?

Bueno en realidad no. Usamos la validación para confirmar que la entrada coincide con nuestras expectativas para evitar tratar de usar datos mal formateados de ciertas maneras. En este caso, OP está buscando un código que pueda validar una dirección de correo electrónico, como debe ser. En su caso, parece que está validando una cadena para que sea algo que desea que sea. En pocas palabras, está validando que una cadena coincide con algo que desea que coincida, que no es una dirección de correo electrónico, mientras que OP busca validar que una cadena coincida con una dirección de correo electrónico. Estas no son las mismas cosas.

Regex simple para ID de correo electrónico

 String EMAIL_PATTERN ="^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})$";
 

De acuerdo con su expresión regular "_.............. kamal@gmail.com" es válido, ¡lo cual no debería ser!

Use la expresión regular:

  /^[a-z][a-zA-Z0-9_.]*(\.[a-zA-Z][a-zA-Z0-9_.]*)?@[a-z][a-zA-Z-0-9]*\.[a-z]+(\.[a-z]+)?$/
  

Ejemplo:

function validateEmail(email) {
    var re = /^[a-z][a-zA-Z0-9_.]*(\.[a-zA-Z][a-zA-Z0-9_.]*)?@[a-z][a-zA-Z-0-9]*\.[a-z]+(\.[a-z]+)?$/;
    return re.test(email);
}
 

Debería permitir solo @,. , _

He mezclado el código @mevius y @Boldewyn para crear este último código para la verificación por correo electrónico usando JavaScript.

 function ValidateEmail(email){
 
  var 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,}))$/;
 
  var input = document.createElement('input');
 
  input.type = 'email';
  input.value = email;
 
  return typeof input.checkValidity == 'function' ? input.checkValidity() : re.test(email);
 
}  

He compartido este código en mi blog aquí .

Esto fallará si el campo está vacío. Puede agregar un atributo requerido y recortar la dirección de correo electrónico para resolver el problema.

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

  • 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 Dirección de correo electrónico de Wikipedia .

Y puede ver el resultado en aquí .

enter descripción de la imagen aquí

Esto parece una buena solución, también funciona con nuevos TLD y correos electrónicos de 1 carta

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

Si está utilizando ng-pattern y material, esto hace el trabajo.

vm.validateEmail = '([a-zA-Z0-9_.]{1,})((@[a-zA-Z]{2,})[\\\.]([a-zA-Z]{2}|[a-zA-Z]{3}))';
 

Quien esté usando la solución @pvl y quiera que pase ESLint Prefer-template entonces aquí hay una versión donde utilicé literales de plantilla en lugar de concatenación de cadenas.

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

    let reValidEmail = new RegExp(sValidEmail);

    return reValidEmail.test(email);
}
 

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

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

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

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

Una solución que no comprueba la existencia del TLD está 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: Asegúrese 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.ccc pasará la expresión regular, no es un correo electrónico válido, porque ccc no es un dominio de nivel superior por IANA.

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

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

  • email@example.com Correo electrónico válido

  • 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 en torno al 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-.]+]*/
 

En nodeJS también puede usar el módulo de nodo validador y simplemente usarlo así

Instalar la biblioteca con el validador de instalación npm

var validator = require('validator');

validator.isEmail('foo@bar.com'); //=> true 
 

Si define su expresión regular como una cadena, entonces todas las barras invertidas deben escaparse, por lo que en lugar de '\ w' debería tener '\ w'.

Alternativamente, defínalo como una expresión regular:

var pattern = /^\w+@[a-zA-Z_]+?\.[a-zA-Z]{2,3}$/; 
 

Hay algunos RegEx complejos escritos aquí, que también funcionan.

Probé este y también funciona:

[a-zA-Z0-9._]+[@]+[a-zA-Z0-9]+[.]+[a-zA-Z]{2,6}
 

Pruebe esto aquí: http://www.regextester.com/?fam=97334

Espero que esto ayude.

me@localhost falla.

Me gustaría agregar una breve nota sobre los caracteres que no son ASCII. La solución de Rnevius (y compañía) es brillante, pero permite agregar cirílico, japonés, emoticones y otros símbolos unicode que pueden estar restringidos por algunos servidores.

El siguiente código imprimirá true aunque contiene el carácter UTF-8 Ё .

 console.log (/^(([^<>()\[\]\\.,;:\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,}))$/.test ('Ё@example.org'))  

En mi caso, todos los símbolos que no son ASCII están prohibidos, por lo que modifiqué la expresión original para excluir todos los caracteres por encima de U + 007F:

 /^(([^\u0080-\uffff<>()\[\]\\.,;:\s@"]+(\.[^\u0080-\uffff<>()\[\]\\.,;:\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,}))$/  

Quizás esto ayude a alguien a evitar comportamientos no deseados.

No, creo que este es un caso de uso bastante inusual que debería ser su propia respuesta

¿Qué tal crear una función que pruebe cualquier cadena contra el patrón de los correos electrónicos utilizando expresiones regulares en JavaScript, ya que sabemos que las direcciones de correo electrónico pueden ser muy diferentes en diferentes regiones, como en el Reino Unido y Australia, generalmente termina con .co.uk o , así que traté de cubrirlos también, también compruebe si la cadena pasó a la función, algo como esto:

.com.au 

y verifique si es un correo electrónico como el siguiente:

var isEmail = function(str) {
  return typeof str==='string' && /^[\w+\d+._]+\@[\w+\d+_+]+\.[\w+\d+._]{2,8}$/.test(str);
}
  

¿Qué sucede con alireza@test.uk o phil.h\@\@cked+liked~it@haacked.com ?

Sintaxis de correo estándar de Wikipedia:

https://en.wikipedia.org/wiki/Email_address#Examples https://fr.wikipedia.org/wiki/Adresse_%C3%A9lectronique#Syntaxe_exacte

function validMail(mail)
{
    return /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()\.,;\s@\"]+\.{0,1})+([^<>()\.,;:\s@\"]{2,}|[\d\.]+))$/.test(mail);
}

// VALID MAILS

validMail('Abc@example.com') // Return true
validMail('Abc@example.com.') // Return true
validMail('Abc@10.42.0.1') // Return true
validMail('user@localserver') // Return true
validMail('Abc.123@example.com') // Return true
validMail('user+mailbox/department=shipping@example.com') // Return true
validMail('"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com') // Return true
validMail('!#$%&\'*+-/=?^_`.{|}~@example.com') // Return true
validMail('"()<>[]:,;@\\\"!#$%&\'-/=?^_`{}| ~.a"@example.org') // Return true
validMail('"Abc@def"@example.com') // Return true
validMail('"Fred Bloggs"@example.com') // Return true
validMail('"Joe.\\Blow"@example.com') // Return true
validMail('Loïc.Accentué@voilà.fr') // Return true
validMail('" "@example.org') // Return true
validMail('user@[IPv6:2001:DB8::1]') // Return true

// INVALID MAILS

validMail('Abc.example.com') // Return false
validMail('A@b@c@example.com') // Return false
validMail('a"b(c)d,e:f;g<h>i[j\k]l@example.com') // Return false
validMail('just"not"right@example.com') // Return false
validMail('this is"not\allowed@example.com') // Return false
validMail('this\ still\"not\\allowed@example.com') // Return false
validMail('john..doe@example.com') // Return false
validMail('john.doe@example..com') // Return false
 

Mostrar esta prueba: https://regex101.com/r/LHJ9gU/1

Muestra ES6

const validateEmail=(email)=> /^(([^<>()\[\]\\.,;:\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,}))$/.test(email);
 

Ahora ReactNative Versión 0.46 Use el siguiente código para la validación de correo electrónico.

 validateEmail = (email) => {
     var 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,}))$/;
     if (re.test(email)) {
     } else {
       alert('email: ' + "Please enter valid emailID.")
     }
 }
 

También puedes probar

var string = "hmharsh3@gmail.com"
var exp = /(\w(=?@)\w+\.{1}[a-zA-Z]{2,})/i
alert(exp.test(string))
 

Esta respuesta está lejos de ser correcta: my.mail@gmail.com ya la rompe

¡Actualización de Regex 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 completa de typscript

//
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 esto simplemente no es cierto. Por favor revise de nuevo

 <input type="email" class="form-control" required="required" placeholder="Email Address" name="Email" id="Email" autocomplete="Email">
 <button class="btn-1 shadow-0 full-width" type="button" id="register">Register account</button>
 

 $("#register").click(function(){       
    var rea = /^[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])?)*$/;
    var Email = $("#Email").val();
    var x = rea.test(Email);
    if (!x) {
        alert('Type Your valid Email');
        return false;
    }           
 </script>
 

Aquí hay una expresión regular simple que simplemente verificaría el formato básico de un correo electrónico, por ejemplo, X@Y.C :

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

Esta pregunta es más difícil de responder de lo que parece a primera vista.

Había muchas personas en todo el mundo buscando "la expresión regular para gobernarlos a todos", pero la verdad es que hay muchos proveedores de correo electrónico.

¿Cuál es el problema? Bueno, "a_z%@gmail.com no puede existir, pero puede existir una dirección como esa a través de otro proveedor" a__z@provider.com.

¿Por qué? De acuerdo con la RFC: https://en.wikipedia.org/wiki/Email_address#RFC_specification .

Tomaré un extracto para facilitar la conferencia:

The local-part of the email address may use any of these ASCII characters:

- uppercase and lowercase Latin letters A to Z and a to z;
- digits 0 to 9;
- special characters !#$%&'*+-/=?^_`{|}~;
- dot ., provided that it is not the first or last character unless quoted, and provided also that it does not appear consecutively unless quoted (e.g. John..Doe@example.com is not allowed but "John..Doe"@example.com is allowed);[6]
Note that some mail servers wildcard local parts, typically the characters following a plus and less often the characters following a minus, so fred+bah@domain and fred+foo@domain might end up in the same inbox as fred+@domain or even as fred@domain. This can be useful for tagging emails for sorting, see below, and for spam control. Braces { and } are also used in that fashion, although less often.
- space and "(),:;<>@[\] characters are allowed with restrictions (they are only allowed inside a quoted string, as described in the paragraph below, and in addition, a backslash or double-quote must be preceded by a backslash);
- comments are allowed with parentheses at either end of the local-part; e.g. john.smith(comment)@example.com and (comment)john.smith@example.com are both equivalent to john.smith@example.com.
 

Entonces, puedo tener una dirección de correo electrónico como esta:

A__z/J0hn.sm{it!}h_comment@example.com.co
 

Si prueba esta dirección, apuesto a que fallará en la totalidad o en la mayor parte de las expresiones regulares publicadas en toda la red. Pero recuerde que esta dirección sigue las reglas de RFC, por lo que es justamente válida.

¡¡¡Imagina mi frustración por no poder registrarme en ningún lugar marcado con esas expresiones regulares !!

El único que realmente puede validar una dirección de correo electrónico es el proveedor de la dirección de correo electrónico.

¿Cómo lidiar, entonces?

No importa si un usuario agrega un correo electrónico no válido en casi todos los casos. Puede confiar en HTML 5 input type = "email" que se ejecuta cerca de a RFC, con pocas posibilidades de fallar. HTML5 input type = "email" info: https : //www.w3.org/TR/2012/WD-html-markup-20121011/input.email.html

Por ejemplo, este es un correo electrónico válido RFC:

"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com
 

Pero la validación html5 le dirá que el texto antes de @ no debe contener "o () caracteres, por ejemplo, que en realidad es incorrecto.

De todos modos, debe hacer esto 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.

Una buena práctica al hacer esto es la entrada "ingrese su correo electrónico nuevamente" para evitar errores de escritura del usuario. Si esto no es suficiente para usted, agregue una ventana modal de preenvío con el título "¿es este su correo electrónico actual?", Luego el correo ingresado por el usuario dentro de una etiqueta h2, ya sabe, para mostrar claramente qué -mail que ingresaron, luego un botón "sí, enviar".

Cómo escribir una expresión regular particular en Android o Java.

1) USER_NAME = "^[A-Za-z0-9_-]{min number of character,max number of character}$";

2) TELEPHONE = "(^\\+)?[0-9()-]*";

3) TELEPHONE_OPTIONAL = "^($|(^\\+)?[0-9()-]*)$";

4) EMAIL = "[a-zA-Z0-9_\\.\\+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-\\.]+";

5) EMAIL_OPTIONAL = "^($|[a-zA-Z0-9_\\.\\+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-\\.]+)$";

6) WEB_URL = "^($|(http:\\/\\/|https:\\/\\/)?(www.)?([a-zA-Z0-9]+).[a-zA-Z0-9]*.[a-z]{3}.?([a-z]+)?)$";

7) WEB_URL_YOUTUBE_BE = "https?\\:\\/\\/(www\\.)?youtu(\\.)?be(\\.com)?\\/.*(\\?v=|\\/v\\/)?[a-zA-Z0-9_\\-]+";

8) POSTAL_ADDRESS = "[a-zA-Z\\d\\s\\-\\,\\#\\.\\+]+";

9) FIELD_NOT_EMPTY = "[^\\s]*";

10) PINCODE = "^([0-9]{6})?$";

11) IFSC_CODE = "^[^\\s]{4}\\d{7}$";

12) SWIFT_CODE = "^([0-9]{10})?$";

13) PINCODE = "^([0-9]{6})?$";

Esta es una traducción de JavaScript de la validación sugerida por la guía oficial de Rails utilizada por miles de sitios web:

/^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i
 

Relativamente simple pero prueba contra los errores más comunes.

Probado en un conjunto de datos de miles de correos electrónicos y tenía cero falsos negativos / positivos.

Ejemplo de uso:

const emailRegex = /^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i;

emailRegex.test('email@example.com');    // true

// Multi-word domains
emailRegex.test('email@example.co.uk');  // true
emailRegex.test('email@mail.gmail.com'); // true

// Valid special characters
emailRegex.test('unusual+but+valid+email1900=/!#$%&\'*+-/=?^_`.{|}~@example.com') // true

// Trailing dots
emailRegex.test('email@example.co.uk.'); // false

// No domain
emailRegex.test('email@example');        // false

// Leading space
emailRegex.test(' email@example.com');   // false

// Trailing space
emailRegex.test('email@example.com ');   // false

// Incorrect domains
emailRegex.test('email@example,com ');   // false

// Other invalid emails
emailRegex.test('invalid.email.com')        // false
emailRegex.test('invalid@email@domain.com') // false
emailRegex.test('email@example..com')       // false
 

No funciona para drikk@øl.com o cualquier otro personaje fuera de a-z

Aquí hay una solución que funciona e incluye la funcionalidad de validación / notificación en un formulario:

Puede ejecutarlo en este enlace

JAVASCRIPT

(function() {
  'use strict';

  window.addEventListener('load', function() {
    var form = document.getElementById('needs-validation');
    form.addEventListener('submit', function(event) {
      if (form.checkValidity() === false) {
        event.preventDefault();
      }
      form.classList.add('was-validated');
      event.preventDefault();              
    }, false);
  }, false);
})();
 

HTML

<p class='title'>
    <b>Email validation</b>
  <hr size="30px;">
</p>
<br>

<form id="needs-validation" novalidate>
  <p class='form_text'>Try it out!</p>
  <div class="form-row">
    <div class="col-12">
      <input type="email" class="form-control" placeholder="Email Address" required>
        <div class="invalid-feedback">
          Please enter a valid email address.
        </div>
    </div>
  <div class="row">
    <div class="col-12">
      <button type="submit" 
          class="btn btn-default btn-block">Sign up now
      </button>
    </div>
   </div>
</form>
 

Escribí un validador de correo electrónico JavaScript que es totalmente compatible con la implementación filter_var($value, FILTER_VALIDATE_EMAIL) de PHP.

https://github.com/mpyw/FILTER_VALIDATE_EMAIL.js

import validateEmail from 'filter-validate-email'

const value = '...'
const result = validateEmail(value)
 

es equivalente a:

<?php

$value = '...';
$result = (bool)filter_var($value, FILTER_VALIDATE_EMAIL, FILTER_FLAG_EMAIL_UNICODE);
 

function ValidateEmail(mail) 
{
  if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(myForm.emailAddr.value))
  {
    return (true)
  }
  alert("You have entered an invalid email address!")
  return (false)
}
 

URL de referencia: https://www.w3resource.com/javascript/ form / email-validation.php

Esto funciona para mí:

function Email(mail)
{
 if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(myForm.emailAddr.value))
  {
    return (true)
  }
    alert("Invalid email address!")
    return (false)
}
 

La parte personal_info contiene los siguientes caracteres ASCII.

  1. Mayúsculas (A-Z) y minúsculas (a-z) letras en inglés. Dígitos (0-9).
  2. Personajes! # $% & '* + - / =? ^ _ `{| } ~
  3. Carácter. (punto, punto o parada completa) siempre que no sea el primer o último personaje y no vendrá uno tras otro.

La parte del nombre de dominio [por ejemplo com, org, net, in, us, info] contiene letras, dígitos, guiones y puntos.

 function ValidateEmail(mail) 
{
 if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(myForm.emailAddr.value))
  {
    return (true)
  }
    alert("You have entered an invalid email address!")
    return (false)
}
 

También puede usar la nueva clase Regex y hacer esto:

function validateEmail( str ) { return new RegExp( /([\w\.\-_]+)?\w+@[\w-_]+(\.\w+){1,}/, 'igm' ).test( str ); }

referencia: https://developer.mozilla.org/en-US/ docs / Web / JavaScript / Guide / Regular_Expressions

Aquí está el patrón Regex recomendado para HTML5 en MDN:

  

Los navegadores que admiten el tipo de entrada de correo electrónico proporcionan automáticamente la validación para garantizar que solo el texto que coincida con el formato estándar para las direcciones de correo electrónico de Internet se ingrese en el cuadro de entrada. Los navegadores que implementan la especificación deberían usar un algoritmo equivalente a la siguiente expresión regular:

/^[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])?)*$/
 

https: //developer.mozilla .org / es-ES / docs / Web / HTML / Element / input / email # Validación

Bueno. ¿Alguna vez ha probado otros métodos de validación como los servicios PHP o API? Al igual que DeBounce Herramienta de validación de correo electrónico .

Usted usa en frío https://github.com/chriso/validator.js y simplemente haz:

var validator = require('validator');

validator.isEmail('foo@bar.com'); //=> true
 

Tenga en cuenta que esto puede funcionar en el cliente.

Así es como lo hago. Estoy usando match () para verificar el patrón de correo electrónico estándar y estoy agregando una clase al texto de entrada para notificar al usuario en consecuencia. ¡Espero que ayude!

 $(document).ready(function(){
  $('#submit').on('click', function(){
      var email = $('#email').val();
      var pat = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/;
      if (email.match(pat)){
        $('#email')
          .addClass('input-valid');
        return false;
      } else {
        $('#email')
        	.addClass('input-error')
          .val('');
        return false;
      }
  });
});  
 .input-error {
  border: 1px solid red;
  color: red;
}

.input-valid {
  border: 1px solid green;
  color: green;
}  
 <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<form>
    <input type="text" id="email" placeholder="name@service.xx" class="">
    <input type="submit" id="submit" value="Send"/>
</form>  

¿Alguna vez has probado DeBounce Validación de correo electrónico ? Sugiero echar un vistazo a esto.

Existe mi versión de un validador de correo electrónico. Este código se realiza con programación orientada a objetos y se realiza como una clase con métodos estáticos. Encontrará dos versiones de los validadores: estricto (EmailValidator.validate ) y kind (EmailValidator.validateKind ).

El primero arroja un error si un correo electrónico no es válido y devuelve el correo electrónico de lo contrario. El segundo devuelve un valor booleano que dice si un correo electrónico es válido. Prefiero la versión estricta en la mayoría de los casos.

export class EmailValidator {
    /**
     * @param {string} email
     * @return {string}
     * @throws {Error}
     */
    static validate(email) {
        email = this.prepareEmail(email);

        const isValid = this.validateKind(email);

        if (isValid)
            return email;

        throw new Error(`Got invalid email: ${email}.`);
    }

    /**
     * @param {string} email
     * @return {boolean}
     */
    static validateKind(email) {
        email = this.prepareEmail(email);

        const regex = this.getRegex();

        return regex.test(email);
    }

    /**
     * @return {RegExp}
     * @private
     */
    static getRegex() {
        return /^(([^<>()\[\]\\.,;:\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,}))$/;
    }

    /**
     * @param {string} email
     * @return {string}
     * @private
     */
    static prepareEmail(email) {
        return String(email).toLowerCase();
    }
}
 

Para validar un correo electrónico, puede seguir estas formas:

// First way.

try {
    EmailValidator.validate('balovbohdan@gmail.com');
} catch (e) {
    console.error(e.message);
}
 
// Second way.

const email = 'balovbohdan@gmail.com';
const isValid = EmailValidator.validateKind(email);

if (isValid)
    console.log(`Email is valid: ${email}.`);
else
    console.log(`Email is invalid: ${email}.`);
 

Estoy usando esta función

/**
 * @param {*} email
 */
export const validateEmail = email => {
    return new RegExp(/[\w-]+@([\w-]+\.)+[\w-]+/gm).test(email);
};
 

No funciona para Unicode. validateEmail('køkø@gmail.com') === false . Olvídese de la validación utilizando comprobaciones como esta. Pruebe @ y simplemente envíe un correo electrónico al usuario.

Regex general de correo electrónico (Norma oficial RFC 5322): https://emailregex.com/

JavaScript:

/^(([^<>()\[\]\\.,;:\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,}))$/
 

Avatar Pax

Busque el signo @ en el campo de entrada.

¡Esta! Este es el único control válido que realmente puede hacer que no complica las cosas innecesariamente. Si realmente desea saber si el correo electrónico es válido, envíe un correo electrónico al usuario.

Si desea algo que un humano pueda leer y mantener , recomendaría Masala Parser (soy uno de sus creadores).

 import {C,Streams} from '@masala/parser'

const illegalCharset = ' @\u00A0\n\t';
const extendedIllegalCharset = illegalCharset + '.';


// Assume 'nicolas@internal.masala.co.uk'
export function simpleEmail() {

    return C.charNotIn(illegalCharset).rep() // 'nicolas'
        .then(C.char('@'))
        .then(subDns())  //'internal.masala.co.'
        .then(C.charNotIn(extendedIllegalCharset).rep()) //'uk'
        .eos(); // Must be end of the char stream
}

// x@internal.masala.co.uk => extract 'internal.masala.co.'
function  subDns() {
    return C.charNotIn(extendedIllegalCharset).rep().then(C.char('.')).rep()
}

function validateEmail(email:string) {
    console.log(email + ': ' + (simpleEmail().parse(Streams.ofString(email)).isAccepted()));
}


validateEmail('nicolas@internal.masala.co.uk'); // True
validateEmail('nz@co.'); // False, trailing "."
  

Si desea aceptar la última versión de correo electrónico feo, puede agregar comillas en la primera parte:

 
function inQuote() {
    return C.char('"')
        .then(C.notChar('"').rep())
        .then(C.char('"'))
}

function allEmail() {

    return inQuote().or(C.charNotIn(illegalCharset))
        .rep() // repeat (inQuote or anyCharacter)
        .then(C.char('@'))
        .then(subDns())
        .then(C.charNotIn(extendedIllegalCharset).rep())
        .eos() // Must be end of the character stream
        // Create a structure
        .map(function (characters) { return ({ email: characters.join('') }); });
}
  

'"nicolas""love-quotes"@masala.co.uk' es oficialmente válido, pero ¿debería estar en su sistema?

Al menos con Masala, te das la oportunidad de entenderlo. Y así, para el próximo año, colega.

Agregué mi Regex, resolví para mí más pequeños problemas como caracteres de otros idiomas o letras mayúsculas

^[a-zA-Z0-9][a-zA-Z0-9-_\.]+@([a-zA-Z]|[a-zA-Z0-9]?[a-zA-Z0-9-]+[a-zA-Z0-9])\.[a-zA-Z0-9]{2,10}(?:\.[a-zA-Z]{2,10})?$
 

Use el navegador / tiempo de ejecución para manejar el análisis de la entrada anteponiendo un protocolo y páselo a la API URL , atrapando cualquier error y verifique el username y hostname propiedades del resultado. Manejará básicamente todas las transformaciones y posibilidades ( punycode de juegos de caracteres, etc.). Esto solo establece que la entrada es analizable, no válida, eso solo es posible al verificar si la máquina de destino recibe mensajes para ese alias. Sin embargo, esto proporciona una suposición cercana (imo razonable), y se puede ampliar para ser más específico y realista si se siente cómodo tanto al mantenerlo como al arriesgarse a rechazos inválidos. (Tenga en cuenta que no intenta abordar las direcciones IPv4 o IPv6, simplemente la amplia gama de escenarios orientados al cliente que utilizan un dominio).

 

Este es el ejemplo más simple y generalmente más permisivo que se me ocurre. Edítelo en los casos en que se pueda hacer que sea más preciso y, al mismo tiempo, mantenga su simplicidad y una validez razonable generalmente permisiva.

Consulte también los documentos de URL de MDN URL , window.URL y Nodejs para URL API.

para la validación del correo electrónico, puede crear su función personalizada y usar la sintaxis de expresiones regulares para validar el correo electrónico:

function validateEmail(email){
        var reg = /^([A-Za-z0-9_\-\.])+\@([A-Za-z0-9_\-\.])+\.([A-Za-z]{2,4})$/;

       //your custom code here to check your email address 

}
 

Estos funcionarán con los correos electrónicos más utilizados ( coinciden exactamente con las reglas de cada uno ).

Gmail
/^[a-z]((?!\.\.)([a-z\.])){4,28}[a-z0-9]@google.com$/i

Yahoo
/^[a-z]((?!\.\.)([\w\.])){3,30}[\w]@yahoo.com$/i

Outlook / Hotmail
/[a-z]((?!\.\.)([\w\.])){0,62}[\w]@(outlook.com|hotmail.com)$/i

¿Sabe que \w ya incluye \d y _ ? Por favor, eche un vistazo a estos sitios: Lista de TLD ; direcciones válidas / inválidas ; regex para la dirección de correo electrónico RFC822

@Toto es cierto, no sé cómo lo perdí allí, en realidad usé esta expresión regular en mi base de datos: \, gracias de nuevo.

Puede intentar RegExp

 function isValidEmail( value ) {
	return /^[\w\-\.\+]+\@[a-zA-Z0-9\.\-]+\.[a-zA-z0-9]{2,5}$/.test( value );
}

console.log( isValidEmail("mymail@mydomain.com") )  

En mi caso, quiero evitar ~ y # es por eso que he usado otra solución Haga clic aquí Para más información

function validEmail(email){
  const regex = /^((?!\.)[\w-_.]*[^.])(@\w+)(\.\w+(\.\w+)?[^.\W])$/;
  return regex.test(email);
}
 

 function validEmail(email){
  const regex = /^((?!\.)[\w-_.]*[^.])(@\w+)(\.\w+(\.\w+)?[^.\W])$/;
  return regex.test(email);
}

const emails = [
'pio_pio@factory.com',
'~pio_pio@factory.com',
'pio_~pio@factory.com',
'pio_#pio@factory.com',
'pio_pio@#factory.com',
'pio_pio@factory.c#om',
'pio_pio@factory.c*om',
'pio^_pio@factory.com'
]

for(const email of emails){
  document.write(email+' : '+validEmail(email)+'</br>');
}