Regex
Prueba expresiones regulares de JavaScript en el navegador en tiempo real. Resalta coincidencias, muestra grupos de captura, admite todos los flags.
Resultado resaltado
Detalles de coincidencias
Patrones comunes
📖 Dónde se suele tropezar
Evalúa un patrón en vivo con el motor de expresiones regulares de JavaScript, resaltando las coincidencias y listando los grupos de captura. Todo se ejecuta en el navegador. El dialecto aquí es el de JavaScript: un patrón que funcione aquí no funcionará necesariamente sin cambios en PHP, Python o Go, porque el significado de las clases de caracteres, la disponibilidad de lookbehind y el tratamiento de Unicode difieren según el lenguaje.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Con la bandera g, la segunda llamada da otro resultado | Un objeto de expresión regular con la bandera g guarda estado en lastIndex. Llama repetidamente a test() sobre el mismo objeto y reanuda desde la posición de la coincidencia anterior, de modo que la misma cadena alterna entre true y false. Esto se vuelve fatal cuando la expresión se define en el nivel superior del módulo y se reutiliza: el estado sobrevive entre peticiones y produce una validación que a veces pasa cuando no debería, y que nunca se reproduce. Una prueba que la llame una sola vez no lo detectará. |
No pongas g en una expresión que uses con test() o exec(). Se añade pensando en que coincida con todo, pero test() pregunta si hay al menos una, así que g sobra. Para recoger todas las coincidencias, usa str.matchAll(re), que sí exige g. Si un objeto compartido necesita de verdad g, pon re.lastIndex = 0 justo antes de cada uso. Y escribir el literal dentro de la función cada vez cuesta prácticamente nada: los motores cachean los literales de expresión regular, así que evitar el objeto compartido es más seguro y no penaliza. |
| El japonés y los emoji no coinciden como esperas | \w significa sólo letras ASCII, dígitos y guion bajo: nunca coincide con japonés. \b, el límite de palabra, falla por lo mismo dentro de texto japonés. Más grave aún son los pares suplentes: sin la bandera u, los emoji y ciertos ideogramas poco frecuentes cuentan como dos, de modo que . coincide con la mitad de uno y una clase como [𠮷] se convierte en un conjunto sin sentido que significa cualquiera de estos dos suplentes. Casi todos los casos de caracteres destrozados por un recuento de longitud o un truncado vienen de aquí. |
Añade siempre la bandera u. Sólo con eso los pares suplentes cuentan como un carácter y además se habilitan los escapes de propiedad Unicode \p{...}. Para el japonés eso significa \p{Script=Hiragana}, \p{Script=Katakana} y \p{Script=Han}: más exacto que un rango como [ぁ-んァ-ヶ一-龠], y con la intención legible. Para emoji, \p{Extended_Pictographic}, aunque los tonos de piel y los emoji de familia son secuencias de varios puntos de código, así que tratarlos como un carácter exige Intl.Segmenter: las expresiones regulares sólo llegan hasta cierto punto. Si tu objetivo es contar caracteres, usa Intl.Segmenter y no una expresión regular. |
| Una coincidencia voraz se traga mucho más de lo previsto | .* coincide con todo lo que pueda. Así que aplicar <.*> a <div>A</div><div>B</div> produce una sola coincidencia que va del primer < al último >. Como . no coincide con el salto de línea por defecto, se detiene al final de la línea, pero añade la bandera s y se traga el archivo entero. El comportamiento es correcto; el problema es que, cuando se aparta de lo que esperabas, aparece como pruebas que pasan y roturas con las entradas más largas de producción. |
Usa el perezoso .*? o, mejor, escríbelo como una clase negada del tipo [^>]*: esta última no retrocede nunca, así que es más rápida y expresa la intención con claridad. El consejo de fondo, no obstante, es no analizar HTML con expresiones regulares: un > dentro del valor de un atributo, los comentarios, el CDATA y las etiquetas anidadas con el mismo nombre lo romperán. Usa DOMParser en el navegador y un analizador de HTML de verdad en el servidor. Las expresiones regulares encajan con texto orientado a líneas, sin estructura y de formato conocido: una línea de registro, una línea de configuración, validar la forma de un identificador. Todo lo que tenga anidamiento queda fuera de su competencia. |
Los cuantificadores anidados son el hogar del ReDoS. Una expresión con una repetición dentro de otra repetición, como (a+)+$ o (\w+\s?)*$, tarda un tiempo exponencial con entradas que no coinciden: bastan treinta caracteres para dejar la CPU de un servidor al 100 por cien durante minutos. Irónicamente, donde más aparece es en la expresión regular de validación estricta de correo, y ha provocado caídas en grandes servicios más de una vez. Hay tres defensas: no escribir cuantificadores anidados, limitar la longitud de la entrada y usar un motor que no retroceda: el regexp estándar de Go, el crate regex de Rust o RE2. Ten presentes también las diferencias de dialecto: JavaScript no tiene \A ni \z, y se sustituyen por ^ y $ sin la bandera m. El lookbehind llegó en ES2018, pero Safari sólo lo admite desde 16.4, así que evítalo si debes dar soporte a entornos antiguos.
📖 Cómo usar
-
1
Introduce el patrónEscribe tu regex y alterna los flags.
-
2
Pega el texto de pruebaPega el texto objetivo y las coincidencias se resaltan en vivo.
-
3
Inspecciona grupos de capturaEl panel derecho muestra posición y grupos de captura.
❓ Preguntas frecuentes
¿Qué motor de regex usa?
¿Puedo usar clases de caracteres japonesas?
¿Qué rendimiento tiene?
¿Puedo convertir a otros lenguajes?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.