Armadilhas de dialectos ECMAScript vs PCRE

Porque as armadilhas de dialeto aparecem em aplicações reais

A maioria das equipas aprende uma variedade 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 inverso também acontece: um padrão Unicode u-flag JavaScript se comporta de forma 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 for ECMAScript RegExp, a fonte de verdade é a seção RegExp do ECMA-262. Se o tempo de execução for 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 discordância geralmente entra

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

Diferenças entre lookbehind e lookaround

O lookbehind de comprimento variável é uma armadilha clássica. Os motores de expressão regular discordam sobre quais comprimentos são legais, e alguns motores de JavaScript mais antigos não tinham lookbehind por completo. Mesmo quando ambos os lados suportam lookbehind, o conjunto de padrões permitidos dentro da afirmação pode ser diferente. Se o seu gate depende de "o token anterior deve ser X", escreva um teste unitário no motor de produção, e não em um playground de PCRE.

O 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 a ser a lista de verificações 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 um 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 motor. Um padrão escrito com a flag u do JavaScript não é o mesmo objeto que um padrão PCRE com o modo UTF ativado sob opções diferentes. O comportamento de ponto-tudo / linha única também difere em nomeação e padrões entre sabores.

Quando revejo 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.

Lista de verificação — Unicode

- Registar as flags exatas usadas na produção (i, m, s/dotAll, u, v quando disponível) - Incluir pelo menos um fixture do plano astral se o texto do usuário pode conter emoji - Evitar assumir que \w significa “letras em todos os idiomas” - Preferir intervalos explícitos ou escapes de propriedades que tenham sido verificados no motor

Recursividade, referências retroativas e funcionalidades "úteis" do PCRE

Padrões recursivos e algumas chamadas de sub-rotinas 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 recursividade falharão quando o consumidor é o JavaScript. Grupos atômicos e quantificadores possessivos são outro conforto do lado do PCRE que o JavaScript falta na mesma forma.

O comportamento de referências retroativas 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 execução; é uma aceitação ou rejeição silenciosa e errada em entradas de bordo.

Funcionalidade | RegExp do ECMAScript | PCRE (típico) | Regra de envio Olhar para trás de comprimento variável | Limitado / dependente da versão do motor | Suporte mais amplo | Testar no motor 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 | Combinações de bandeiras de correspondência explicitamente Grupos nomeados | Suportado em motores 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 é 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). - Verifique quantificadores aninhados e alternância sobreposta (passagem ReDoS). - Apenas então cole em um segundo mecanismo se você realmente precisar de tempo de execução duplo — espere edições.

RegexProof é construído 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 preparação.

Erros comuns

- Confiar num teste verde no regex101 com o sabor incorrecto seleccionado - Partilhar um padrão através de WAF (PCRE) e frontend (ECMAScript) sem fixtures duplos - Deixar que um LLM emita lookbehind ou recursividade sem especificar o motor - Tratar "compilou" como "corresponde ao que queremos dizer" - Ignorar a revisão de ReDoS porque o padrão é "apenas para validação"

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

Permaneça com um motor quando o padrão das portas de entrada de dados do utilizador se encontra num único nível. Divida os motores apenas quando tiver dois proprietários, dois ficheiros de configuração e um mapeamento documentado. O compartilhamento de motores duplos da "mesma string" é como as armadilhas de dialecto se tornam incidentes.

O que isto 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) deteta todos os bugs de dialecto, 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 casos limite. O também não é abordado aqui.

Como mapeio um bilhete para um contrato de motor

Cada bilhete 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 motor 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

- Motor + versão + flags - Cinco fixtures de aceitação e cinco fixtures de rejeição (strings cruas, não paráfrases) - 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

LLM-gerado regex: fixar o sabor no prompt

Se pedir a um modelo por "um regex para e-mails" sem nomear ECMAScript ou PCRE, muitas vezes se obtém uma resposta com sabor PCRE com lookbehind ou hábitos possessivos. 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.

Também proíbo a colagem cruzada de registos de chat para produção sem um segundo ser humano que possa explicar cada grupo. O modo de falha não são erros de sintaxe dramáticos — é aceitações silenciosas erradas em casos de bordo Unicode semanas mais tarde.

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

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

Quando um cliente relata uma rejeição falsa, peça os pontos de código exatos (um dump hexadecimal da string) antes de "corrigir" o padrão. Muitos bugs de dialeto são invisíveis em capturas de tela, incluindo problemas relacionados a RegexProof, ReDoS, ECMAScript, PCRE.

Encerramento

Fixe o dialeto, escreva fixtures nesse dialeto, então preocupe-se 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 cross-engine como uma tarefa de transferência com sua própria revisão.

Referências

- ECMA-262 RegExp - PCRE - OWASP ReDoS

Experimente o produto: RegexProof

2026-09-16 · apenas fontes primárias · nenhum tráfego métrico fabricado

Leituras relacionadas

- redos-heuristics-for-application-regex-2026 - A Matriz de Tópicos LX AI Micro-SaaS