Codificador/Decodificador de URL
Codifica e decodifica URLs.
URL inválida
Tips
- O caractere japonês「あ」é codificado como
%E3%81%82em UTF-8. - Um espaço pode se tornar
%20em caminhos de URL ou+em parâmetros de consulta (diferença entre RFC 3986 e a especificação de formulários HTML). - Caracteres reservados como
?,&e=devem ser codificados quando usados como valores de parâmetros. - Útil ao incluir caracteres não ASCII em parâmetros de consulta de APIs REST ou ao passar URLs de redirecionamento com segurança.
Perguntas frequentes
%XX, seguro para uso em URLs. Decodificar reverte esse processo de volta ao texto original legível.%20 em caminhos de URL (conforme RFC 3986). Use + apenas em query strings application/x-www-form-urlencoded (dados de formulários HTML). Na dúvida, %20 é a escolha mais segura.- _ . ~ — podem aparecer em URLs sem codificação. Todos os demais, incluindo caracteres reservados como & e =, devem ser codificados quando usados como valores de parâmetros.
Curiosidade — O nascimento da URL: Tim Berners-Lee e o alvorecer da World Wide Web
A URL foi projetada em 1991 por Tim Berners-Lee, o inventor da World Wide Web. Originalmente concebida apenas para caracteres ASCII, caracteres multibyte (como o japonês) e caracteres especiais precisam ser representados por codificação percentual.
A URL da primeira página web da internet, http://info.cern.ch/hypertext/WWW/TheProject.html, ainda está acessível hoje. Domínios com emoji (ex.: 🍕.ws) são tecnicamente possíveis e são convertidos internamente para Punycode (formato que começa com xn--). Embora URLs possam teoricamente ultrapassar 2.000 caracteres, os limites práticos de navegadores e servidores ficam em torno de 2.048 caracteres.
O RFC 3986 define a especificação de URL, mas a distinção entre %20 (espaço) e + (espaço) ainda é fonte de confusão frequente. %20 é o padrão URI; + é usado no formato application/x-www-form-urlencoded de formulários HTML — a escolha depende do contexto.