Ferramenta de Teste Regex

A ferramenta Regex ajuda a escrever, testar e entender expressões regulares. Uma expressão regular descreve padrões de texto para busca, extração, validação e substituição, como strings parecidas com e-mail, campos de log, URLs, IDs, datas ou formatações repetidas. Um testador torna visíveis correspondências, grupos de captura, flags e casos de borda antes de usar o padrão em código, pipeline de dados ou validação de formulário. Regex é poderoso, mas fácil de superestimar: um padrão pode casar demais ou de menos, ficar lento com entradas grandes ou lidar mal com Unicode e regras locais. Para parsers complexos, HTML ou validação crítica, uma biblioteca dedicada costuma ser mais segura.

O testador é conduzido pelo mecanismo ECMAScript RegExp definido na especificação da linguagem. Regex em ECMAScript é uma implementação NFA com backtracking: o motor tenta cada alternativa da esquerda para a direita e retrocede sempre que um quantificador falha, o que torna lookarounds e backreferences possíveis, mas também o que produz backtracking catastrófico em entradas adversariais. As seis flags reconhecidas são g (global), i (insensível a maiúsculas/minúsculas), m (multilinha, âncoras por linha), s (dotAll, '.' casa com nova linha), u (modo Unicode) e y (sticky, âncora em lastIndex).

A semântica de correspondência muda drasticamente entre flags. Com /u, o motor trata o padrão como uma sequência de code points Unicode em vez de code units UTF-16, então pares de substituição casam como um caractere e classes de propriedade Unicode como \p{L} (qualquer letra), \p{Sc} (símbolo de moeda) e \p{Script=Han} se tornam disponíveis. Grupos de captura nomeados (?<name>...) e lookbehind (?<=...) fazem parte do ES2018 e estão presentes no Chromium 64+, Firefox 78+ e Safari 16.4+, mas funcionalidades exclusivas de PCRE como grupos atômicos (?>...) e quantificadores possessivos (a++) ainda não estão na especificação.

O maior risco em produção é o ReDoS — um padrão como (a+)+b na entrada 'aaaaaaaaaaaaaaaa!' explora um número exponencial de caminhos porque dois quantificadores aninhados podem dividir a mesma sequência de caracteres de muitas maneiras. As mitigações são bem conhecidas: evite quantificadores aninhados sobre a mesma classe de caracteres, use âncoras ^ e $ sempre que possível, prefira grupos atômicos quando o motor os suporta, ou mude para um motor de tempo linear como o RE2 do Go (que troca backreferences e lookbehind por correspondência O(n) garantida). Para entrada não confiável destinada a validação no lado do servidor, RE2 ou um parser escrito à mão quase sempre é a opção mais segura.

• Motor: ECMAScript RegExp é um NFA com backtracking, não um DFA; é isso que permite lookarounds e backreferences, mas também permite backtracking catastrófico.
• Flags: g (global), i (insensível a maiúsculas/minúsculas), m (^/$ por linha), s (dotAll, '.' casa com \n), u (modo Unicode, consciente de surrogates), y (sticky, âncora em lastIndex).
• Modo Unicode: /u desbloqueia correspondência por code point além de \p{L} (letra), \p{Sc} (moeda), \p{Script=Han}; sem /u, [a-zA-Z]+ perde toda palavra não latina.
• Disponibilidade de sintaxe moderna: capturas nomeadas (?<n>...) e lookbehind (?<=...) presentes no Chromium 64+, Firefox 78+, Safari 16.4+; grupos atômicos (?>...) e quantificadores possessivos (a++) não estão no ECMAScript.
• ReDoS: quantificadores aninhados sobre a mesma classe como (a+)+b explodem exponencialmente; aperte com âncoras, grupos atômicos ou migre para RE2 / re2-wasm para entrada não confiável.
• Piso de complexidade: padrões literais com âncoras sobre um alfabeto fixo rodam em O(n); backreferences e lookarounds ilimitados levam o pior caso para exponencial, então faça benchmark com entrada adversarial antes de publicar.