validate type node español address forms email email-validation email-address

forms - type - validate email javascript



¿Qué caracteres están permitidos en una dirección de correo electrónico? (18)

No estoy preguntando acerca de la validación completa de correo electrónico.

Solo quiero saber qué son los caracteres permitidos en user-name partes de user-name y server de la dirección de correo electrónico. Esto puede simplificarse en exceso, tal vez las direcciones de correo electrónico pueden tomar otras formas, pero no me importa. Solo pregunto sobre esta forma simple: user-name@server (por ejemplo, [email protected]) y caracteres permitidos en ambas partes.

¡Cuidado! Hay una gran cantidad de conocimientos en este hilo (cosas que solían ser ciertas y ahora no lo son).

Para evitar rechazos falsos positivos de direcciones de correo electrónico reales en el mundo actual y futuro, y desde cualquier parte del mundo, debe conocer al menos el concepto de alto nivel de RFC 3490 , "Internacionalización de nombres de dominio en aplicaciones (IDNA)". Sé que la gente en EE. UU. Y A a menudo no están de acuerdo con esto, pero ya se está extendiendo y está aumentando rápidamente en todo el mundo (principalmente en las partes dominadas no en inglés).

Lo esencial es que ahora puedes usar direcciones como mason @ 日本 .com y wildwezyr@fahrvergnügen.net. No, esto aún no es compatible con todo lo que hay por ahí (como muchos se han lamentado anteriormente, incluso las direcciones de identificación + de estilo qmail simples a menudo se rechazan erróneamente). Pero hay un RFC, hay una especificación, ahora está respaldado por el IETF y la ICANN y, lo que es más importante, hay un gran número de implementaciones que respaldan esta mejora y que están actualmente en servicio.

Yo no sabía mucho sobre este desarrollo hasta que me mudé a Japón y comencé a ver direcciones de correo electrónico como hei @ や .ca y URL de Amazon como esta:

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

Sé que no desea enlaces a especificaciones, pero si confía únicamente en el conocimiento desactualizado de los piratas informáticos en los foros de Internet, su validador de correo electrónico terminará rechazando las direcciones de correo electrónico que los usuarios que no son de Enlish esperan que funcionen. Para esos usuarios, dicha validación será tan molesta como la forma de muerte cerebral común que todos odiamos, la que no puede manejar un + o un nombre de dominio de tres partes o lo que sea.

Así que no estoy diciendo que no sea una molestia, pero la lista completa de caracteres "permitidos en algunas condiciones / cualquiera / ninguna" es (casi) todos los caracteres en todos los idiomas. Si desea "aceptar todas las direcciones de correo electrónico válidas (y muchas de ellas no válidas también"), debe tener en cuenta el IDN, lo que básicamente hace que un enfoque basado en caracteres sea inútil (lo sentimos), a menos que primero convierta las direcciones de correo electrónico internacionalizadas a Punycode .

Después de hacer eso, puede seguir (la mayoría de) los consejos anteriores.

Como se puede encontrar en este enlace de Wikipedia.

La parte local de la dirección de correo electrónico puede usar cualquiera de estos caracteres ASCII:

  • mayúsculas y minúsculas letras latinas A a Z y a a z ;

  • dígitos del 0 al 9 ;

  • caracteres especiales !#$%&''*+-/=?^_`{|}~ ;

  • punto , siempre que no sea el primer o el último carácter a menos que se indique, y siempre que no aparezca consecutivamente a menos que se indique (por ejemplo, [email protected] no está permitido pero "John..Doe"@example.com está permitido);

  • el espacio y los caracteres "(),:;<>@[/] están permitidos con restricciones (solo se permiten dentro de una cadena entre comillas, como se describe en el párrafo a continuación, y además, una barra invertida o una comilla doble deben ir precedidas por una barra invertida);

  • los comentarios se permiten con paréntesis en cualquiera de los extremos de la parte local; por ejemplo, john.smith(comment)@example.com y (comment)[email protected] son equivalentes a [email protected] .

Además de los caracteres ASCII anteriores, los caracteres internacionales por encima de U + 007F, codificados como UTF-8, están permitidos por RFC 6531 , aunque los sistemas de correo pueden restringir qué caracteres usar cuando se asignan partes locales.

Una cadena entre comillas puede existir como una entidad separada por puntos dentro de la parte local, o puede existir cuando las comillas más externas son los caracteres más externos de la parte local (por ejemplo, abc."defghi"[email protected] o "abcdefghixyz"@example.com está permitido. A la inversa, abc"defghi"[email protected] no lo es; tampoco abc/"def/"[email protected] ). Las cadenas y los caracteres entre comillas, sin embargo, no se utilizan comúnmente. RFC 5321 también advierte que "un host que espera recibir correo DEBE evitar la definición de los buzones donde la parte local requiere (o usa) el formulario de cadena entre comillas".

El postmaster parte local se trata de manera especial: no distingue entre mayúsculas y minúsculas, y debe enviarse al administrador de correo electrónico del dominio. Técnicamente, todas las demás partes locales distinguen entre mayúsculas y minúsculas, por [email protected] tanto, [email protected] y [email protected] especifican diferentes buzones; sin embargo, muchas organizaciones tratan las letras mayúsculas y minúsculas como equivalentes.

A pesar de la amplia gama de caracteres especiales que son técnicamente válidos; Las organizaciones, servicios de correo, servidores de correo y clientes de correo en la práctica a menudo no los aceptan a todos. Por ejemplo, Windows Live Hotmail solo permite la creación de direcciones de correo electrónico mediante caracteres alfanuméricos, punto ( .), guión bajo ( _) y guión ( -). El consejo común es evitar el uso de algunos caracteres especiales para evitar el riesgo de correos electrónicos rechazados.

Consulte RFC 5322: Formato de mensaje de Internet y, en menor medida, RFC 5321: Protocolo de transferencia de correo simple

RFC 822 también cubre direcciones de correo electrónico, pero trata principalmente con su estructura:

addr-spec = local-part "@" domain ; global address local-part = word *("." word) ; uninterpreted ; case-preserved domain = sub-domain *("." sub-domain) sub-domain = domain-ref / domain-literal domain-ref = atom ; symbolic reference

Y como es habitual, Wikipedia tiene un artículo decente sobre las direcciones de correo electrónico :

La parte local de la dirección de correo electrónico puede usar cualquiera de estos caracteres ASCII:

  • mayúsculas y minúsculas letras latinas A a Z y a a z ;
  • dígitos del 0 al 9 ;
  • caracteres especiales !#$%&''*+-/=?^_`{|}~ ;
  • punto , siempre que no sea el primer o el último carácter a menos que se indique, y siempre que no aparezca consecutivamente a menos que se indique (por ejemplo, [email protected] no está permitido pero "John..Doe"@example.com está permitido);
  • el espacio y los caracteres "(),:;<>@[/] están permitidos con restricciones (solo se permiten dentro de una cadena entre comillas, como se describe en el párrafo a continuación, y además, una barra invertida o una comilla doble deben ir precedidas por una barra invertida);
  • los comentarios se permiten con paréntesis en cualquiera de los extremos de la parte local; por ejemplo, john.smith(comment)@example.com y (comment)[email protected] son equivalentes a [email protected] .

Además de los caracteres ASCII, a partir de 2012 puede usar caracteres internacionales sobre U+007F , codificados como UTF-8 .

Para la validación, consulte Uso de una expresión regular para validar una dirección de correo electrónico .

La parte del domain se define de la siguiente manera :

Los estándares de Internet (Solicitud de comentarios) para los protocolos establecen que las etiquetas de los nombres de host de los componentes pueden contener solo las letras ASCII de la A a la z (de manera que no distingan mayúsculas y minúsculas), los dígitos del 0 al 9 y el guión ( - ). La especificación original de nombres de host en RFC 952 exigía que las etiquetas no pudieran comenzar con un dígito o un guión, y no deben terminar con un guión. Sin embargo, una especificación posterior ( RFC 1123 ) permitió que las etiquetas de nombre de host comenzaran con dígitos. No se permiten otros símbolos, caracteres de puntuación o espacios en blanco.

El formato de la dirección de correo electrónico es: local-part@domain-part (máx. 64 @ 255 caracteres, no más de 256 en total).

La parte local-part domain-part pueden tener diferentes conjuntos de caracteres permitidos, pero eso no es todo, ya que existen más reglas.

En general, la parte local puede tener estos caracteres ASCII:

  • letras latinas minúsculas: abcdefghijklmnopqrstuvwxyz ,
  • letras latinas en mayúsculas: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • dígitos: 0123456789 ,
  • caracteres especiales:! !#$%&''*+-/=?^_`{|}~ ,
  • punto:. (no es el primer o último carácter o se repite a menos que se indique)
  • puntuaciones de espacio tales como: "(),:;<>@[/] (con algunas restricciones),
  • comentarios: () (están permitidos entre paréntesis, por ejemplo, ( (comment)[email protected] ) (comment)[email protected] ).

Parte del dominio:

  • letras latinas minúsculas: abcdefghijklmnopqrstuvwxyz ,
  • letras latinas en mayúsculas: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • dígitos: 0123456789 ,
  • guión: - (no el primer o el último carácter),
  • puede contener una dirección IP entre corchetes: jsmith@[192.168.2.1] o jsmith@[IPv6:2001:db8::1] .

Estas direcciones de correo son válidas:

Y estos ejemplos de inválidos:

  • Abc.example.com (no @ carácter)
  • A@b@[email protected] (solo una @ está permitida entre comillas)
  • a"b(c)d,e:f;gi[j/k][email protected] (ninguno de los caracteres especiales en esta parte local está permitido fuera de las comillas)
  • just"not"[email protected] (las cadenas entre comillas deben estar separadas por puntos o el único elemento que forma la parte local)
  • this is"not/[email protected] (los espacios, las comillas y las barras invertidas solo pueden existir cuando están dentro de cadenas entre comillas y this is"not/[email protected] precedidas por una barra diagonal inversa)
  • this/ still/"not/[email protected] (incluso si se escapó (precedido por una barra invertida), los espacios, las comillas y las barras invertidas aún deben estar entre comillas)
  • [email protected] (punto doble antes de @ ); (con advertencia: Gmail deja pasar esto)
  • [email protected] (punto doble después de @ )
  • Una dirección válida con un espacio inicial.
  • una dirección válida con un espacio al final

Fuente: Dirección de correo electrónico en Wikipedia

La expresión regular RFC2822 de Perl para validar correos electrónicos:

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

La regexp completa para direcciones RFC2822 fue de solo 3.7k.

Ver también: RFC 822 Analizador de direcciones de correo electrónico en PHP .

Las definiciones formales de las direcciones de correo electrónico están en:

  • RFC 5322 (secciones 3.2.3 y 3.4.1, RFC 2822 obsoletos), RFC 5321, RFC 3696,
  • RFC 6531 (caracteres permitidos).

Relacionado:

Google hace algo interesante con sus direcciones de gmail.com. Las direcciones de gmail.com solo permiten letras (az), números y puntos (que se ignoran).

por ejemplo, [email protected] es lo mismo que [email protected], y ambas direcciones de correo electrónico se enviarán al mismo buzón. [email protected] también se entrega al mismo buzón.

Entonces, para responder a la pregunta, a veces depende del implementador la cantidad de estándares RFC que desean cumplir. El estilo de dirección de gmail.com de Google es compatible con los estándares. Lo hacen de esa manera para evitar confusiones donde diferentes personas tomarían direcciones de correo electrónico similares, por ejemplo,

*** gmail.com accepting rules *** [email protected] (accepted) [email protected] (bounce and account can never be created) [email protected] (accepted) D.Oy''[email protected] (bounce and account can never be created)

El enlace de wikipedia es una buena referencia sobre lo que generalmente permiten las direcciones de correo electrónico. http://en.wikipedia.org/wiki/Email_address

La respuesta aceptada se refiere a un artículo de Wikipedia cuando se habla de la parte local válida de una dirección de correo electrónico, pero Wikipedia no es una autoridad en esto.

IETF RFC 3696 es una autoridad en este tema y debe consultarse en la sección 3. Restricciones en las direcciones de correo electrónico en la página 5:

Las direcciones de correo electrónico contemporáneas consisten en una "parte local" separada de una "parte de dominio" (un nombre de dominio completamente calificado) por un signo de entrada ("@"). La sintaxis de la parte del dominio corresponde a la de la sección anterior. Las inquietudes identificadas en esa sección sobre el filtrado y las listas de nombres se aplican también a los nombres de dominio utilizados en un contexto de correo electrónico. El nombre de dominio también puede ser reemplazado por una dirección IP entre corchetes, pero se desaconseja encarecidamente esa forma, excepto para propósitos de prueba y resolución de problemas.

La parte local puede aparecer usando las convenciones de cotización que se describen a continuación. Las formas citadas rara vez se usan en la práctica, pero se requieren para algunos propósitos legítimos. Por lo tanto, no deben rechazarse en las rutinas de filtrado, sino que deben pasarse al sistema de correo electrónico para su evaluación por parte del host de destino.

La regla exacta es que cualquier carácter ASCII, incluidos los caracteres de control, puede aparecer entre comillas o en una cadena entre comillas. Cuando se necesita citar, el carácter de barra diagonal inversa se utiliza para citar el siguiente carácter. Por ejemplo

Abc/@[email protected]

Es una forma válida de una dirección de correo electrónico. También pueden aparecer espacios en blanco, como en

Fred/ [email protected]

El carácter de barra invertida también se puede usar para citarse, por ejemplo,

Joe.//[email protected]

Además de citar usando el carácter de barra invertida, se pueden usar caracteres de comillas dobles convencionales para rodear cadenas. Por ejemplo

"Abc@def"@example.com "Fred Bloggs"@example.com

Son formas alternativas de los dos primeros ejemplos anteriores. Estos formularios citados rara vez se recomiendan y son poco comunes en la práctica, pero, como se mencionó anteriormente, deben ser compatibles con aplicaciones que procesan direcciones de correo electrónico. En particular, las formas citadas a menudo aparecen en el contexto de direcciones asociadas con transiciones de otros sistemas y contextos; esos requisitos de transición aún surgen y, dado que un sistema que acepta una dirección de correo electrónico proporcionada por el usuario no puede "saber" si esa dirección está asociada con un sistema heredado, los formularios de dirección deben aceptarse y pasarse al entorno de correo electrónico.

Sin comillas, las partes locales pueden consistir en cualquier combinación de
Caracteres alfabéticos, dígitos, o cualquiera de los caracteres especiales.

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

el período (".") también puede aparecer, pero no puede usarse para iniciar o finalizar la parte local, ni pueden aparecer dos o más períodos consecutivos. Dicho de otra manera, cualquier carácter ASCII gráfico (impresión) distinto del at-sign ("@"), barra invertida, comillas dobles, comas o corchetes puede aparecer sin comillas. Si aparece alguna de esas listas de caracteres excluidos, deben ser citados. Formas tales como

[email protected] customer/[email protected] [email protected] !def!xyz%[email protected] [email protected]

son válidos y se ven con bastante frecuencia, pero se permite cualquiera de los caracteres mencionados anteriormente.

Como otros lo han hecho, presento una expresión regular que funciona para PHP y JavaScript para validar las direcciones de correo electrónico:

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

La respuesta corta es que hay 2 respuestas. Hay un estándar para lo que debes hacer. es decir, el comportamiento que es sabio y te mantendrá fuera de problemas. Hay otro estándar (mucho más amplio) para el comportamiento que debe aceptar sin causar problemas. Esta dualidad funciona para enviar y aceptar correos electrónicos, pero tiene una amplia aplicación en la vida.

Para una buena guía de las direcciones que creas; consulte: http://www.remote.org/jochen/mail/info/chars.html

Para filtrar correos electrónicos válidos, simplemente transmita cualquier cosa lo suficientemente comprensible como para ver el siguiente paso. O comienza a leer un montón de RFC, precaución, aquí hay dragones.

Nombre:

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

Servidor:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

Puedes empezar desde el artículo de wikipedia :

  • Letras inglesas en mayúsculas y minúsculas (az, AZ)
  • Dígitos del 0 al 9
  • Caracteres ! # $% & ''* + - / =? ^ _ `{| } ~
  • Personaje . (punto, punto, punto final) siempre que no sea el primer o el último carácter, y también que no aparezca dos o más veces consecutivas.

Wikipedia tiene un buen artículo sobre esto , y la especificación oficial está aquí . De Wikipdia:

La parte local de la dirección de correo electrónico puede usar cualquiera de estos caracteres ASCII:

  • Letras inglesas en mayúsculas y minúsculas (az, AZ)
  • Dígitos del 0 al 9
  • Caracteres ! # $% & ''* + - / =? ^ _ `{| } ~
  • Personaje . (punto, punto, punto final) siempre que no sea el primer o el último carácter, y también que no aparezca dos o más veces consecutivas.

Además, se permiten cadenas entrecomilladas (es decir, "John Doe" @ example.com), por lo que se permiten caracteres que de otro modo estarían prohibidos, sin embargo, no aparecen en la práctica común. RFC 5321 también advierte que "un host que espera recibir correo DEBE evitar la definición de buzones donde la parte local requiere (o usa) el formulario de cadena entre comillas".

Compruebe para @ y. y luego enviar un correo electrónico para que los verifiquen.

Todavía no puedo usar mi dirección de correo electrónico .name en el 20% de los sitios en Internet porque alguien cometió un error en su validación de correo electrónico, o porque es anterior a la validez de las nuevas direcciones.

En mi PHP uso este cheque

<?php if (preg_match( ''/^(?:[/w/!/#/$/%/&/'/*/+/-///=/?/^/`/{/|/}/~]+/.)*[/w/!/#/$/%/&/'/*/+/-///=/?/^/`/{/|/}/~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_/-](?!/.)){0,61}[a-zA-Z0-9_-]?/.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_/-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:/[(?:(?:[01]?/d{1,2}|2[0-4]/d|25[0-5])/.){3}(?:[01]?/d{1,2}|2[0-4]/d|25[0-5])/]))$/'', "tim''[email protected]" )){ echo "legit email"; } else { echo "NOT legit email"; } ?>

Pruébelo usted mismo http://phpfiddle.org/main/code/9av6-d10r

He creado esta expresión regular de acuerdo con las directrices de RFC:

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

Para aquellos interesados ​​en la validación de dominios internacionales, hay una herramienta .NET disponible aquí (no afiliada a la compañía):

http://cobisi.com/email-validation/.net-component - compatible con una larga lista de RFC:

Estándares IETF (RFC 1123, RFC 2821, RFC 2822, RFC 3490, RFC 3696, RFC 4291, RFC 5321, RFC 5322 y RFC 5336), con soporte para palabras citadas, literales de dominio, nombres de dominio no-ASCII (IDNA) y buzones , y comentarios

Gmail solo permitirá el signo + como carácter especial y en algunos casos (.), Pero cualquier otro carácter especial no está permitido en Gmail. RFC dice que puede usar caracteres especiales, pero debe evitar enviar correos a Gmail con caracteres especiales.

La respuesta es (casi) ALL(ASCII de 7 bits).
Si las reglas de inclusión son "... permitidas bajo algunas condiciones / cualquiera / ninguna ..."

Con solo mirar una de las varias reglas de inclusión posibles para el texto permitido en la parte de "texto de dominio" en RFC 5322 en la parte superior de la página 17, encontramos:

dtext = %d33-90 / ; Printable US-ASCII %d94-126 / ; characters not including obs-dtext ; "[", "]", or "/"

los únicos tres caracteres que faltan en esta descripción se usan en el dominio literal [], para formar un par entre comillas /y el carácter de espacio en blanco (% d32). Con eso se utiliza todo el rango 32-126 (decimal). Un requisito similar aparece como "qtext" y "ctext". También se permiten / usan muchos caracteres de control. Una lista de dichos caracteres de control aparece en la página 31 sección 4.1 de RFC 5322 como obs-NO-WS-CTL.

obs-NO-WS-CTL = %d1-8 / ; US-ASCII control %d11 / ; characters that do not %d12 / ; include the carriage %d14-31 / ; return, line feed, and %d127 ; white space characters

Todos estos caracteres de control están permitidos como se indica al comienzo de la sección 3.5:

.... MAY be used, the use of US-ASCII control characters (values 1 through 8, 11, 12, and 14 through 31) is discouraged ....

Y tal regla de inclusión es, por lo tanto, "demasiado amplia". O, en otro sentido, la regla esperada es "demasiado simplista".

Para simplificar, desinfecto el envío eliminando todo el texto entre comillas dobles y las comillas dobles que lo rodean antes de la validación, poniendo el kibosh en los envíos de direcciones de correo electrónico según lo que está prohibido. Solo porque alguien puede tener la dirección de John .. "The * $ hizzle * Bizzle" .. [email protected] no significa que tenga que permitirlo en mi sistema. Vivimos en el futuro, donde tal vez lleve menos tiempo obtener una dirección de correo electrónico gratuita que hacer un buen trabajo limpiando tu trasero. Y no es como si los criterios de correo electrónico no estuvieran pegados justo al lado de la entrada diciendo qué está permitido y qué no.

También desinfecto lo que específicamente no está permitido por varios RFC después de eliminar el material citado. La lista de caracteres y patrones específicamente prohibidos parece ser una lista mucho más corta para probar.

Desestimado

local part starts with a period ( [email protected] ) local part ends with a period ( [email protected] ) two or more periods in series ( [email protected] ) &’`*|/ ( some&thing`[email protected] ) more than one @ ( which@[email protected] ) :% ( mo:characters%mo:[email protected] )

En el ejemplo dado:

John.."The*$hizzle*Bizzle"[email protected] --> [email protected] [email protected] --> [email protected]

Enviar un mensaje de correo electrónico de confirmación al resultado restante al intentar agregar o cambiar la dirección de correo electrónico es una buena manera de ver si su código puede manejar la dirección de correo electrónico enviada. Si el correo electrónico pasa la validación después de tantas rondas de desinfección como sea necesario, desencadene esa confirmación. Si una solicitud regresa del enlace de confirmación, entonces el nuevo correo electrónico se puede mover desde el estado del purgatorio || temporario || retenido para que se convierta en un correo electrónico almacenado de primera clase y de buena fe.

Si desea ser considerado, puede enviar una notificación de error o éxito de cambio de dirección de correo electrónico a la dirección de correo electrónico anterior. Las configuraciones de cuentas no confirmadas pueden caer fuera del sistema como intentos fallidos por completo después de un período de tiempo razonable.

No permito correos electrónicos apestosos en mi sistema, tal vez eso es simplemente tirar dinero. Pero, el 99.9% del tiempo las personas simplemente hacen lo correcto y tienen un correo electrónico que no lleva los límites de conformidad al límite, utilizando escenarios de compatibilidad de casos de vanguardia. Tenga cuidado con el regex DDoS, este es un lugar donde puede meterse en problemas. Y esto está relacionado con la tercera cosa que hago, pongo un límite a cuánto tiempo estoy dispuesto a procesar cualquier correo electrónico. Si necesita reducir la velocidad de mi máquina para validarla, no está superando la lógica de punto final de la API de datos entrantes.

Edit: Esta respuesta seguía siendo golpeada por ser "mala", y tal vez la merecía. Tal vez todavía sea malo, tal vez no.