Ferramentas de desenvolvedor · Codificador e decodificador URL
Codificação dupla URL: como %2520 acontece e como detectá-la e desfazê-la
· Como funciona
codificação de URL javascript fluxo de trabalho do desenvolvedor depuração
Um %2520 em URL significa que um espaço foi codificado duas vezes. Esta postagem explica os erros de pipeline que causam isso, como reconhecer a assinatura e quantas passagens de decodificação são seguras.
Codificação dupla URL: quando %2520 significa que um espaço passou por dois codificadores
Um nome de arquivo chegando como "my%20file.pdf" em vez de "my file.pdf" sinaliza codificação dupla: um espaço foi codificado para %20, então o próprio sinal de porcentagem foi codificado para %25, produzindo %2520 no URL final. Cada camada de um sistema, como código do cliente, estrutura da web ou proxy reverso, pode codificar uma vez. Quando duas camadas separadas são codificadas, um único caractere fica mutilado.
A codificação dupla surge com mais frequência em cadeias de redirecionamento complexas e sistemas de modelos. Um desenvolvedor pode gerar um URL codificado dentro de uma estrutura que codifica toda a saída por padrão. Um proxy reverso ou rede de entrega de conteúdo pode recodificar URLs que já chegaram codificados do sistema back-end. Um parâmetro contendo um valor já codificado é codificado novamente antes de ser aninhado dentro de outra estrutura URL.
Por que %25 é o indicador - o próprio sinal de porcentagem é codificado, então %20 se torna %2520 e %C3%A9 se torna %25C3%25A9
O sinal revelador de codificação dupla é %25 aparecendo onde você normalmente esperaria ver um único sinal de porcentagem no URL ou nos dados. Em um URL normalmente codificado, você nunca verá %25 a menos que envie literal "%25". Se um espaço codificado como %20 for codificado novamente, ele se tornará %2520.
Um caractere acentuado como é, que codifica normalmente para %C3%A9, torna-se %25C3%25A9 quando codificado duas vezes por dois sistemas diferentes em sequência. Aprender a identificar o padrão %25 em barras, logs e mensagens de erro URL economiza inúmeras horas de trabalho frustrante de depuração em ambientes de produção onde os dados fluem por vários serviços.
Onde a codificação dupla é introduzida – código do cliente mais estrutura, redirecionamentos, proxies e auxiliares de modelo
A codificação dupla destrói a legibilidade e a capacidade dos sistemas do lado do servidor analisarem URL corretamente. Um arquivo chamado "my file.pdf" torna-se "my%20file.pdf" quando codificado corretamente. Se a string codificada for recodificada - talvez por um formulário - ela se tornará "my%2520file.pdf".
Quando o servidor recebe isso e o decodifica uma vez, ele vê "my%20file.pdf" como um nome de arquivo literal em vez de reconhecê-lo como "my file.pdf". Quaisquer aplicativos que esperam receber apenas uma única passagem de decodificação receberão um resultado distorcido. Pior ainda, um desenvolvedor que decodifica duas vezes para corrigir problemas em valores que foram codificados apenas uma vez irá, na verdade, corromper os dados legítimos com a passagem de decodificação extra.
Exemplo resolvido: decodificando um URL duplamente codificado, uma passagem de cada vez - o que cada passagem revela e quando parar
O código JavaScript do lado do cliente e os padrões da estrutura do lado do servidor são as fontes mais comuns de codificação dupla acidental em sistemas de produção. Um aplicativo JavaScript pode usar encodeURIComponent em um valor e depois passá-lo diretamente para uma estrutura que codifica toda a saída de string por padrão, codificando assim o sinal de porcentagem uma segunda vez. Uma camada de proxy reverso destinada a higienizar URLs pode recodificar parâmetros que já vieram pré-codificados do aplicativo de back-end.
Um redirecionamento URL construído concatenando a entrada fornecida pelo usuário com uma função auxiliar de estrutura pode codificar em ambas as etapas simultaneamente. Exemplo resolvido: um usuário envia "teste e valor" por meio do formulário HTML, o navegador o codifica como "teste%26valor". A estrutura vê o texto percentual literal e o codifica, produzindo "test%2526value". Uma decodificação fornece "test%26value", ainda errado.
Quando a codificação dupla é deliberada - um URL transportado dentro do parâmetro de consulta de outro URL
A codificação dupla deliberadamente é válida em um caso específico: quando um URL deve viajar dentro do parâmetro de consulta de outro URL. Os fluxos OAuth e os links de retorno de login às vezes exigem o aninhamento de um URL completo dentro de outro. O URL interno deve ser totalmente codificado por porcentagem primeiro e, em seguida, toda a string codificada deve ser codificada novamente como um valor de parâmetro para o URL externo.
Esta dupla codificação é deliberada e absolutamente necessária nestes casos. O analisador de parâmetro externo é decodificado uma vez, produzindo o URL interno ainda codificado. O sistema interno então decodifica novamente, recuperando o URL original. A chave crítica é compreender a intenção e documentá-la claramente em comentários de código para futuros mantenedores.
Erros comuns — decodificação até que nada mude, o que corrompe valores que contêm legitimamente %25
O erro clássico e perigoso é decodificar repetidamente até que nada mude, o que corromperá valores que contêm legitimamente sinais de porcentagem nos dados reais. Um parâmetro como "discount%2525" (representando um literal "%25" codificado como um valor de parâmetro e depois codificado novamente para transporte) é completamente correto por design. Decodificá-lo uma vez produz "desconto%25", o que ainda está correto. Decodificá-lo uma segunda vez resulta em "% de desconto", o que está errado e perde informações.
Um desenvolvedor pode assumir que "%25" é um erro e decodificar repetidamente, perdendo o sinal de porcentagem. Em vez disso, decodifique exatamente quantas vezes sua arquitetura exigir: uma vez para um parâmetro, duas vezes aninhado. Conte camadas para saber as operações de decodificação corretas.
O que isso não cobre - codificação de entidade HTML em camadas sobre URLs, que o escaper de entidade HTML manipula
Erros comuns incluem codificar um URL inteiro com encodeURIComponent e esperar que barras e dois pontos funcionem como delimitadores estruturais, o que não podem ocorrer após a codificação. Outro erro frequente é misturar diferentes padrões de codificação: alguns códigos usam codificação percentual por RFC 3986 e outros códigos usam codificação de formulário com sinais de mais representando espaços. Um valor como "meu+arquivo" torna-se genuinamente ambíguo - pode significar "meu arquivo" ou pode significar o texto literal "meu+arquivo" com um sinal de mais.
Se a codificação percentual tocar primeiro em "meu+arquivo", ela se tornará "meu%2Barquivo". Se a decodificação do formulário ocorrer, esperando mais como espaço, ela permanecerá errada. A consistência entre as camadas é essencial. Cada sistema deve usar o mesmo padrão de codificação ou cada camada deve ser explicitamente documentada.
Conclusão: codifique exatamente uma vez por camada - como o codificador e decodificador URL permite decodificar uma passagem por vez e ver cada resultado intermediário
Depois de identificar com êxito a codificação dupla que ocorre nos sistemas de produção, a correção depende inteiramente de onde a duplicação está ocorrendo no pipeline. Se o código do cliente e uma estrutura estiverem codificando, remova completamente a codificação de um deles. Se um parâmetro passar por vários serviços de back-end, rastreie o caminho completo em cada serviço e descubra qual serviço está codificando quando não deveria.
Teste a correção minuciosamente passando dados de amostra por todo o pipeline de ponta a ponta e verifique se os dados chegam completamente inalterados ao destino. Documente claramente a suposição de codificação em cada limite: "este endpoint retorna parâmetros codificados por porcentagem" ou "este middleware espera UTF-8 bruto e aplica codificação a ele". Inclua o número de passagens de decodificação esperadas nessa documentação para futuros desenvolvedores.