Regex do Dreamweaver - Inigualável) na expressão regular

2

O problema

A questão que estou abordando é que desenvolvedores antigos de algum código estão trabalhando em variáveis set como $ _GET [name] ou algumas vezes como $ _GET ['name']. Tentando tornar o código uniforme, eu quero fazer todos eles como $ _GET ['name']

Tentativa de solução

Em um script personalizado do DreamWeaver, usei o seguinte.

dreamweaver.setUpFindReplace({
    searchString: "\$(_POST|_SESSION|_GET)\[([^\'][0-9a-zA-Z _]+?[^\'])\]",
    replaceString: "$$1['$2']",
    searchWhat: "document",
    searchSource: true,
    useRegularExpressions: true
});
dreamweaver.replaceAll();

Informações extras

Enquanto eu estou recebendo o erro executando-o de um script personalizado, eu não entendo quando executando o mesmo "searchString" e "replaceString" dentro do prompt de busca (CTRL + F).

O prompt de busca encontrará, felizmente, e substituirá as ocorrências onde ocorrer.

Antes de alguém potencialmente apontar o fato - sim, eu poderia simplesmente executar o prompt de busca e fazer isso, mas ainda tenho que executar o script personalizado para executar as outras 20 ou mais opções de localizar e substituir.

Você tem exemplos de resultados finais em algum lugar?

Claro que sim. Eu tenho o regex usado no Regex 101 - link

Finalmente ...

Alguém sabe como parar o problema entre parênteses sem correspondência? Estou tentando há algum tempo e não consigo encontrar uma solução, pois não há parênteses sem correspondência.

Solução

Obrigado a Bob por descobrir isso. O Dreamweaver usa regex JS (que eu não acreditava ser diferente do PHP, mas acontece que um é POSIX e um é perl-regex [ou algo assim ...]) e que os literais precisam escapar com \ não \ . / p>

Isso fez a função final, de trabalho;

dreamweaver.setUpFindReplace({
    searchString: "\$(_POST|_SESSION|_GET)\[([^\'][0-9a-zA-Z _]+?[^\'])\]",
    replaceString: "$$1['$2']",
    searchWhat: "document",
    searchSource: true,
    useRegularExpressions: true
});
dreamweaver.replaceAll();
    
por MrMarlow 31.03.2016 / 15:49

1 resposta

1

Seu escape está um pouco errado. Você parece estar usando JavaScript e a string literal "\$(_POST|_SESSION|_GET)\[([^\'][0-9a-zA-Z _]+?[^\'])\]" é avaliada como $(_POST|_SESSION|_GET)[([^'][0-9a-zA-Z _]+?[^'])] .

Em vez disso, você deve usar "\$(_POST|_SESSION|_GET)\[([^'][0-9a-zA-Z _]+?[^'])\]" , que avalia para \$(_POST|_SESSION|_GET)\[([^'][0-9a-zA-Z _]+?[^'])\] .

A razão aqui é porque você realmente tem dois níveis de análise, cada um com suas próprias regras de escape. Primeiro, você tem o literal de string JavaScript, que permite escapar coisas como \n para uma nova linha. No entanto, seqüências de escape não reconhecidas como "\[" são silenciosamente engolidas e produzem [ . O mecanismo de regex vê [ , indicando o início de uma classe de caracteres.

Você deseja que o mecanismo regex receba barras invertidas literais no padrão. Para fazer isso, primeiro você deve produzir uma cadeia JS contendo barras invertidas literais. O que significa que você deve escapar as próprias contrabarras na string literal, então "\" produz \ , por exemplo "\[" produz a string \[ . Dessa forma, o mecanismo de regex vê \[ , indicando um colchete de escape (literal).

A outra coisa é que aspas simples não precisam ter nenhum escape, já que elas não possuem nenhum significado especial em regex e as aspas simples dentro de uma string entre aspas duplas são tratadas como caracteres normais por JS.

Existe outra opção, mas não tenho certeza se o DreamWeaver a aceita. O JavaScript tem uma sintaxe especial do literal regex , para que você não precise criar uma string primeiro. Ao pular essa etapa extra de análise, você realmente evita a necessidade de escapar duas vezes. Um literal de regex JS tem o formato /pattern/options (barras devem ser escapadas, mas você não tem nenhum nesse padrão). Portanto, seu padrão pode ser expresso como /\$(_POST|_SESSION|_GET)\[([^'][0-9a-zA-Z _]+?[^'])\]/ . Mais uma vez, as aspas simples não precisam ter nenhum escape.

Se o DreamWeaver suportar a sintaxe literal do regex, essa é a opção preferida.

    
por 04.04.2016 / 12:07