Codificar e descodificar URL

Codificar e descodificar URL aplica percent-encoding RFC 3986 a texto e inverte sequências %HH de volta para caracteres. O modo componente codifica caracteres reservados como /, ? e & para poderem ficar em segurança dentro de um único parâmetro de consulta. O modo URI completo preserva delimitadores estruturais para um endereço completo permanecer um link utilizável. O tratamento de espaços oferece tanto %20 como o sinal de mais de codificação de formulário.

Toda a codificação e descodificação corre no seu navegador. Nada do que cola é enviado para um servidor.

Codificar texto para uso seguro num URL

Percent-encoding substitui bytes inseguros ou reservados por um sinal de percentagem seguido de dois dígitos hexadecimais. Os dígitos são o valor do byte, normalmente de UTF-8. Introduza uma cadeia, escolha modo componente ou URI completo, e copie o resultado codificado para uma cadeia de consulta, segmento de caminho ou alvo de redireccionamento.

Caracteres já no conjunto não reservado passam inalterados. Todo o resto torna-se sequências %HH no modo componente. Codificar é reversível quando as mesmas regras são usadas na descodificação; misturar sinais de mais de codificação de formulário com %20 de estilo caminho é a fonte habitual de idas e voltas quebradas.

Descodificar uma cadeia percent-encoded

Descodificar encontra cada % seguido de dois dígitos hex, converte esse par num byte, e reconstrói o texto original com a codificação de caracteres seleccionada. Um % solitário ou um % com dígitos não hex é um erro. Sinais de mais podem opcionalmente ser tratados como espaços quando a entrada veio de corpos application/x-www-form-urlencoded.

Codificação aninhada aparece quando um valor foi codificado duas vezes. Descodificar uma vez pode ainda deixar sequências %25 que representam um percentagem literal. Descodifique outra vez apenas quando essa segunda camada foi intencional; descodificação dupla cega corrompe dados que continham um carácter % real.

Compreender caracteres reservados e não reservados

A RFC 3986 divide ASCII em caracteres não reservados que nunca precisam de codificação num URI, e caracteres reservados que transportam significado estrutural como delimitadores. Letras, dígitos e -_.~ não reservados ficam literais. Marcas reservadas como /, ? e & devem ser percent-encoded quando aparecem como dados em vez de sintaxe que enquadra o URL.

Não reservados: A a Z, a a z, 0 a 9, hífen -, underscore _, ponto ., til ~

Reservados (gen-delims): `: / ?

Reservados (sub-delims): ! $ & ' ( ) * + , ; =

Caracteres não reservados ficam literais. Caracteres reservados devem ser codificados quando aparecem como dados em vez de delimitadores. Um ponto de interrogação dentro de um valor de parâmetro é dado; um ponto de interrogação que inicia a cadeia de consulta é estrutura. A selecção de modo é como a calculadora sabe que papel cada carácter desempenha.

Codificar um URL completo versus um único parâmetro

Codificação URI completa, semelhante a encodeURI em JavaScript, deixa caracteres estruturais intactos para https:// e barras de caminho sobreviverem. Codificação de componente, semelhante a encodeURIComponent, codifica esses caracteres para um valor poder ficar dentro de um parâmetro sem partir o URL envolvente. Escolher o modo errado ou destrói um link ou deixa delimitadores que partem a consulta incorrectamente.

Entrada	Estilo URI completo	Estilo componente
https://example.com/a b	https://example.com/a%20b	https%3A%2F%2Fexample.com%2Fa%20b
red&blue	red&blue	red%26blue
a=b	a=b	a%3Db

Codificar um URL inteiro com modo componente destrói-o como link: os dois pontos do esquema e as barras tornam-se %3A e %2F. Codificar um único parâmetro com modo URI completo deixa & e = intactos, o que parte a consulta incorrectamente. Escolha o modo que corresponde ao slot que a cadeia vai ocupar.

Codificar uma barra e um ponto de interrogação

A cadeia fixa / and ? em modo componente torna-se %2F%20and%20%3F. A barra e o ponto de interrogação são delimitadores reservados tratados aqui como texto de payload, por isso cada um é escapado. Espaços tornam-se %20, enquanto as letras em and são não reservadas e passam inalteradas da esquerda para a direita ao longo da cadeia.

Carácter	Razão	Codificado
/	delimitador de caminho reservado	%2F
espaço	não reservado	%20
a, n, d	letras não reservadas	inalteradas
?	delimitador de consulta reservado	%3F

Percorra a cadeia da esquerda para a direita: codifique /, codifique o espaço, passe and, codifique o espaço, codifique ?. O resultado %2F%20and%20%3F é seguro para colocar num parâmetro de consulta chamado, por exemplo, q. Usar modo URI completo na mesma cadeia deixaria / e ? literais, o que só está correcto quando esses caracteres são estrutura em vez de texto de payload.

Compreender %20 versus o sinal de mais

Um espaço codifica como %20 em caminhos URI e em cadeias de consulta modernas que seguem RFC 3986. Formulários HTML que submetem como application/x-www-form-urlencoded codificam historicamente espaços como + em vez disso. Ambas as convenções aparecem em tráfego de produção, e tratá-las como idênticas é o bug de codificação de espaços mais comum ao descodificar entradas mistas.

Contexto	Codificação de espaço
Segmento de caminho	%20
Consulta RFC 3986	%20
Corpo de formulário / consulta legada	+

Um sinal de mais literal em dados deve ser codificado como %2B, ou um descodificador de formulário tratará-o como espaço. A calculadora indica que convenção de espaço está activa para um + descodificado não ser confundido com um carácter de mais quando o modo formulário está ligado, e um %20 não ser rejeitado quando o modo caminho está ligado.

Decompor um URL nas suas partes

Um URL típico tem esquema, anfitrião, porta opcional, caminho, cadeia de consulta e fragmento, e regras de codificação diferem por parte. Delimitadores estruturais como ://, /, ?, &, = e # ficam literais quando enquadram o endereço.

Nomes de parâmetros, valores de parâmetros e segmentos de caminho que transportam dados são codificados individualmente em modo componente antes desses delimitadores os juntarem.

https://example.com:443/search?q=a%20b&lang=en#top
└─┬─┘   └─────┬─────┘ └─┬──┘ └───────┬───────┘ └┬┘
esquema      anfitrião  caminho     consulta   fragmento

Parte	Papel
Esquema	Protocolo, como https
Anfitrião	Domínio ou IP, com porta opcional
Caminho	Localização do recurso, separada por barras
Consulta	Lista de parâmetros após ?, unida por &
Fragmento	Localização no cliente após #, não enviada ao servidor no URI de pedido da mesma forma

Codifique nomes e valores de parâmetros individualmente em modo componente, depois una com & e = literais. Codifique segmentos de caminho individualmente se contiverem espaços ou caracteres reservados, mantendo as barras que separam segmentos literais.

Ler a tabela de codificação de caracteres

A tabela abaixo lista caracteres reservados e inseguros comuns com as suas formas percent sob codificação de bytes UTF-8. Um espaço torna-se %20, um e comercial %26, e um cardinal %23. Caracteres não ASCII expandem para múltiplas unidades %HH porque cada byte UTF-8 é codificado separadamente em vez de como um glifo abstracto único.

Carácter	Percent	Notas
espaço	%20	Ou + em codificação de formulário
!	%21
#	%23	Delimitador de fragmento
$	%24
&	%26	Delimitador de par de consulta
'	%27
(	%28
)	%29
+	%2B	Sinal de mais literal
,	%2C
/	%2F	Delimitador de caminho
:	%3A	Separador esquema / anfitrião
;	%3B
=	%3D	Atribuição de parâmetro
?	%3F	Início de consulta
@	%40	Separador userinfo
[	%5B
]	%5D

Texto não ASCII é primeiro expresso como bytes UTF-8, depois cada byte é percent-encoded. Um carácter visível pode portanto expandir para duas ou três unidades %HH. Aprofundamentos de codificação de caracteres para Shift JIS e conjuntos legados semelhantes vivem com a ferramenta Base64; esta página liga em vez de repetir esse catálogo.

Perguntas frequentes

Resumo

Codificar e descodificar URL percent-encodifica e descodifica texto sob regras RFC 3986, com modos separados para URIs completos e componentes individuais. O exemplo fixo / and ? torna-se %2F%20and%20%3F em modo componente. Espaços usam %20 em contextos URI e podem usar + em codificação de formulário, que é uma convenção diferente.

Caracteres reservados mantêm o seu significado apenas quando ficam literais como estrutura; codifique-os quando são payload. Todo o trabalho fica no dispositivo.