Codificador / Decodificador de URL & parser de query string

encodeURIComponent() escapa quase tudo, então é o que você usa em um único pedaço de URL — um valor de query, um segmento de caminho. encodeURI() deixa em paz os caracteres reservados : / ? # & = + e até o #, então é o que você usa em uma URL já montada que só precisa se livrar dos espaços e dos caracteres não ASCII. Passe uma URL inteira para encodeURIComponent e ela vira um bloco opaco (https%3A%2F%2F…); passe um único valor para encodeURI e qualquer & dentro dele silenciosamente se torna um separador de parâmetros. O modo Encode aqui expõe os dois: o padrão é a regra de componente, e a caixa «Whole URL» é encodeURI() byte a byte.

Os dois estão certos, em lugares diferentes. A RFC 3986 só conhece %20. A convenção do + vem do envio de formulários HTML (application/x-www-form-urlencoded) e vale para corpos de formulário e, por hábito antigo, para query strings — por isso URLSearchParams decodifica + como espaço, mas o deixa intacto dentro de um caminho. Ou seja: %20 é sempre seguro, enquanto + só é espaço se quem produziu o valor decidiu assim. O modo Decode mostra qual convenção foi aplicada e deixa você inverter, para distinguir «Ada+Lovelace» o nome de «Ada Lovelace» as duas palavras.

A codificação percentual substitui um byte por um % seguido daquele byte escrito em dois dígitos hexadecimais. Uma URL só pode carregar um conjunto pequeno de caracteres ASCII, então todo o resto — um espaço, um acento, um emoji ou um caractere reservado usado como dado — primeiro é convertido em bytes UTF-8 e depois cada byte é escrito como %XX. é tem dois bytes, então vira %C3%A9. Decodificar faz o inverso: juntar os bytes e lê-los de volta como UTF-8.

Decodifique duas vezes. %2520 significa que o % de %20 também foi codificado, virando %25 — o que acontece quando um cliente chama encodeURIComponent() em um valor que já estava codificado: o clássico bug do redirect_uri do OAuth. Esta ferramenta detecta isso: cole o valor no modo Decode e ela avisa que a primeira passada ainda contém escapes, mostra o que uma segunda passada produz e oferece o botão «Decode again». O conserto de verdade é mais acima: codificar exatamente uma vez, no momento em que o valor entra na URL.

Porque os bytes escapados não são UTF-8 válido. %C3%A9 é uma sequência de dois bytes bem formada e decodifica para é, mas %E9 sozinho é o byte Latin-1 (ISO-8859-1) de é e não é UTF-8 legal, então decodifica para U+FFFD, o caractere de substituição. Esta ferramenta nomeia os bytes problemáticos em vez de lançar o URIError que decodeURIComponent() lançaria, o que diz a você que o valor foi codificado a partir da codificação de origem errada, em vez de deixar você no escuro.

Nada no padrão de URL diz qual vence, então aqui cada linha é listada e as posteriores são marcadas como duplicadas. Na prática, PHP e Express ficam com o último valor, r.URL.Query() do Go devolve todos, o ASP.NET junta com vírgulas, e o Rails só agrupa quando a chave termina em []. Essa discordância é justamente o motivo pelo qual uma ferramenta deve mostrar todos os valores em vez de escolher um em silêncio.

Punycode é a codificação ASCII de um nome de domínio internacionalizado. O DNS só carrega rótulos ASCII, então münchen.example é convertido para xn--mnchen-3ya.example antes de qualquer resolução — e essa forma ASCII também é a que um certificado TLS precisa casar. O parser aqui mostra o host convertido com o nome que você digitou logo abaixo, para você identificar um domínio sósia. Ele deliberadamente não converte punycode de volta para Unicode: exibir como Unicode bonitinho um nome fornecido por um atacante é exatamente como funciona o phishing homográfico.

O conjunto não reservado da RFC 3986 §2.3: A–Z, a–z, 0–9 e as quatro marcas - . _ ~. Eles são seguros em qualquer posição e nunca devem ser codificados sem motivo, porque %2D e - são a mesma URL e recodificá-los quebra esquemas de assinatura que fazem hash da string bruta. Repare: encodeURIComponent() também deixa em paz ! ' ( ) *, uma herança do antigo conjunto «mark» da RFC 2396. A RFC 3986 lista esses cinco como subdelimitadores, então o modo de componente aqui os escapa e avisa quando discorda da função nativa do navegador.

Não mais. O HTML já sugeriu que servidores aceitassem ; ao lado de & como separador de parâmetros, e esse conselho foi retirado da especificação em 2014. Navegadores e URLSearchParams nunca trataram o ; como separador, então a=1;b=2 é um único parâmetro chamado a cujo valor é o literal 1;b=2. Esta ferramenta reproduz esse comportamento e avisa quando vê um ponto e vírgula, porque um backend legado pode ainda dividir por ele e discordar do navegador que está na frente dele.

Sim: a ferramenta inteira é uma página estática sem servidor por trás. Analisar, codificar e decodificar acontecem na sua aba, nada é enviado, não há log e não há conta. Isso pesa mais aqui do que na maioria das ferramentas, porque query strings são exatamente onde acabam tokens de acesso, URLs assinadas, ids de sessão e endereços de e-mail. Se quiser uma segunda opinião, abra o painel de rede das ferramentas de desenvolvedor enquanto digita: não há requisição alguma para ver.