Biblioteca de patrones Regex

Acerca de esta biblioteca

Es una colección organizada y buscable de más de 60 patrones de expresiones regulares habituales, agrupados por categoría. Cada patrón incluye una descripción, la expresión en sí y ejemplos de coincidencias. Haz clic en un patrón para copiarlo, o usa el panel de prueba rápida para validar un texto contra él directamente en esta página.

Todo se ejecuta en tu navegador · ningún patrón ni texto de prueba se envía a ningún sitio. Usa estos patrones en JavaScript, Python, PHP, Java, Go o cualquier lenguaje compatible con expresiones regulares. Para pruebas más avanzadas con flags y grupos de captura, prueba nuestro Probador y depurador de Regex.

De dónde vienen las expresiones regulares

La idea matemática de un «conjunto regular» fue formalizada por Stephen Cole Kleene en 1951 en el memorando de investigación de RAND Representation of Events in Nerve Nets and Finite Automata. El operador * de esta página todavía se llama estrella de Kleene en su honor. Ken Thompson convirtió la teoría en un algoritmo en su artículo de junio de 1968 en Communications of the ACM, Programming Techniques: Regular Expression Search Algorithm, y entregó la primera implementación de regex en el editor QED en Bell Labs. Para 1973, el mismo motor impulsaba ed, luego grep (la expansión literal es «globally search for regular expression and print»), sed y awk. Perl de Larry Wall (1987) y especialmente Perl 5 (1994) añadieron grupos nombrados, lookaround, cuantificadores no codiciosos y manejo Unicode que se convirtieron en el dialecto de facto conocido como PCRE, portado a C como biblioteca por Philip Hazel en 1997.

Variantes de motor y qué cambia entre ellas

Un patrón que se ejecuta limpiamente en JavaScript puede fallar silenciosamente en Go y ser rechazado directamente en POSIX. Las cinco variantes que un desarrollador probablemente encontrará:

• POSIX BRE / ERE (IEEE Std 1003.2-1992): el dialecto de grep, sed y awk en un Unix estándar. Sin lookaround, sin grupos nombrados, sin escapes de propiedad Unicode. BRE además requiere escapar (, ), {, } y |.
• PCRE2 (Philip Hazel, 1997, versión mayor actual 10.x): el dialecto más completo en funcionalidades. Lookaround, grupos nombrados (?<name>...), grupos atómicos, cuantificadores posesivos, recursión. Usado por PHP preg_*, Apache, nginx, R.
• Regex ECMAScript (ECMA-262, sección regex 22.2): el dialecto JavaScript. ES2018 añadió grupos nombrados, lookbehind y los flags s (dotAll) y u (Unicode). ES2022 añadió el flag d para índices de coincidencia. ES2024 añadió el flag v con clases de notación de conjunto.
• Python re: cercano a PCRE, pero usa (?P<name>...) para grupos nombrados (PEP 433) y un modo verboso diferente re.X. El módulo de terceros más nuevo regex añade patrones recursivos y semántica POSIX de coincidencia más larga.
• RE2 (Russ Cox, 2010): el motor detrás del regexp de Go y la crate regex de Rust. Sin lookaround, sin retrorreferencias, sin cuantificadores posesivos, a propósito. La compensación: tiempo lineal garantizado, sin retroceso catastrófico. Si un patrón de esta biblioteca usa (?=...) o \1, no compilará en Go.

Retroceso catastrófico y ReDoS

La mayoría de motores regex en lenguajes principales (PCRE, Java, JS V8 / SpiderMonkey / JavaScriptCore, Python re, .NET) son motores de retroceso. Cuando un patrón con cuantificadores anidados como (a+)+ se encuentra con una entrada que casi coincide, el motor puede probar un número exponencial de caminos alternativos antes de rendirse. Esto es retroceso catastrófico, y es la base de la clase de ataque ReDoS (Regular expression Denial of Service) catalogada por OWASP.

Stack Overflow, 20 de julio de 2016: un patrón diseñado para recortar espacios en blanco al inicio y al final, aplicado a un cuerpo de pregunta que contenía 20 000 caracteres de espacio consecutivos, tomó 11 minutos de CPU por solicitud e hizo que el sitio fuera inaccesible durante 34 minutos. El post-mortem en el blog oficial Stack Status recomendó reemplazar las regex de recorte por el trim nativo de cadena.

Cloudflare, 2 de julio de 2019: una regla WAF que contenía el patrón de cuantificador anidado .*(?:.*=.*) fue desplegada globalmente y consumió el 100 % del CPU en cada servidor edge durante 27 minutos, dejando offline grandes porciones de internet público. El post-mortem de Cloudflare en su blog acreditó el cambio a la crate regex de Rust (un motor basado en RE2, tiempo lineal) por prevenir la recurrencia.

Las lecciones defensivas: evitar cuantificadores anidados ((a+)+, (a*)*, (a|aa)+); evitar recortes estilo \s+$ en entradas controladas por el atacante; preferir grupos atómicos (?>...) o cuantificadores posesivos a++ en PCRE; y para servicios de alto rendimiento, considerar un motor basado en RE2.

Email, URL, teléfono, fecha, tarjeta de crédito: cuándo no usar regex

Email. La gramática completa de RFC 5322 (octubre de 2008) se compila en una regex de unos 3 000 caracteres. La especificación HTML5 del W3C para la validación de <input type="email"> usa una regex mucho más corta «es-esto-plausiblemente-un-email» que es el punto de partida correcto para las indicaciones del lado cliente. RFC 6531 (febrero de 2012) permite direcciones no ASCII como 用户@example.com, que una regex solo ASCII rechazará incorrectamente. El consenso de la industria desde RFC 6532: no validar emails con regex, enviar un email de verificación en su lugar.

URL. RFC 3986 (enero de 2005) es la spec de sintaxis genérica URI, pero el WHATWG URL Living Standard diverge deliberadamente de ella para coincidir con lo que los navegadores realmente aceptan. Use new URL("...") en JavaScript o urllib.parse en Python en lugar de regex para cualquier cosa más allá de una verificación visual rápida.

Números de teléfono. La Recomendación E.164 de la UIT-T (revisión actual noviembre de 2010) permite hasta 15 dígitos con un prefijo + opcional, pero las reglas específicas de cada país varían enormemente. La biblioteca de código abierto de Google libphonenumber codifica las reglas por país para cada territorio y es el único validador confiable inter-país.

Fechas. Una regex como ^\d{4}-\d{2}-\d{2}$ coincide con el formato calendario ISO 8601-1:2019, pero también acepta 2026-02-31. La validez de fecha requiere lógica calendaria, no coincidencia de patrón; use Date.parse() o una biblioteca de fechas.

Tarjetas de crédito. Una regex puede coincidir con la longitud de dígitos y el prefijo IIN (Visa empieza con 4, Mastercard con 51-55 o 2221-2720, Amex con 34 o 37) pero no puede verificar la suma de comprobación Luhn (Hans Peter Luhn, IBM, patente EE.UU. 2 950 048 concedida en agosto de 1960). Luhn requiere una suma dígito por dígito módulo 10.

Formas comunes en que los desarrolladores usan esta biblioteca

• Indicaciones de formulario del lado cliente, con el entendimiento de que un acierto de regex es una indicación, no una validación final.
• Extracción de logs, sacando marcas de tiempo, IP, códigos de error y URL de los logs de la aplicación hacia un pipeline.
• Limpieza de datos puntual: normalizar espacios, eliminar etiquetas HTML, convertir entre formatos de fecha, slugificar títulos.
• Buscar-reemplazar en editor en VS Code, Sublime, vim, IntelliJ donde la variante regex es cercana a PCRE.
• Patrones de coincidencia de router y URL en Express, Flask, FastAPI, Rails.
• Reglas WAF y detección de intrusiones, con extrema precaución sobre ReDoS como demostró el incidente de Cloudflare en 2019.
• Prueba rápida de cadenas en el panel de prueba al final de la página, antes de comprometer el patrón al código.

Errores comunes

• Olvidar las anclas. Sin ^ y $ (o \A y \z en PCRE), una regex de validación coincide si el patrón aparece en cualquier lugar de la cadena. /\d{4}/ coincide con «year 2026 was good», lo cual casi nunca es lo que se quiere.
• Confiar en .* a través de varias cosas. <a href=".*"> sobre la entrada <a href="a"><a href="b"> captura a través de ambas etiquetas porque .* es codicioso. Use .*? para perezoso, o mejor, parsee con un parser real.
• Suponer que el punto coincide con saltos de línea. Por defecto . coincide con todo excepto terminadores de línea. Use el flag s (dotAll) en JS, o re.DOTALL en Python, o el modificador inline (?s) en PCRE.
• Suponer que \w incluye letras no ASCII. En modo ASCII, \w es [a-zA-Z0-9_]. Añada el flag u en JS (ES2018+) y use \p{L} para cualquier letra Unicode; en Python añada re.UNICODE (por defecto en Python 3).
• Retrorreferencias en Go. El regexp de Go es RE2 y rechaza \1 en tiempo de compilación. El error «error parsing regexp: invalid escape sequence: \1» significa que el patrón necesita dividirse en un enfoque no regex.
• Parsear HTML con regex. Notoriamente inviable: HTML no es un lenguaje regular. Use un parser DOM (el DOMParser integrado del navegador, cheerio, BeautifulSoup, lxml).

Más preguntas frecuentes

¿Por qué algunos patrones usan (?:...) en lugar de (...)?

(?:...) es un grupo no capturante: agrupa para repetición o alternancia pero no asigna un slot de retrorreferencia. Es más rápido y evita contaminar $1, $2 en el array de resultados. Use (...) cuando necesite extraer el texto capturado; use (?:...) solo para agrupar.

¿Cuáles son los flags regex más comunes?

i insensible a mayúsculas, g global (encontrar todo, comportamiento específico JS), m multilínea (para que ^ y $ coincidan con límites de línea), s dotAll (para que . coincida con saltos de línea, ES2018+), u Unicode (ES2015+), y sticky (ES2015+), d hasIndices (ES2022+), v clases de notación de conjunto (ES2024+). Combine como /pattern/gimsu.

¿Cómo coincido con un carácter especial literal?

Escápelo con una barra invertida. Los metacaracteres regex que necesitan escape para coincidencia literal son: . ^ $ * + ? ( ) [ ] { } | \ /. Dentro de una clase de caracteres [...] el conjunto de caracteres especiales es más pequeño: solo ] \ ^ - necesitan escape, según la posición.

¿Puedo usar los patrones de esta biblioteca en scripts shell?

Sí, con reservas. grep usa POSIX BRE por defecto; grep -E usa ERE; grep -P usa PCRE en sistemas donde libpcre está enlazada (GNU grep, macOS grep con Homebrew). Los patrones que usan lookaround, grupos nombrados o escapes Unicode requieren grep -P o ripgrep (que usa el motor RE2-based de Rust y rechaza lookaround).

¿Estos patrones se envían a un servidor?

No. Cada regex de esta página, cada búsqueda que escribe y cada cadena que prueba en el panel de prueba rápida se procesa en el motor JavaScript de su navegador. No se realiza ninguna llamada de red. Los datos de patrón en sí se entregan como un archivo JSON estático en el bundle de la página. Abra la pestaña Red en DevTools para verificar.