link Codificar / Decodificar URL star

Como Funciona

Uma URL só consegue transportar com segurança um alfabeto pequeno: letras, dígitos e os quatro símbolos não reservados - _ . ~. Tudo o mais é reescrito como um trio %XX, em que XX é o valor hexadecimal do byte do caractere — isso é a codificação em porcentagem do RFC 3986. Os caracteres que estruturam uma URL (? # / : @ & =, o conjunto "reservado") também são codificados sempre que aparecem dentro de um valor em vez de atuarem como delimitadores, já que um & literal dentro de um valor de consulta seria lido como o início do próximo parâmetro.

Texto não-ASCII é codificado byte a byte, não caractere a caractere: a ferramenta converte sua string para UTF-8 primeiro, depois codifica em hexadecimal cada byte resultante. A letra turca "ç" tem dois bytes em UTF-8 (0xC3 0xA7), então vira dois blocos de porcentagem, %C3%A7 — não um único código. Um exemplo concreto: codificar İstanbul çayı & simit produz %C4%B0stanbul%20%C3%A7ay%C4%B1%20%26%20simit. Observe que o espaço vira %20, o & reservado vira %26, e cada letra acentuada se expande em sua própria sequência multibyte.

Na prática, essa distinção importa mais ao montar requisições manualmente: colar uma URL de webhook com um valor de consulta que alguém te enviou, decodificar um parâmetro de rastreamento de um e-mail de marketing, ou descobrir por que uma chamada de API falha porque um & ou # não codificado se infiltrou em um valor e foi lido como delimitador em vez de dado. Codificar o valor primeiro e depois substituir o resultado no modelo da URL evita exatamente esse tipo de erro.

O Que Saber

• %20 vs +: a codificação em porcentagem do RFC 3986 sempre usa %20 para um espaço. A convenção + pertence a um padrão diferente e mais antigo — application/x-www-form-urlencoded, usado quando um formulário HTML envia dados — e só se aplica dentro desse formato específico de corpo, nunca dentro de um caminho ou de um valor de consulta devidamente codificado em porcentagem. Trocar os dois é uma fonte clássica de erros: um servidor que espera codificação de formulário lê um + perdido em uma string codificada em porcentagem como um sinal de mais literal, não como um espaço.
• Codifique um componente, não a URL inteira: esta ferramenta foi feita para um único valor de consulta ou segmento de caminho. Passar o endereço inteiro (incluindo https://) pelo codificador também escaparia as barras e os dois-pontos que tornam a URL válida, quebrando-a por completo.
• Mesmo mecanismo do seu navegador: ele chama as funções nativas encodeURIComponent/decodeURIComponent do navegador, então os resultados correspondem exatamente ao que um navegador real ou uma chamada fetch em JavaScript produziriam — não é uma aproximação.
• A ida e volta não tem perdas: codificar uma string e depois decodificar o resultado sempre retorna exatamente os bytes originais, o que torna fácil verificar manualmente um trabalho de codificação decodificando-o de volta e comparando com o texto de origem.
• Nada sai do seu navegador: a codificação e a decodificação rodam inteiramente no lado do cliente, instantaneamente, sem upload.