validas una tipos tener son sirve servidores que pueden permitidos para número numeros nombres menos los las incluir especiales especial electrónico electronico ejemplos dirección direcciones direccion definicion deben debe cuáles cuál correo contraseñas contraseña configurar con carácter caracteristicas caracteres caracter alfanuméricos alfanumérico alfanumericos alfanumerico alfabeto email unicode internationalization domain-name

email - una - ¿Las direcciones de correo electrónico pueden contener caracteres no alfanuméricos?



tipos de servidores dns (6)

Bueno, sí. Lea (al menos) this artículo de Wikipedia.

Vivo en Argentina y aquí se permiten correos electrónicos como ñoñó[email protected]

Estoy construyendo un sitio web usando `Django. El sitio web podría tener usuarios importantes de países que no hablan inglés.

Solo quiero saber si hay restricciones técnicas sobre qué tipos de caracteres podría contener una dirección de correo electrónico.

¿Las direcciones de correo electrónico solo pueden contener alfabetos, números, "_", "@" y "." Ingleses?

¿Se les permite contener alfabetos no ingleses como "é" o "ü"?

¿Se les permite contener caracteres chinos o japoneses u otros caracteres Unicode?


En lugar de preocuparte por lo que las direcciones de correo electrónico pueden y no pueden contener, lo que realmente no te importa, prueba si tu configuración puede enviarles un correo electrónico o no, ¡esto es lo que realmente te importa! Esto significa en realidad enviar un correo electrónico de verificación.

De lo contrario, no se puede detectar un caso mucho más común de errores tipográficos accidentales que permanecen dentro de cualquier conjunto de caracteres que se ideen. (Rápido: ¿es [email protected] una dirección válida para usar en su sitio, o no?) También evita alienar innecesaria y gratuitamente a los usuarios cuando les dice que su dirección correcta y correcta es incorrecta. Es posible que todavía no pueda procesar algunas direcciones (esta es una alienación necesaria), como dicen las otras respuestas: el procesamiento de la dirección de correo electrónico no es trivial; pero eso es algo que deben averiguar si quieren proporcionarle una dirección de correo electrónico.

Todo lo que debe verificar es que el usuario proporciona algo de texto antes de una @, algo de texto después, y la dirección no es escandalosamente larga (digamos 1000 caracteres). Si desea dar una advertencia ("¡esto parece un problema! ¿Hay un error tipográfico?", Haga doble clic antes de continuar "), está bien, pero no debería bloquear el proceso de agregar direcciones de correo electrónico.

Por supuesto, si no les importa enviarles un correo electrónico, simplemente tomen lo que ingresen. Por ejemplo, la dirección solo puede usarse para Gravatar , pero Gravatar verifica todas las direcciones de correo electrónico de todos modos.


Existe la posibilidad de tener direcciones de correo electrónico que no sean ASCII, como se muestra en este RFC: http://tools.ietf.org/html/rfc3490 pero creo que esto no se ha establecido para todos los países, y por lo que entiendo solo uno Se permitirá el código de idioma para cada país, y también hay una manera de convertirlo en ASCII, pero eso no será un tema trivial.


He encontrado direcciones de correo electrónico con comillas simples, y no pocas veces tampoco. Rechazamos el espacio en blanco (aunque estrictamente hablando está permitido), más de un signo "@" y cadenas de direcciones de menos de cinco caracteres en total. Creo que esto resuelve más problemas de los que crea, y hasta ahora más de diez años y cientos de miles de direcciones ha funcionado para rechazar muchas direcciones de basura. También hay un disparador para archivar todas las direcciones de correo electrónico al insertar o actualizar.

Dicho esto, es imposible validar un correo electrónico sin un viaje de ida y vuelta al propietario, pero al menos podemos rechazar datos que son extremadamente sospechosos.


La sintaxis permitida en una dirección de correo electrónico se describe en RFC 3696 , y es bastante complicado.

La regla exacta [para la parte local; la parte anterior a ''@'' es que cualquier carácter ASCII, incluidos los caracteres de control, puede aparecer entre comillas o en una cadena entrecomillada. Cuando se necesita una cita, el carácter de barra diagonal inversa se utiliza para citar el siguiente carácter
[...]
Sin comillas, las partes locales pueden consistir en cualquier combinación de caracteres alfabéticos, dígitos o cualquiera de los caracteres especiales. # $% Y ''* + - / =? ^ _ `. {| } ~
[...]
Cualquier carácter, o combinación de bits (como octetos), está permitido en los nombres DNS. Sin embargo, hay una forma preferida que es requerida por la mayoría de las aplicaciones ...

... y así sucesivamente, en profundidad.


La dirección de correo electrónico consta de dos partes local antes @ y el domain que va después.

Las reglas para estas partes son diferentes:

Para local part , puede usar ASCII:

  • Letras latinas A - Z a - z
  • dígitos 0 - 9
  • caracteres especiales! # $% & ''* + - / =? ^ _ `{|} ~
  • punto, que no es el primero ni el último, y no en secuencia
  • space y los caracteres "(),:; <> @ [] se permiten con restricciones (solo se permiten dentro de una cadena entre comillas, una barra diagonal inversa o una comilla doble debe ir precedida de una barra diagonal inversa)
  • Además, desde 2012 puede usar caracteres internacionales por encima de U+007F , codificados como UTF-8 .

Domain part es más restringida:

  • Letras latinas A - Z a - z
  • dígitos 0 - 9
  • guión -, que no es el primero ni el último, se permiten guiones múltiples en secuencia.

Regex para validar

^(([^<>()/[/]/.,;:/s@/"]+(/.[^<>()/[/]/.,;:/s@/"]+)*)|(/".+/"))@(([^<>()[/]/.,;:/s@/"]+/.)+[^<>()[/]/.,;:/s@/"]{2,})

Espero que esto te ahorre algo de tiempo.