¿Por qué la validación de formularios HTML5 permite correos electrónicos sin un punto?

112

Estoy escribiendo una maqueta muy simple para demostrar algo de validación de formularios HTML5. Sin embargo, noté que la validación de correo electrónico no verifica un punto en la dirección, ni busca caracteres después de dicho punto.

En otras palabras, "john @ doe" se considera válido, cuando claramente no es una dirección de correo electrónico válida; "doe" no es un dominio.

Así es como estoy codificando mi campo de correo electrónico:

<input type="email" required />

¿No es suficiente?

Mira este violín para ver a qué me refiero.

Nota: sé cómo lograr esto a través de un patrón RegEx. Me pregunto cómo alguien podría salirse con la suya usando el tipo de correo electrónico.

html email-validation

— WEFX
fuente

10

In other words, "john@doe" is considered valid, when it's clearly not a valid email address; doe isn't a domain.Sí, doedefinitivamente puede ser un dominio (piense localhost), y esa dirección es técnicamente válida según las especificaciones.

— admdrew

2

@admdrew Je ... ese sería un caso interesante, si está enviando un correo electrónico desde el servidor de correo y decide escribir "amigo @ localhost"

— Katana314

@ Katana314 - je, sí. La mayoría de los servidores de correo (bien configurados) rechazarán los mensajes que se envíen a direcciones que no coincidan con un dominio esperado, por lo que, en general, no hay ningún problema con las localhostdirecciones.

— admdrew

1

posible duplicado de ¿Cómo funciona el correo electrónico de tipo de entrada HTML5 sin un nombre de dominio de nivel superior?

— Léo Lam

83

Porque a @ b es una dirección de correo electrónico válida (por ejemplo, localhost es un dominio válido). Ver http://en.wikipedia.org/wiki/Email_address#Examples

Además, tenga en cuenta que siempre debe realizar la validación de entrada en el servidor. La validación del lado del cliente debe ser solo para dar retroalimentación al usuario y no ser confiable, ya que se puede omitir fácilmente.

— Ali Alavi
fuente

7

Gracias. Simplemente no veo cómo ninguna empresa podría beneficiarse de esta validación de correo electrónico lista para usar. Facebook no permitiría que alguien se registre con una dirección a @ b. Gracias por la informacion sin embargo. (No

— voté

6

En el caso de sitios web como Facebook con acceso público, no sirve de nada. Pero piense en sitios web internos. Es posible que desee escribir a joe @ support. Pero también creo que tiene un uso mínimo. Sin embargo, los navegadores web se implementarán en base a estándares (es decir, RFC), no a los casos más comunes.

— Ali Alavi

9

Me pregunto cuándo fue la última vez que alguien envió un correo electrónico a localhost.

— Matthew Lock

2

Como una nota al margen de las direcciones de correo electrónico de trabajo más cortas ( recordsetter.com/world-record/shortest-email-address/4327 ) esau@ua

— Kyborek

132

En teoría, puede tener una dirección sin un "." en.

Dado que técnicamente cosas como:

user@com
user@localserver
user@[IPv6:2001:db8::1]

Son todos correos electrónicos válidos.

Por lo tanto, la validación estándar de HTML5 permite todos los correos electrónicos válidos, incluidos los poco comunes.

Para obtener explicaciones fáciles de leer (en lugar de leer los estándares): http://en.wikipedia.org/wiki/Email_address#Examples

— DBS
fuente

1

De acuerdo, éste responde al "por qué", no a la "solución". También tenía curiosidad sobre el por qué. Ahora sé que no debo "arreglar".

— Eleanor Zimmermann

Un ejemplo del primer tipo es el dominio uz, que apunta directamente a una IP a partir de octubre de 2018. Si lo hace nslookup uz, apunta a 91.212.89.8, por lo que también debería ser posible tener correo electrónico en este dominio.

— PulseJet

36

Intente agregar esto a la entrada

pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,63}$"

Violín

— APAD1
fuente

2

Con muchos dominios nuevos disponibles, es decir (contables [11], internacionales [13], etc.) y una longitud máxima potencial de 63, el valor de longitud del patrón de expresiones regulares debería ser {2, 63}.

— unasAquila

42

-1. En primer lugar, ni siquiera ha intentado explicar qué permite o restringe esto, ni por qué alguien querría esas reglas. En segundo lugar, es mucho más restrictivo de lo que permiten los estándares (no pretendo haber leído y asimilado los estándares, pero consulte, por ejemplo, en.wikipedia.org/wiki/Email_address#Internationalization o las muchas preguntas de validación de correo electrónico en Stack Desbordamiento de ejemplos de direcciones de correo electrónico extrañas). ¿Por que hacerlo? Si alguien ingresa algo inusual como su correo electrónico, simplemente acéptelo; es probable que lo sepa mejor que usted.

— Mark Amery

7

En realidad, yo diría que "es probable" que estén cometiendo un error. Es posible que tengan una dirección de correo electrónico muy inusual, pero yo diría que la mayoría de las veces simplemente obtendría una dirección de correo electrónico correcta en lugar de una incorrecta si dejara de pasar la validación y solicitara el usuario para comprobar.

— Geoff Kendall

1

Esto debe tener un ^, lo que indica que debe comenzar a coincidir desde el principio de la cadena y también aceptar mayúsculas:^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]+$

— Kohjah Breese

13

El RFC 822 , capítulo 6, proporciona la especificación de una dirección en forma aumentada Backus-Naur (BNF):

addr-spec   =  local-part "@" domain
local-part  =  word *("." word)
domain      =  sub-domain *("." sub-domain)

El uso de esta especificación a@bes una dirección válida.

ACTUALIZAR

Para responder al comentario de Trejkaz, agrego las siguientes definiciones. Vemos que se permite el ESPACIO pero solo entre comillas.

word          =  atom / quoted-string
atom          =  1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">
SPACE         =  <ASCII SP, space>
CTL           =  <any ASCII control character and DEL> 
qtext         =  <any CHAR excepting <">, "\" & CR, and including linear-white-space>
quoted-pair   =  "\" CHAR

— Ortomala Lokni
fuente

OTOH, RFC 822 también me permite poner espacios en la parte local, lo que Chrome al menos no parece permitir, así que no estoy seguro de que usen el RFC como referencia. (¡Aunque deberían serlo!)

— Trejkaz

8

En esta página de MDN, muestra las expresiones regulares que los navegadores deben usar para validar el correo electrónico:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#Validation

Puede cambiar ligeramente esta expresión regular para requerir al menos un punto en el nombre de dominio: cambie la estrella *al final de la expresión regular a un signo más +. Luego use esa expresión regular como patternatributo:

<input type="email" pattern="^[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])?)+$"></input>

— gitaarik
fuente

3

Puede personalizar el patrón del campo de correo electrónico:

input:valid {
  border-color: green
}

input:invalid {
  border-color: red
}

Email:
<input type="email" required value="a@b.c" /><br>

Non-dots Email:
<input type="email" required pattern="[^.]+@[^.]+" value="a@b.c" />

Expandir fragmento

— dorio
fuente

2

Así es como puede hacerlo con html5 usando el patrón de expresiones regulares. También puede incluir un mensaje personalizado para mostrar.

<form>
  <input type="email" value="paul@test" required pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,63}$" title="Hey, you are missing domain part in the email !!!"/>
  <button type="submit">Click Me</button>
</form>

Expandir fragmento

— Hari Das
fuente

-5

Este patrón siempre me funciona.

El texto debe estar en minúsculas, pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"pero creo que cubre más o menos la mayoría de los correos electrónicos.

— TSlegaítis
fuente