Probador de expresiones regulares

Una expresión regular describe un patrón de texto: «cuatro dígitos, un guion, dos dígitos» en lugar de una fecha concreta. Sirve para buscar, validar, extraer y sustituir, y está en casi todos los lenguajes con la misma sintaxis, así que lo que aprendes aquí vale igual en JavaScript, en Python o en el buscador de tu editor.

Escribirlas es fácil de empezar y difícil de acertar a la primera. Por eso se prueban: se escribe la expresión, se pega un texto representativo y se mira qué casa y qué no antes de llevarla al código.

Esta herramienta ejecuta la expresión **fuera del hilo principal**, con un plazo de segundo y medio. Suena a detalle técnico y es lo que evita que la página se quede colgada cuando escribes sin querer una expresión patológica: en lugar de una pestaña bloqueada, sale un aviso.

El motor recorre el texto intentando encajar el patrón en cada posición. Cuando una alternativa falla, retrocede y prueba la siguiente: eso es el backtracking, y es lo que hace potentes a las expresiones regulares y también lo que puede volverlas peligrosas.

Con cuantificadores anidados, el número de combinaciones que hay que probar crece de forma exponencial con la longitud del texto. La expresión «(a+)+b» sobre treinta aes seguidas obliga al motor a explorar más de mil millones de caminos antes de rendirse. Se llama backtracking catastrófico.

JavaScript no tiene forma de poner un límite de tiempo a una expresión regular: una vez arranca, no cede el control ni atiende a ningún temporizador. La única manera de recuperarse es ejecutarla en un proceso aparte al que sí se pueda matar desde fuera, y eso es un web worker.

Conviene un matiz, porque casi nadie lo cuenta: el motor de Chrome ya se defiende de una parte de estos casos. Cuando la expresión no lleva retrovisores ni lookarounds, puede ejecutarla con un algoritmo de tiempo lineal, y ejemplos de manual como (a+)+b se resuelven al instante. Lo que no puede linealizar es todo lo que lleve \1 o (?<=…), y ahí el cuelgue sigue siendo real. En Node, sin esa red, se cuelga hasta el ejemplo de manual.

Van después de la barra de cierre en la notación habitual: /patrón/gi. Aquí se eligen con los botones.

No es un caso de laboratorio. En 2019 una expresión regular mal construida dejó fuera de servicio a Cloudflare durante media hora, y el mismo patrón ha causado caídas en Stack Overflow y en varios proyectos grandes. Se le llama ReDoS cuando alguien lo provoca a propósito enviando una entrada preparada.

El patrón peligroso tiene una forma reconocible: un cuantificador dentro de otro, como (a+)+ o (\w*)*, o alternativas que pueden casar lo mismo, como (a|a)*. Si además el texto no llega a casar del todo, el motor prueba todas las combinaciones antes de rendirse.

La defensa práctica es escribir cuantificadores que no se solapen, acotar las repeticiones con {1,50} en lugar de + cuando sepas el máximo, y desconfiar de cualquier expresión que venga de fuera. Si validas entrada de usuario con una expresión regular, esa expresión es superficie de ataque.

Analizar HTML o XML. No son lenguajes regulares: pueden anidarse hasta el infinito y ninguna expresión regular puede seguir esa estructura. Para eso está un analizador de verdad, como DOMParser en el navegador.

Validar correos electrónicos a rajatabla. La expresión que cumple el RFC 5322 completo ocupa varias líneas y aun así acepta direcciones que ningún servidor entrega. En la práctica basta con comprobar que hay una arroba con algo a cada lado y mandar un correo de confirmación.