Armadilhas de dialectos ECMAScript vs PCRE

Por que as armadilhas de dialeto aparecem em aplicativos reais

A maioria das equipes aprende um sabor bem e cola padrões em pilhas. Um backend que usa recursos do estilo PCRE (subpadrões recursivos, certas formas de lookbehind, quantificadores possessivos) aceitará felizmente um padrão que o navegador não consegue sequer parsear. O contrário também acontece: um padrão Unicode com a flag u do JavaScript se comporta de maneira diferente quando alguém o porta para uma compilação PCRE orientada a bytes sem as mesmas propriedades Unicode.

Trato o dialeto como parte do contrato, da mesma forma que trato o dialeto SQL. Se o tempo de execução é RegExp ECMAScript, a fonte de verdade é a seção RegExp do ECMA-262. Se o tempo de execução é PCRE, a fonte de verdade é a documentação do PCRE. Testadores que mudam silenciosamente os motores escondem o bug até a produção.

Onde a incompatibilidade geralmente entra

- Snippets de biblioteca de “validação” compartilhados copiados do Stack Overflow sem uma tag de motor - CI que executa re do Python enquanto o gateway de borda executa JavaScript - Analisadores de log ou parsers de WAF que usam PCRE enquanto o formulário do aplicativo usa ECMAScript - Regex gerado por LLM que usa a sintaxe PCRE-ish por padrão, a menos que você fixe o sabor

Diferenças de lookbehind e lookaround

Lookbehind de comprimento variável é uma armadilha clássica. Os mecanismos de regex discordam sobre quais comprimentos são legais, e alguns mecanismos de regex mais antigos em JavaScript não tinham lookbehind. Mesmo quando ambos os lados suportam lookbehind, o conjunto de padrões permitidos dentro da asserção pode ser diferente. Se sua lógica depende de "token anterior deve ser X", escreva um teste unitário no mecanismo de produção, não em um playground de PCRE.

Lookahead é mais amplamente compartilhado, mas combinar lookaround com quantificadores aninhados aumenta o risco de ReDoS. A segurança do dialeto e a segurança contra negação de serviço são verificações separadas; passe em uma e você ainda pode falhar na outra. As notas de ReDoS da OWASP continuam sendo a lista de verificação prática para a segunda verificação (OWASP ReDoS).

Regra prática

Se um recurso não está no RegExp ECMA-262, não o envie para o navegador. Se você precisar de recursos apenas do PCRE, mantenha esse padrão no lado do PCRE e retorne um booleano ou token normalizado para o JavaScript, em vez de enviar o padrão bruto.

Modos Unicode e classes de caracteres

Escapes de propriedades Unicode, caracteres do plano astral e dobramento de caso dependem de flags e tabelas Unicode do mecanismo. Um padrão escrito com a flag u do JavaScript não é o mesmo objeto que um padrão PCRE com o modo UTF habilitado em opções diferentes. O comportamento de ponto-tudo / linha única também difere em nomeação e padrões entre sabores.

Quando reviso padrões gerados, faço três perguntas: quais pontos de código devem corresponder, quais não devem e se o padrão assume texto apenas do BMP. E-mail, emoji e entrada CJK são onde aparecem correspondências silenciosas.

Checklist — Unicode

- Registre as flags exatas usadas em produção (i, m, s/dotAll, u, v quando disponível) - Inclua pelo menos um fixture do plano astral se o texto do usuário pode conter emoji - Evite assumir que \w significa “letras em todos os idiomas” - Prefira intervalos explícitos ou escapes de propriedades que você verificou no mecanismo

Recursão, referências retroativas e recursos "úteis" do PCRE

Padrões recursivos e algumas chamadas de sub-rotina são pontos fortes do PCRE. O RegExp do ECMAScript não oferece a mesma caixa de ferramentas. Geradores que emitem padrões de delimitadores balanceados com recursão falharão quando o consumidor é o JavaScript. Grupos atômicos e quantificadores possessivos são outro conforto do lado do PCRE que o JavaScript não possui na mesma forma.

O comportamento de referência retroativa em torno de grupos com falha e combinações vazias também pode surpreender as pessoas que movem padrões entre motores. O modo de falha raramente é uma falha de crash; é uma aceitação ou rejeição silenciosa e errada em entradas de bordo.

Recursos | RegExp do ECMAScript | PCRE (típico) | Regra de envio Olhar para trás de comprimento variável | Limitado / dependente da versão do mecanismo | Suporte mais amplo | Testar no mecanismo de destino Subpadrões recursivos | Não disponível | Disponível | Manter apenas no lado do servidor Possessivo / atômico | Não é a mesma caixa de ferramentas | Disponível | Não colar no JS Escapes de propriedade Unicode | Com u/v | Com UTF + opções | Sinalizar as correspondências explicitamente Grupos nomeados | Suportado em mecanismos modernos | Suportado | Verificar ainda a sintaxe de substituição

Fluxo de trabalho passo a passo que uso antes de enviar um padrão

- Escreva os exemplos de aceitação e rejeição primeiro (cinco de cada é o suficiente para começar). - Prenda o mecanismo e as flags no título do ticket (exemplo: "ECMAScript, flags u + i"). - Gere ou autor o padrão para esse mecanismo apenas. - Execute os fixtures no mesmo tempo de execução que o usuário atinge (compilação do navegador ou versão do Node que você implanta). - Escaneie quantificadores aninhados e alternância sobreposta (passagem ReDoS). - Somente então cole em um segundo mecanismo se você realmente precisar de tempo de execução duplo — espere edições.

RegexProof é projetado para manter a escolha de sabor explícita e explicar grupos antes de colar. Ele não substitui a execução de fixtures no seu binário de estágio. PCRE e ReDoS também são considerados nesse processo.

Erros comuns

- Confiar em um teste verde no regex101 com o sabor errado selecionado - Compartilhar um padrão entre WAF (PCRE) e frontend (ECMAScript) sem fixtures duplos - Deixar um LLM emitir lookbehind ou recursão sem especificar o mecanismo - Tratar “compilou” como “corresponde ao que queremos dizer” - Pulando a revisão de ReDoS porque o padrão é “apenas para validação”

Critérios de decisão: um motor ou dois

Permaneça em um motor quando o padrão controla a entrada do usuário em um único nível. Divida os motores apenas quando você tiver dois proprietários, dois arquivos de fixture e um mapeamento documentado. Dual-motor “compartilhe a mesma string” é como as armadilhas de dialeto se tornam incidentes.

O que isso não é

Este artigo não é uma comparação completa de todos os sabores de regex, não é uma garantia de que o RegexProof (ou qualquer ferramenta) captura todos os bugs de dialeto e não é uma afirmação de que passar nos testes significa que o padrão é seguro sob carga adversária. Nós não inventamos métricas de cliente. Use-o como uma lista de verificação de operador; mantenha os documentos ECMA-262 e PCRE abertos quando discutir sobre casos de bordo. O também não é abordado aqui.

Como mapeio um ticket para um contrato de engine

Cada ticket de regex deve nomear a runtime da mesma forma que nomeamos um banco de dados: "Node 20 ECMAScript RegExp, flags u+i" ou "gateway PCRE2 UTF, sem recursão." Sem essa linha, os revisores discutem sobre gosto em vez de contratos. Eu colo a linha do engine na descrição do PR e no cabeçalho do arquivo de fixture para que o CI e os humanos compartilhem uma história.

Quando o produto pede "a mesma regra no navegador e na borda", eu divido o trabalho em dois padrões com dois arquivos de fixture. Intenção compartilhada está bem; strings não verificadas compartilhadas não estão. O custo de manter dois padrões pequenos é menor do que o custo de um incidente de dialeto em um campo de login ou checkout.

Modelo para a descrição do PR

- Engine + versão + flags - Cinco fixtures de aceitação e cinco fixtures de rejeição (strings cruas, não parafrases) - Comprimento máximo de entrada aplicado antes de o matcher ser executado - Nota ReDoS: quantificadores aninhados revisados sim/não - Proprietário para risco residual se o padrão deve permanecer complexo

Observações: RegexProof, ReDoS, ECMAScript, PCRE devem ser preservados.

LLM-gerado regex: prender o sabor no prompt

Se você pedir a um modelo por "um regex para emails" sem nomear ECMAScript ou PCRE, você geralmente obtém uma resposta com sabor PCRE com lookbehind ou hábitos possessivos. O RegexProof força uma escolha de sabor por esse motivo. Ainda execute os fixtures no seu binário; uma explicação limpa não é um trabalho de CI verde.

Eu também proíbo a cópia cruzada de logs de chat para produção sem um segundo humano que possa explicar cada grupo. O modo de falha não é erros de sintaxe dramáticos — é aceitações silenciosas erradas em casos de borda Unicode semanas depois.

Notas do operador de formulários de micro-SaaS de envio

Formulários públicos atraem Unicode estranho, caracteres de largura zero e trabalhos de cola de suites de escritório. Armadilhas de dialeto aparecem como "funciona no meu laptop" porque o testador do laptop usou um mecanismo diferente do nó de borda. Mantenha um host de preparação que espelha as flags de regex de produção exatamente.

Quando um cliente relata uma rejeição falsa, peça os pontos de código exatos (um dump de hexa da string) antes de "corrigir" o padrão. Muitos bugs de dialeto são invisíveis em telas de captura.

Fechamento

Prenda o dialeto, escreva fixtures nesse dialeto, então se preocupe com a elegância. O bug caro é o padrão que funciona no tester errado. Mantenha o mecanismo de produção honesto e trate a cola de cross-engine como uma tarefa de porting com sua própria revisão. Note que conceitos como RegexProof, ReDoS, ECMAScript, PCRE devem ser preservados em sua forma original para garantir a compatibilidade e a precisão técnica.

Referências

- ECMA-262 RegExp - PCRE - OWASP ReDoS

Tente o produto: RegexProof

16-09-2026 · somente fontes primárias · nenhum métrica de tráfego fabricada

Preservado: ECMAScript, PCRE

Leituras relacionadas

- heurísticas-redos-para-aplicativos-regex-2026 - A Matriz de Tópicos LX AI Micro-SaaS