Codificação de URL explicada: por que os espaços se tornam% 20

Você já viu isso em endereços da web: %20 onde deveria estar um espaço, ou %3D em vez de um sinal de igual. Isso é codificação de URL (também chamada de codificação percentual) e, embora pareça algo sem sentido, resolve um problema real que mantém a web funcionando. Aqui está o que está acontecendo.

Por que URLs precisam de codificação

Os URLs só podem conter com segurança um conjunto limitado de caracteres — letras, dígitos e alguns símbolos. Muitos caracteres têm significado especial (? inicia uma string de consulta, & separa parâmetros, / separa segmentos de caminho) ou não são permitidos (espaços). Se você colocar esses caracteres em um URL como estão, navegadores e servidores ficarão confusos. A codificação os substitui por uma representação segura.

Como funciona

A codificação percentual substitui um caractere inseguro por um % seguido por seu valor de byte hexadecimal de dois dígitos. Um espaço é o byte 32, que é 20 em hexadecimal — daí %20. Um sinal de igual se torna %3D, um e comercial %26 e assim por diante. Codifique ou decodifique qualquer string instantaneamente com nosso codificador de URL e decodificador de URL.

Um exemplo prático

Suponha que você queira um URL de pesquisa para "café e bar". O espaço e o E comercial devem ser codificados:

https://example.com/search?q=caf%C3%A9%20%26%20bar

Observe que "é" se tornou %C3%A9 — caracteres não-ASCII são codificados como seus bytes UTF-8, que podem ter mais de um par percentual. A referência de codificação percentual MDN cobre os detalhes.

Onde é importante

• Parâmetros de consulta: a entrada do usuário na pesquisa e nos formulários deve ser codificada para que caracteres especiais não quebrem o URL.
• APIs: passar valores em um URL requer codificação para permanecer válido.
• Links com rastreamento: URLs de campanha geralmente carregam valores codificados.

Armadilhas comuns

Dois grandes problemas: codificação dupla (codificar uma string já codificada, transformando %20 em %2520) e esquecer de codificar a entrada do usuário, o que pode quebrar links ou abrir falhas de segurança. Em caso de dúvida, decodifique um URL para verificar o que ele realmente contém.

Caracteres reservados versus não reservados

Nem todo caractere precisa de codificação. O padrão define caracteres não reservados — letras, dígitos e - _ . ~ — que são sempre seguros como estão. Caracteres reservados como / ? # & = têm um significado estrutural especial em uma URL, portanto devem ser codificados quando usados ​​como dados em vez de como separadores. Este é o ponto crucial do motivo pelo qual você codifica a entrada do usuário: um termo de pesquisa contendo "&" deve se tornar %26, ou o "&" seria mal interpretado como o início de um novo parâmetro.

Sinais de mais e confusão de espaço

Uma pegadinha clássica: na string de consulta de envios de formulários mais antigos, um espaço às vezes é codificado como + em vez de %20, porque é assim que os dados do formulário HTML (o formato application/x-www-form-urlencoded) funcionavam historicamente. No caminho de uma URL, um espaço é sempre %20 e um + literal significa um sinal de mais. Essa divisão é a razão pela qual o mesmo "espaço" pode aparecer de duas maneiras e por que a decodificação do contexto errado pode corromper os dados. Em caso de dúvida, decodifique e inspecione.

Codificação e segurança

A codificação adequada não envolve apenas links válidos — é um limite de segurança. Deixar de codificar (ou validar) a entrada do usuário que termina em uma URL pode permitir ataques de injeção e redirecionamentos quebrados. Frameworks geralmente fornecem funções de codificação integradas; use-os em vez de rolar manualmente e nunca confie na entrada bruta do usuário em um URL. A codificação correta mantém seus links válidos e seu aplicativo mais seguro.

Resultado

A codificação de URL troca caracteres inseguros por % mais seu valor de byte hexadecimal, para que os URLs permaneçam válidos, independentemente do que contenham. Os espaços tornam-se %20, os símbolos especiais recebem seus próprios códigos e os caracteres não-ASCII usam seus bytes UTF-8. Codifique a entrada do usuário, evite a codificação dupla e use uma ferramenta para verificar — e esses sinais enigmáticos de porcentagem deixarão de ser um mistério.