Angular.js: validador de correo electrónico es incorrecto

Sí, tienes razón, parece que EMAIL_REGEX está mal.

Según http://dev.w3.org/html5/markup/input.email.html , podemos utilizar

/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

y parece que debería funcionar mejor debido a que no incluye . después de @

Intentaré enviar un parche rápido para esto.

... en realidad, esto es un poco más complicado de lo que pensé, esto podría requerir un poco más de trabajo. Parece que también aceptará expresiones regulares que comienzan con un punto. Así que supongo que hay un poco de trabajo por hacer aquí.

Si puede resolver esto antes que yo, no dude en enviar una solicitud de extracción

Gracias por reportar el error. En la demostración de documentos, no notará esta corrección hasta que caiga 1.2.10, porque carga el script angular 1.2.9 todo el tiempo. Pero en unos días debería ver esto abordado en la demostración del documento (a menos que la confirmación se revierta, lo que podría suceder O_O)

¡Genial, 10x!

El miércoles 22 de enero de 2014 a las 5:32 a. M., Caitlin Potter [email protected] escribió :

Gracias por reportar el error. En la demostración de documentos, no notará esta corrección
hasta que caiga 1.2.10, porque carga el script angular 1.2.9 todo el tiempo.
Pero en unos días debería ver esto abordado en la demostración del documento.

-
Responda a este correo electrónico directamente o véalo en Gi
.

¿Cuál fue mi expresión facial cuando noté que " dummy @ ferferfe " (sin ningún dominio) se considera un correo válido;)

@ mica16 pero dummy@ferferfe es una dirección de correo electrónico válida. Los dominios no necesitan tener una extensión, solo piense en localhost .

@Zequez correcto, pero ¿quién diablos usa una dirección de

@mbeckenbach Uso
ng-pattern = "/ ^ [a-z0-9! # $% & '* + / =? ^ _` {|} ~ .-] + @ [a-z0-9 -] +. [a-z0 -9 -] / "
No es ideal pero funciona.

@mbeckenbach sí, cierto. Pero considere que un nombre de dominio sin puntos es un dominio válido. Que ICANN no le permita registrar un dominio con ELLOS, no significa que el nombre de dominio no sea válido.

6 @ 6 no es una dirección de correo electrónico. El hecho de que pueda ser una dirección de correo electrónico adecuada en una circunstancia especial no debería, en mi opinión, llevarnos a permitirlo. Las probabilidades de que se produzca un error a través de este patrón permisivo son órdenes de magnitud mayores que las probabilidades de que excluyamos a alguien con esa dirección de correo electrónico.

+1 para Jeff

@jeffmcmahan Lo siento, pero parece que debería presentar un problema con el IETF o el WHATWG. Una vez que cambia la definición de cómo se ve una dirección de correo electrónico, entonces debería cambiarse en Angular, pero realmente debemos seguir lo que se describe en las recomendaciones de RFC y WHATWG.

Ahora, si desea ser un poco más estricto, también puede agregar un validador de patrones, eso estaría bien.

@caitp Eres el jefe.

¿Qué tal si configuramos EMAIL_REGEXP? Nuestra validación del lado del servidor es más estricta que la de angularjs. Específicamente, requiere, por ejemplo, que la parte antes del signo @ no tenga más de 63 caracteres. Ahora tenemos que crear una directiva personalizada para todas las entradas de correo electrónico o recordar agregar el patrón ng a cada entrada de correo electrónico.

puede usar ng-pattern además de type = email, @rjokelai ; además, el cambio en la canalización de validación de @matsko facilitará la adición de validación de correo electrónico personalizada

"Ahora, si quieres ser un poco más estricto, también puedes agregar un validador de patrones, eso estaría bien".

¿Qué tal el validador predeterminado solo acepta correos electrónicos normales con un punto en ellos, y si alguien en la pequeña minoría quiere ser menos estricto, puede crear su propio validador? ¿Por qué la gran mayoría de los desarrolladores deberían crear su propio patrón para que la pequeña minoría no tenga que hacerlo? Esto es purismo de estándares tontos

porque esto es básicamente un polyfill para la validación de restricciones html5, es por eso. Con suerte, la semana que viene estaremos enviando una función que hará que la personalización sea mucho más fácil.

¿Son válidos los correos electrónicos sin zona de dominio? Estoy probando un campo de entrada simple con type = "email" y Angular valida el correo electrónico _foo @ bar_ con éxito. (Angular v1.3.0)

Oh, ya hay un problema cerrado: https://github.com/angular/angular.js/issues/9463

¿Son válidos los correos electrónicos sin zona de dominio? Estoy probando un campo de entrada simple con type = "email" y Angular valida el correo electrónico foo @ bar con éxito. (Angular v1.3.0)

Son correos electrónicos válidos, según las especificaciones. Esta pregunta ha sido respondida tantas veces en este rastreador de problemas, no hay nada inválido en un correo electrónico sin un TLD.

Utilice un validador personalizado para solicitar los TLD específicos que desee

@caitp , me doy cuenta de que te hemos estado molestando por esto, pero creo que podría ser útil si explicaras por qué es imperativo cumplir con las especificaciones. Todos reconocemos que un desarrollador razonable y competente no va a asumir que el validador de correo electrónico permite _0 @ 0_. Es decir, se utilizará para la situación de registro de formularios estándar y causará problemas en muchas de estas situaciones. Y nos dicen que la importancia de respetar las especificaciones supera esos problemas. Está bien --- genial. ¿Pero por qué?

Porque va a ser realmente extraño cuando su navegador dice que es válido y angular dice que no lo es

No está buscando una validación por correo electrónico, está buscando una validación de patrones además de la validación por correo electrónico: desea direcciones de correo electrónico válidas (manejadas por angular) que coincidan con un patrón específico (contiene un TLD)

1. ¿Sería extraño cuando agregas la validación de patrones y luego "tu navegador dice que es válido y [A] ngular dice que no lo es"? No. Entonces, ¿por qué sería extraño si esa validación de patrones estuviera incorporada?
2. Todos somos conscientes de que lo que pasa por un correo electrónico válido en el caso de uso que nos interesa es más limitado que la especificación.

_Sólo quiero saber por qué Angular no debería servir para el caso de uso que me interesa, ya que es el caso general.

Entonces, ¿por qué sería extraño si esa validación de patrones estuviera incorporada?

En realidad, obtienes el mismo comportamiento del navegador. http://jsfiddle.net/t6rdmngo/ Si ejecuta esto en un navegador moderno, no podrá enviar el formulario superior debido a una discrepancia de patrón si no incluye un TLD.

En la versión angular, obtienes el mismo comportamiento. Esto es bueno. Esto es lo que queremos. Comportamiento idéntico entre el comportamiento nativo y el comportamiento del marco. El marco no debería tener desacuerdos con la plataforma.

Ahora lo entiendo. ¡Gracias por aguantarme!

Puedes arreglar esto rápidamente usando ng-pattern

<input type="email" ng-pattern="/^[_a-z0-9]+(\.[_a-z0-9]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$/">

Si cambia el último * a + en la expresión regular, funciona como se esperaba

http://w3c.github.io/html-reference/input.email.html

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