BrowserTools
Início / Codificadores / Codificar / Descodificar URL

Codificar / Descodificar URL

Codifica ou descodifica URLs e parâmetros de consulta em percentagem, modos seguro por componente e URI completa.

A carregar Codificar / Descodificar URL… Se nada acontecer, ativa o JavaScript.

A codificação em percentagem, vulgarmente chamada codificação de URL, é o mecanismo definido no RFC 3986 para representar com segurança caracteres arbitrários dentro de um Identificador Uniforme de Recursos. O sistema de endereçamento da internet foi concebido em torno do ASCII, por isso qualquer caractere fora de um pequeno conjunto seguro (espaços, letras acentuadas, pontuação, emoji ou binário em bruto) tem de ser substituído por um sinal de percentagem seguido de dois dígitos hexadecimais que representam o valor de byte do caractere em UTF-8. O esquema faz parte da web desde que Tim Berners-Lee definiu os URL no CERN em 1990 e foi formalmente normalizado no RFC 1738, mais tarde substituído pelo RFC 3986 em 2005.

Exemplos

Entrada hello world & co=1
Saída hello%20world%20%26%20co%3D1

Codificação em percentagem (encodeURIComponent): o espaço torna-se %20.

Entrada hello world & co=1
Saída hello+world+%26+co%3D1

Codificação de formulário (application/x-www-form-urlencoded): o espaço torna-se +.

Perguntas frequentes

Os meus dados são enviados para um servidor?
Não. A codificação e a descodificação acontecem inteiramente no teu navegador usando as funções integradas do JavaScript encodeURIComponent, decodeURIComponent, encodeURI e decodeURI. A tua entrada nunca sai do teu dispositivo e não é feito nenhum pedido de rede.
Que caracteres são considerados 'seguros' e ficam sem codificação?
O RFC 3986 define os caracteres não reservados (A-Z, a-z, 0-9, hífen (-), sublinhado (_), ponto (.) e til (~)) como sempre seguros e nunca codificados. No modo URI completa, os caracteres estruturais reservados (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) também são preservados porque têm significado sintático num URL completo.
Qual é a diferença entre os dois modos?
O modo por componente (encodeURIComponent) foi concebido para codificar valores individuais de parâmetros de consulta ou segmentos de caminho. Escapa tudo exceto os caracteres não reservados, por isso um ampersand dentro de um valor torna-se %26 e não será confundido com um separador de parâmetros. O modo URI completa (encodeURI) foi concebido para URL completos: preserva os caracteres estruturais reservados para que o URL continue válido e analisável após a codificação.
Porque é que um espaço por vezes se torna + e por vezes %20?
Depende do contexto. O formato application/x-www-form-urlencoded, usado pelos formulários HTML, codifica os espaços como + por razões históricas. A codificação estrita em percentagem definida pelo RFC 3986 usa %20 para os espaços em todos os outros lugares, incluindo segmentos de caminho e cadeias de consulta modernas. Na dúvida, %20 é a escolha segura; o + só deve ser descodificado como espaço dentro do corpo de um formulário, não num caminho de URL.
Há caracteres que nunca possam aparecer num URL mesmo codificados?
Todos os bytes 0x00-0xFF podem ser representados num URL através de codificação em percentagem, por isso tecnicamente qualquer sequência de bytes é exprimível. No entanto, existem limites práticos: URL muito longos (mais de 2000 caracteres) podem ser rejeitados por navegadores, servidores ou proxies. Os nomes de domínio internacionalizados (IDN) usam Punycode em vez de codificação em percentagem para a parte do host de um URL.
Esta ferramenta trata corretamente Unicode e emoji?
Sim. A função encodeURIComponent do JavaScript converte os caracteres na sua sequência de bytes UTF-8 antes de codificar em percentagem cada byte, que é o comportamento correto segundo o RFC 3986. Por exemplo, o sinal do euro € (U+20AC) torna-se %E2%82%AC, os três bytes da sua codificação UTF-8. Os emoji e qualquer outro ponto de código Unicode são tratados da mesma forma.
Posso usar isto para descodificar um URL que foi codificado duas vezes?
Podes aplicar a descodificação várias vezes colando a saída de novo como entrada. A dupla codificação acontece quando uma cadeia já codificada é codificada de novo, transformando %20 em %2520 (o próprio % torna-se %25). Se vês sequências literais %25 num URL descodificado, o valor original estava duplamente codificado e precisas de o descodificar uma segunda vez.
A codificação de URL é o mesmo que a codificação de entidades HTML?
Não. São sistemas separados. A codificação de URL usa a codificação em percentagem (%20, %26, etc.) para tornar seguros os caracteres dentro dos URI. A codificação de entidades HTML usa referências nomeadas ou numéricas (&,  , etc.) para escapar caracteres que têm significado especial na marcação HTML. Por vezes confundem-se porque ambas convertem & para %26 num URL e para & em HTML, mas nunca devem ser misturadas.
Qual é a diferença entre um URI e um URL?
Um URI (Identificador Uniforme de Recursos) é o conceito mais amplo: uma cadeia que identifica um recurso por nome, localização ou ambos. Um URL (Localizador Uniforme de Recursos) é um tipo específico de URI que fornece o meio para localizar o recurso; inclui um esquema (https://), um host e um caminho. No desenvolvimento web do dia a dia os termos são usados indistintamente, mas tecnicamente todo o URL é um URI, ao passo que nem todo o URI é um URL.
Porque é que codificar uma cadeia já codificada produz uma saída ilegível?
Porque o sinal de percentagem (%) é ele próprio codificado como %25, codificar uma cadeia já codificada transforma cada sequência %XX em %25XX. Por exemplo, %20 torna-se %2520. Descodifica sempre primeiro se não tens a certeza de que a entrada já está codificada, em vez de a codificar outra vez. O modo de descodificação desta ferramenta restaura a cadeia original a partir de um único nível de codificação.

Sobre Codificar / Descodificar URL

A codificação de URL é incontornável sempre que constróis ou analisas endereços web por programação. Os valores de cadeia de consulta que contêm espaços, ampersands ou sinais de igual quebrariam a análise de parâmetros se ficassem sem codificação. Os envios de formulários usam por omissão application/x-www-form-urlencoded, que codifica tudo em percentagem e converte os espaços em +. Os clientes de API REST têm de codificar os segmentos de caminho que contêm barras ou pontos de interrogação para que o servidor não os interprete como caracteres estruturais. As cargas de webhooks, os URI de redirecionamento OAuth e os deeplinks dependem todos de uma codificação e descodificação cuidadosas para passar dados sem ambiguidade.

Esta ferramenta trata da codificação e descodificação em percentagem inteiramente no teu navegador. Oferece dois modos para corresponder às duas funções padrão do JavaScript. O modo por componente (equivalente a encodeURIComponent) destina-se a valores individuais (um termo de pesquisa, um nome de ficheiro, um parâmetro OAuth) e escapa tudo exceto os caracteres não reservados A-Z, a-z, 0-9, hífen, sublinhado, ponto e til. O modo URI completa (equivalente a encodeURI) preserva os caracteres estruturais de um URL completo (dois pontos, barra, ponto de interrogação, cardinal, ampersand, igual) e é útil quando queres normalizar um URL sem quebrar a sua estrutura. Como tudo corre localmente, nenhuma entrada é alguma vez enviada para um servidor.

Um erro comum é codificar um URL inteiro com encodeURIComponent: isto escapa os dois pontos e as barras, produzindo um endereço quebrado. Usa o modo por componente apenas em valores individuais antes de os montar num URL. Inversamente, esquecer de codificar valores que contêm & ou = dentro das cadeias de consulta leva a que os parâmetros sejam divididos ou fundidos em silêncio na extremidade recetora. Nota também que o caractere + significa um espaço apenas dentro dos corpos application/x-www-form-urlencoded; nos segmentos de caminho, um + literal deve ser codificado em percentagem como %2B.

Como a codificação em percentagem obteve o nome

A codificação em percentagem deve o nome ao literal sinal de percentagem (%) que usa como caractere de escape. Quando Tim Berners-Lee definiu a sintaxe de URL no CERN em 1990, precisava de uma forma de representar bytes arbitrários que fosse inequívoca em texto ASCII. Escolheu % porque era imprimível, raramente usado em identificadores e visualmente distinto, tornando as sequências codificadas fáceis de detetar num relance.

A especificação original de URL (RFC 1738, 1994) já exigia a codificação em percentagem para os caracteres inseguros, mas diferentes sistemas discordavam sobre que caracteres eram 'inseguros' e como tratar o Unicode. Foi preciso esperar até 2005, e até ao RFC 3986, para surgir um padrão definitivo, juntamente com um documento complementar (RFC 3987) que definia os IRI (Identificadores de Recursos Internacionalizados), que permitem caracteres Unicode diretamente na sintaxe.

Hoje, praticamente todas as linguagens de programação incluem uma função de codificação de URL na sua biblioteca padrão, mas persistem diferenças subtis: o urlencode() do PHP codifica os espaços como +, o urllib.parse.quote() do Python usa %20 e o encodeURIComponent() do JavaScript segue o RFC 3986. Esta diversidade é a razão pela qual as integrações de API entre linguagens por vezes têm dificuldades com desajustes de codificação: o mesmo caractere pode parecer completamente diferente consoante a biblioteca que o serializou.

Apoiar