¿Por qué las personas usan la expresión regular para el correo electrónico y otras validaciones complejas?

Question

Hay email regexp questions apareciendo up aquí, y estoy sinceramente desconcertado por qué las personas están usando estas insanely obtuse expresiones coincidentes en lugar de un analizador muy simple que divide el correo electrónico en los tokens de nombre y dominio, y luego valida esos contra los caracteres válidos permitidos para el nombre (no se puede hacer más comprobaciones en esta parte) y los caracteres válidos para el dominio (y supongo que podría agregar la verificación de todos los TLD del mundo y luego otro nivel de dominios de segundo nivel para países con tales (es decir, com.uk)).

El problema real es que los tlds y slds siguen cambiando (contrariamente a la creencia popular), por lo que debe actualizar la expresión regular si planea hacer todo este control de alto nivel cuando los servidores de nombres raíz envían un cambio.

¿Por qué no tener un módulo que simplemente valida los dominios, que extrae de una base de datos, o un archivo plano, y opcionalmente verifica el DNS para los registros coincidentes?

Estoy hablando en serio, ¿por qué todos están tan interesados ​​en inventar la expresión regular perfecta para esto? No parece ser una solución adecuada al problema ...

Convencerme de que no solo es posible hacerlo en expresiones regulares (y satisfacer a todos), sino que es una solución mejor que un analizador/validador personalizado.

-Adam

Answer 1

Lo hacen porque ven "Quiero probar si este texto coincide con la especificación" y de inmediato piensan "Lo sé, usaré una expresión regular". sin entender completamente la complejidad de la especificación o las limitaciones de las expresiones regulares. Los regex son una herramienta maravillosa y poderosa para manejar una amplia variedad de tareas de correspondencia de texto, pero no son la herramienta perfecta para cada tarea y parece que muchas personas que las usan pierden de vista ese hecho.

Answer 2

expresiones regulares son mucho más rápidos de usar, por supuesto, y sólo se validan lo que se especifica en el RFC. Escribir un analizador personalizado? ¿Qué? Toma 10 segundos usar una expresión regular.

Answer 3

Los Regex que captan la mayoría (pero no todos) de los errores comunes son relativamente fáciles de configurar e implementar. Toma más tiempo escribir un analizador personalizado.

Answer 4

Usar expresiones regulares para esto es no una buena idea, como se ha demostrado extensamente en esas otras publicaciones.

Supongo que las personas siguen haciéndolo porque no conocen nada o no les importa.

¿Será mejor un analizador? Tal vez tal vez no.

Sigo diciendo que enviar un correo electrónico de verificación es la mejor manera de validarlo. Si desea verificar algo desde JavaScript, compruebe que tiene un signo '@' y algo antes y después. Si vas más estricto que eso, te tropiezas con una sintaxis que no conocías y tu validador se volverá demasiado restrictivo.

Además, tenga cuidado con el esquema de validación TLD suyo, puede encontrar que es assuming too much acerca de lo que está permitido en un TLD.

Answer 5

Las personas escriben expresiones regulares porque a la mayoría de los desarrolladores les gusta resolver un problema simple de la manera más "buena" y "eficiente" (lo que significa que debe ser lo más ilegible posible).

En Java, hay bibliotecas para verificar si una Cadena representa una dirección de correo electrónico sin tener que saber nada sobre las expresiones regulares. Estas bibliotecas deben estar disponibles para otros idiomas aswel.

Como Jamie Zawinski dijo en 1997: "Algunas personas, cuando se enfrentan con un problema, piensan" Lo sé, usaré expresiones regulares. "Ahora tienen dos problemas".

Answer 6

La gente lo hace porque en la mayoría de los idiomas es mucho más fácil escribir expresiones regulares que escribir y usar un analizador en el código (o al menos eso parece).

Si decide evitar las expresiones regulares, tendrá que escribir analizadores a mano, o recurrir a herramientas externas (como yacc) para la generación de lexer/analizador. Esto es mucho más complejo que la comparación de expresiones regulares de una sola línea.

Uno necesita tener una biblioteca que hace que sea fácil escribir analizadores directamente en el lenguaje X (donde 'X' es C, C++, C#, Java) para poder construir analizadores personalizados con la misma facilidad que la expresión regular matchers.

Dichas bibliotecas se originaron en el terreno funcional (Haskell y ML), pero hoy en día existen "bibliotecas de combinadores de analizadores" para Java, C++, C#, Scala y otros lenguajes principales.

Answer 7

La gente utiliza expresiones regulares para direcciones de correo electrónico, HTML, XML, etc. porque:

1. Se ve como deben trabajar y que a menudo hacer el trabajo de los casos obvios.
2. "Saben" expresiones regulares. Cuando todo lo que tienes es un martillo todos tus problemas parecen clavos.
3. Escribir un analizador es más difícil (o parece más difícil) que escribir una expresión normal . En particular, escribir un analizador es más difícil que escribir una expresión regular que maneje los casos obvios en el # 1.
4. No comprenden la complejidad total de la tarea.
5. No comprenden las limitaciones de las expresiones regulares.
6. Comienzan con una expresión regular que maneja los casos obvios y luego prueban para extenderla a otros. Se bloquean en un enfoque.
7. Ellos no son conscientes de que hay (probablemente) una biblioteca disponible para hacer el trabajo para ellos.

Answer 8

La tentación de usar RegExp, una vez que dominas los conceptos básicos, es muy grande. De hecho, RegExp parece tan poderoso que la gente naturalmente quiere comenzar a usarlo en todas partes. Realmente sospecho que hay una gran cantidad de psicología involucrada aquí, como lo demuestra el XKCD comic de Randall (y sí, es es útil).

He hecho una presentación introductoria sobre RegExp una vez y la diapositiva más importante advirtió sobre su uso excesivo. Fue la única diapositiva que usó la fuente negrita. Creo que esto debería hacerse más a menudo.

Answer 9

y luego se valida aquellos contra los caracteres válidos permitidos para el nombre (no hay comprobación adicional que puede ser realiza en esta parte)

Esto no es cierto. Por ejemplo, "ben..doom @ gmail.com" contiene solo caracteres válidos en la sección de nombre, pero no es válido.

En lenguajes que no tienen bibliotecas de validación de correo electrónico, generalmente uso de expresiones regulares robaba

1. Sé expresiones regulares, y les resulta fácil de usar
2. tengo muchos amigos que saben de expresiones regulares, y puedo colabore con
3. Me resulta más rápido codificar, y el tiempo-me resulta más caro que el tiempo del procesador para la mayoría de las aplicaciones
4. Para la mayoría de las direcciones de correo electrónico, funciona.

Estoy seguro de que muchas bibliotecas integradas usan su enfoque, y si quiere abarcar todas las posibilidades, se vuelve ridículo. Sin embargo, también lo hace tu analizador. La especificación formal para las direcciones de correo electrónico es absurdamente compleja. Entonces, usamos una expresión regular que se acerca lo suficiente.

Answer 10

No creo que la validación correcta del correo electrónico se pueda hacer con una sola expresión regular (¡ahora hay un desafío!). Uno de los problemas es que los comentarios se pueden anidar a una profundidad arbitraria tanto en la parte local como en el dominio.

Si desea validar una dirección contra las RFC 5322 y 5321 (las normas actuales), entonces necesitará una función de procedimiento para hacerlo.

Afortunadamente, este es un problema de productos básicos. Todo el mundo quiere el mismo resultado: cumplimiento de RFC. No es necesario que nadie vuelva a escribir este código una vez que haya sido resuelto por una función de código abierto.

ver algunas de las alternativas aquí: http://www.dominicsayers.com/isemail/

Si sabes de otra función que pueda añadir a la cabeza de cabeza a, que me haga saber.

Answer 11

Estamos buscando una forma rápida de ver si la dirección de correo electrónico es válida para que podamos advertir al usuario que ha cometido un error o evitar que las personas entren basura fácilmente. Ir al servidor de correo y digitarlo es lento y poco confiable. La única forma real de estar seguro es recibir un correo electrónico de confirmación, pero el problema es solo dar una respuesta rápida al usuario antes de que tenga lugar el proceso de confirmación. Es por eso que no es tan importante ser estrictamente obediente. De todos modos, es un desafío y es divertido.

Answer 12

Factor: el conjunto de personas que entienden cómo escribir una expresión regular es mucho más grande que el conjunto de personas que entienden las restricciones formales en los idiomas regulares. Lo mismo ocurre con las "expresiones regulares" no regulares.