Depuração de regex com fixtures, flags e visualização de replace

A maioria dos bugs de regex não é erro de sintaxe — são suposições erradas sobre flags, quebras de linha ou o que “match” significa no seu engine. Um padrão que destaca uma string de demo costuma falhar em logs de produção, exportações CSV ou nomes internacionalizados.

Este guia é um fluxo repetível para quem já conhece \d e [a-z] básicos, mas precisa de matches confiáveis antes de enviar um refactor ou regra de validação.

Comece com fixtures, não com o padrão

Antes de ajustar parênteses, reúna linhas deve dar match e não deve dar match:

• Algumas linhas reais de log (redija segredos)
• Entrada vazia ou só com espaços
• Nomes ou slugs Unicode se o app é internacional
• Linhas que antes geraram falso positivo

Cole-as num Testador de regex e mantenha o conjunto aberto enquanto edita. Um highlight verde não é suíte de testes.

Confira as flags antes de aumentar a complexidade

Quando o padrão funciona numa linha mas não num arquivo, flags são o suspeito usual:

Sintoma	Flag para testar
Só o primeiro match destaca	g (global)
^ / $ ignoram início de linha	m (multiline)
. para em newlines	s (dotAll)
Surpresas de maiúsculas/minúsculas	i (ignore case)
Pares substitutos / \p{...}	u (Unicode)

Documente as flags que você envia ao lado do padrão em comentários ou runbooks — o você do futuro não vai lembrar por que /^ERROR/m era obrigatório.

Monte o padrão em camadas

1. Ancore um prefixo estável (^timestamp=) se souber que existe
2. Troque trechos variáveis por classes de caractere, não sanduíches gananciosos .*
3. Adicione grupos de captura só para campos que vai extrair ou substituir
4. Visualize a saída do replace em cada linha de fixture antes de rodar sed ou replace-all na IDE

Exemplo de intenção: transformar user_id=123 em userId: 123. Se $1 cair no grupo errado, corrija o agrupamento antes de tocar dados de produção.

Saiba quando regex é a ferramenta errada

Regex serve para estrutura local em texto. Use um parser quando a entrada for:

• HTML ou XML aninhado
• Documentos JSON ou YAML completos
• Uma linguagem de programação

Para query strings de URL dentro de uma linha maior, considere normalizar com o Codificador de URL primeiro e depois fazer match na forma codificada que espera.

Checklist de revisão em cinco minutos

1. Todas as fixtures batem ou rejeitam como esperado
2. Flags registradas (gimsu ou subconjunto)
3. Preview de replace conferido em colagem multiline
4. Pior caso de tamanho de entrada testado (colagem grande de log)
5. Engine anotado se o padrão for copiado para Python, Java ou PCRE

Aprendizado relacionado

Para gramática campo a campo, grupos de captura e riscos de backtracking, veja o curso de Expressões regulares.

Em resumo

Trate regex como código: fixtures, flags, preview, depois ship. O conserto mais rápido costuma ser alternar g ou m — não adicionar outro quantificador aninhado.