Chuleta de expresiones regulares con buscador para el dialecto de JavaScript: clases de caracteres, conjuntos, cuantificadores, anclas, lookaround, grupos y banderas, cada uno con un ejemplo.
Cuarenta y un tokens de regex con ejemplos. Filtra a la vez por token, descripcion y ejemplo, y copia la sintaxis que necesites. Cubre el dialecto de JavaScript (ECMAScript) usado en navegadores y Node.js.
Ninguna entrada de sintaxis coincide con ese filtro.
Las expresiones regulares son densas por diseno. Un patron como ^(?:\d{1,3}\.){3}\d{1,3}$ comprime un validador completo de IPv4 en treinta caracteres, algo estupendo cuando lo escribiste tu y penoso cuando lees el de otra persona. La mayor parte de la dificultad no es conceptual: el vocabulario es amplio, escueto y muy facil de recordar a medias.
Esta pagina es una tabla de consulta para ese vocabulario, organizada tal como se construyen los patrones en la practica: que coincide con un solo caracter, como definir tus propios conjuntos, como decir "repite esto", donde anclar la coincidencia, como agrupar y alternar, y que banderas cambian el comportamiento del motor. El filtro busca a la vez en el token, la descripcion y el ejemplo, de modo que escribir "perezoso", "limite" o "lookbehind" te lleva directamente a la fila que recuerdas a medias.
Las expresiones regulares no son un unico lenguaje. Grep, PCRE, Python, Java, RE2 de Go y JavaScript comparten un nucleo comun pero discrepan en los bordes. Todo lo que aparece aqui apunta al dialecto de JavaScript definido por ECMAScript, porque es el que se ejecuta en el navegador, en Node.js y en la mayoria del utillaje de front-end.
Merece la pena senalar tres diferencias. Primera, el lookbehind — (?<=...) y (?<!...) — esta soportado en los motores modernos de JavaScript pero ausente en RE2 de Go y en versiones antiguas de Safari, asi que los patrones que dependen de el no son portables en todas partes. Segunda, JavaScript no tiene bandera x de modo extendido, de modo que no puedes repartir un patron en varias lineas con comentarios como permite Python; los patrones largos suelen ensamblarse a partir de fragmentos de cadena. Tercera, \d y \w son solo ASCII por defecto en JavaScript, asi que \w no coincide con letras acentuadas ni con caracteres CJK a menos que uses escapes de propiedad Unicode como \p{L} junto con la bandera u.
Dos habitos evitan casi todo el dolor con las expresiones regulares. El primero es anclar de forma deliberada. Un patron sin anclas busca una coincidencia en cualquier punto de la cadena, que es lo que quieres al escanear y casi nunca lo que quieres al validar. Anadir ^ y $ convierte "contiene algo que parece una fecha" en "es una fecha", y esa distincion esta detras de una proporcion sorprendente de fallos de validacion.
El segundo es preferir la pereza y las clases negadas frente a los comodines codiciosos. El error clasico es <.+> sobre texto tipo HTML: como + es codicioso, se traga todo hasta el ultimo > de la linea. Escribir <.+?> o, mejor, <[^>]+> coincide con una sola etiqueta. La version con clase negada es ademas bastante mas rapida, porque el motor nunca tiene que retroceder.
Por ultimo, ten presente el retroceso catastrofico. Anidar cuantificadores, como en (a+)+b, puede llevar al motor a explorar un numero exponencial de formas de partir la entrada antes de concluir que no hay coincidencia, lo que convierte una llamada de validacion en un vector de denegacion de servicio cuando el patron toca datos del usuario. Si un patron contiene un grupo cuantificado que a su vez contiene un cuantificador, reescribelo: normalmente una sola clase de caracteres con un unico cuantificador hace el mismo trabajo en tiempo lineal. Y cuando un patron crece mas alla de una o dos lineas, la respuesta honesta suele ser que la herramienta adecuada es un parser de verdad y no una expresion regular.