Una expresión regular es un lenguaje para describir conjuntos de cadenas, y su mayor riesgo no es equivocarse de sintaxis sino acertar de más: un patrón demasiado permisivo deja pasar datos inválidos y uno demasiado estricto rechaza casos legítimos. Este generador parte de ejemplos concretos, escapa los literales que tienen significado especial y produce un patrón que puedes afinar, probar y llevar directo a `grep -E`, JavaScript, Python o una validación de formulario.
Los metacaracteres que hay que escapar sí o sí
Doce caracteres cambian de significado dentro de un patrón: . ^ $ * + ? ( ) [ ] { } | \. Un punto sin escapar en www.dominio.com encaja con cualquier carácter, de modo que wwwXdominioYcom también valida. Dentro de una clase [...] las reglas cambian: sólo ], \, ^ (si va primero) y - (si va en medio) necesitan tratamiento. Este es el error número uno en validaciones caseras y la razón por la que conviene generar el esqueleto automáticamente en lugar de escribirlo de memoria.
Anclas, límites de palabra y coincidencias parciales
Sin ^ y $ una expresión encaja con cualquier subcadena: el patrón [0-9]{5} valida "mi código es 28001 y sobra texto". En validación de formularios ancla siempre el patrón completo; en búsqueda dentro de logs, al contrario, las anclas te estorban y lo que quieres es \b para respetar límites de palabra. Ojo con multilínea: en JavaScript y Python la bandera m hace que ^ y $ encajen en cada salto de línea, mientras que \A y \z (en Python) siguen refiriéndose al texto completo.
Cuantificadores codiciosos, perezosos y catastróficos
.* es codicioso: consume hasta el final y retrocede. .*? es perezoso y para en la primera coincidencia. La diferencia importa al extraer contenido entre delimitadores: con <b>(.*)</b> sobre dos etiquetas capturas todo lo que hay entre la primera apertura y el último cierre. El problema grave es el backtracking catastrófico: patrones como (a+)+$ sobre una cadena larga que no encaja provocan un número exponencial de intentos y bloquean el proceso. Es una vulnerabilidad real (ReDoS) que ha tumbado servicios en producción; evita cuantificadores anidados y prefiere clases explícitas a .* cuando el patrón se aplique a entrada de usuario.
Diferencias entre motores: PCRE, JavaScript, Python y POSIX
grep sin -E usa expresiones básicas donde +, ? y | deben escaparse; grep -E y egrep usan las extendidas; grep -P habilita PCRE con \d, lookahead y grupos con nombre. JavaScript no soportó lookbehind hasta ES2018 y sigue sin tener el modificador x de patrones comentados. Python usa (?P<nombre>...) para grupos con nombre frente al (?<nombre>...) de PCRE y JavaScript. Antes de copiar un patrón de internet comprueba para qué motor se escribió: la mitad de los fallos de "no funciona" son de dialecto, no de lógica.
Casos donde una regex es la herramienta equivocada
No valides emails con una expresión exhaustiva: la gramática del RFC 5322 es tan permisiva que el patrón resultante es ilegible e igualmente incapaz de saber si el buzón existe. Comprueba que hay una arroba, un dominio con punto y envía un correo de verificación; para eso está el validador de email. Tampoco parsees HTML o XML con regex: son lenguajes anidados y necesitas un parser real, como el que usa el validador de XML. Y para logs con estructura fija, un awk por campos suele ser más rápido y mucho más legible.
Cómo probar y documentar un patrón
Construye siempre una batería mínima de casos: tres que deban validar, tres que deban fallar y uno límite (cadena vacía, espacios al inicio, acentos, mayúsculas). Usa el modificador i sólo si de verdad quieres ignorar mayúsculas y recuerda que en Unicode i no cubre todas las equivalencias sin la bandera u. Por último, comenta el patrón en el código: un # valida matrícula española: 4 dígitos + 3 consonantes ahorra media hora a quien lo lea dentro de un año, y ese alguien serás tú.
Casos de uso comunes
- Validar formatos fijos como matrículas, códigos postales, IBAN o referencias internas.
- Extraer campos de un log con `grep -E` o `sed`.
- Definir reglas de reescritura en Apache o Nginx sin romper el sitio.
- Filtrar nombres de fichero en un script de limpieza.
- Buscar y reemplazar de forma masiva en un editor o en `sed -i`.
Buenas prácticas
- Ancla con `^` y `$` cualquier patrón de validación.
- Escapa el punto: `.` encaja con cualquier carácter.
- Evita cuantificadores anidados sobre entrada de usuario para prevenir ReDoS.
- Prueba siempre con casos que deban fallar, no sólo con los que deban pasar.