2010-10-02 15 views
47

Estoy construyendo un sitio web usando `Django. El sitio web podría tener usuarios importantes de países que no hablan inglés.¿Se permite que las direcciones de correo electrónico contengan caracteres no alfanuméricos?

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 en inglés, números, "_", "@" y "."?

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

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

Respuesta

26

Dirección de correo electrónico consists of two partslocal antes @ y domain que va después.

Reglas a estas partes son diferentes:

Para local part puede utilizar ASCII:

  • letras latinas A - Z - Z
  • dígitos 0 - 9
  • caracteres especiales #! $% & '* + -/=?^_ `{|} ~
  • punto, que no es el primero ni el último, y no está en secuencia
  • espacio y "(),:; <> @ [] caracteres están permitidos con restricciones (que sólo se permiten dentro de una cadena entre comillas, una barra invertida o de comillas dobles deben estar precedidos por una barra invertida)
  • Plus since 2012 puede utilizar internacional characters aboveU+007F, codificado as UTF-8.

Domain part está más restringido:

  • letras latinas A - Z a - z
  • dígitos 0 - 9
  • guión -, que no es primero o el último, varios guiones en secuencia son permitido.

Regex to validate

^(([^<>()\[\]\.,;:\[email protected]\"]+(\.[^<>()\[\]\.,;:\[email protected]\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\[email protected]\"]+\.)+[^<>()[\]\.,;:\[email protected]\"]{2,})

Hope esto le ahorra tiempo.

+0

¿Dónde está la aplicación de estas restricciones de "dominio de parte"? 'Letras en latín A - Z a - z' ' dígitos 0 - 9 ' – user3175580

+0

Solo vamos a agregar aquí @ matas-vaitkevicius, RFC 6531 está ** propuesto ** estándar. Aún no es un estándar completo. –

+0

Regex no funciona en JAVA; pattern = Pattern.compile ("^ (([^ <>() \ [\] \.,;:: \ s @ \"] + (\. [^ <>() \ [\] \.,;: \ s @ \ "] +) *) | (\". + \ ")) @ (([^ <>() [\] \.,;: \ s @ \"] + \.) + [^ <>() [\] \.,;: \ s @ \ "] {2,})", Pattern.CASE_INSENSITIVE); – Furkan

35

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

Vivo en Argentina y aquí son mensajes permitido como ñoñó[email protected]

+9

Sus caracteres de ejemplo están en el conjunto latin1, y no requieren unicode completo. – Bryce

+4

No puedo encontrar un servicio que permita esas direcciones de correo electrónico, ¿puede señalar uno? – theCakeCoder

+0

@ eKek0, ¿Son comunes estas direcciones de correo electrónico? ¿Estaría bien tener una política para desactivar direcciones de correo electrónico que no sean de ASCII? – Pacerier

4

Existe la posibilidad de tener direcciones de correo electrónico que no son ASCII, como se muestra por 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 se permitirá un 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.

17

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. Al citar es necesaria, la barra invertida se utiliza para citar el carácter que sigue
[...]
sin comillas, locales de partes puede consistir en cualquier combinación de caracteres alfabéticos, dígitos, o cualquiera de los caracteres especiales ! # $% & '* + -/=?^_ `. {| } ~
[...]
Cualquier carácter, o combinación de bits (como octetos), está permitido en nombres DNS. Sin embargo, hay una forma preferida que es requerida por la mayoría de las aplicaciones ...

... y así sucesivamente, con cierta profundidad.

9

En lugar de preocuparse por lo que las direcciones de correo electrónico pueden y no pueden contener, lo que realmente no le importa, compruebe si su configuración puede enviarlas o no; ¡esto es lo que realmente le 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 de tipeo accidentales que permanecen dentro de cualquier conjunto de caracteres que usted idee. (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 un 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 le importa enviarles un correo electrónico, simplemente tome lo que ingrese. Por ejemplo, la dirección solo se puede usar para Gravatar, pero Gravatar verifica todas las direcciones de correo electrónico de todos modos.

+17

Es presuntuoso decirle a las personas lo que hacen y lo que no les importa. (Por ejemplo, dado que las direcciones de correo electrónico generalmente no distinguen entre mayúsculas y minúsculas, es importante saber si debe tratar con Unicode o solo con ASCII). –

2

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.

+0

Las direcciones de correo electrónico (la parte del usuario ...) pueden ser sensibles a mayúsculas .... (Se recomienda que no lo estén, consulte [RFC5321] (https://tools.ietf.org/html/rfc5321) sección 2.4) No debe alterar el caso de las direcciones recibidas .... (cuando se usa como nombre de usuario, Sin embargo, podría ser razonable ignorar el caso ...) (Técnicamente, [email protected] y [email protected] pueden ser usuarios diferentes ...) (Conozco un caso hace años en el que un sistema de correo requería que el caso coincidiera (por ejemplo, [email protected] funcionó, [email protected] no lo hizo) para que los correos electrónicos lleguen a los usuarios finales ...) –

Cuestiones relacionadas