Ferramentas de desenvolvedor · Codificador e decodificador URL
Como funciona a codificação percentual: de caracteres a UTF-8 bytes a sequências %XX
· Como funciona
codificação de URL utf-8 codificação percentual desenvolvedor
A codificação percentual não codifica caracteres; ele codifica bytes. Esta postagem mostra como um caractere se torna UTF-8 bytes e depois pares hexadecimais, e por que uma letra acentuada ocupa dois grupos %XX enquanto um emoji ocupa quatro.
Por que 'é' se transforma em %C3%A9 em vez de %E9 — a observação que revela a camada de bytes abaixo
Quando um desenvolvedor júnior vê %C3%A9 em URL, a codificação percentual opera em bytes, não em caracteres. O caractere é não é um byte; UTF-8 codifica-o como dois: C3 A9. A regra de codificação percentual de RFC 3986 é simples: codifique cada byte como um sinal de porcentagem seguido por dois dígitos hexadecimais. Essa distinção transforma a explicação de misteriosa em lógica.
Compreender a codificação percentual requer compreender UTF-8. O texto deve ser convertido em bytes usando codificação de caracteres. UTF-8 é o padrão para URLs e web. Ele expressa caracteres como sequências de bytes de comprimento variável: ASCII usa um byte, letras acentuadas usam dois, emoji usa quatro. Cada estágio é distinto: caractere, ponto de código Unicode, UTF-8 bytes e, em seguida, pares %XX. Pular para hexadecimal sem entender os bytes é perder o foco.
A regra de codificação percentual de RFC 3986 - um% seguido por dois dígitos hexadecimais por byte, preferencialmente letras maiúsculas
RFC 3986 define uma regra: codificar cada byte como uma porcentagem seguida por dois dígitos hexadecimais maiúsculos. Caracteres não reservados que não precisam de codificação são letras, dígitos, hífen, sublinhado, ponto final e til. Todo o resto deve ser codificado. Os espaços tornam-se %20, as barras tornam-se %2F e o sinal de porcentagem torna-se %25. Isso evita que caracteres especiais em valores de consulta quebrem a estrutura URL.
Um espaço é codificado como byte 0x20, tornando-se %20. Uma barra é 0x2F, tornando-se %2F. Estes são ASCII caracteres que precisam de um byte. Letras acentuadas e emojis são diferentes. O sinal de porcentagem se torna %25. Delimitadores reservados, como dois pontos, são codificados para preservar a estrutura. Isso evita que um E comercial incorporado ou igual em um parâmetro de consulta interrompa a análise. Cada byte se torna% HH.
UTF-8 como o conjunto de caracteres assumido — por que os URLs modernos são UTF-8 e onde estão as exceções herdadas
UTF-8 usa codificação de comprimento variável. ASCII dos pontos de código 0 a 127 é um byte. Os caracteres de 128 a 2047, incluindo letras latinas acentuadas, têm dois bytes. Os caracteres de 2048 a 65535, comuns em scripts do Leste Asiático, têm três bytes. Os caracteres acima de 65535, incluindo a maioria dos emojis, têm quatro bytes. Cada byte é prefixado com bits que sinalizam quantos bytes se seguem.
A letra acentuada é é o ponto de código Unicode U+00E9. UTF-8 codifica-o como dois bytes: 0xC3 e 0xA9. A codificação percentual produz %C3%A9. Alemão ü (U+00FC) codifica como 0xC3 0xBC, tornando-se %C3%BC. Espanhol ñ (U+00F1) codifica como 0xC3 0xB1, tornando-se%C3%B1. O padrão é consistente: o primeiro byte sinaliza uma sequência de dois bytes. Uma letra acentuada se expande em seis caracteres na codificação.
Exemplo resolvido: codificação 'café 😀' byte por byte - os pontos de código, os bytes UTF-8 e a string resultante
Emoji torna a camada de bytes óbvia. O emoji de polegar para cima 👍 é o ponto de código U+1F44D. UTF-8 codifica-o como quatro bytes: F0 9F 91 8D. A codificação percentual produz %F0%9F%918D: doze caracteres para um símbolo. O smiley 😀 (U+1F600) codifica como F0 9F 98 80, tornando-se %F0%9F%9880. Sequências de quatro bytes tornam-se caracteres codificados em doze por cento.
O texto misto mostra por que a compreensão dos bytes é importante. A frase "café 😀" contém ASCII simples, um sotaque e um emoji. As letras c, a, f são codificadas como 63, 61, 66. O é codifica como C3 A9. O espaço codifica como 20. O emoji é codificado como F0 9F 98 80. O resultado é "caf%C3%A9%20%F0%9F%9880". Compreender quais bytes precisam de codificação torna a saída previsível.
Decodificação ao contrário - coletando grupos %XX em bytes e só então interpretando-os como UTF-8
A decodificação inverte o processo. Um decodificador procura pares %XX e os coleta em valores de bytes. Vendo %C3%A9, ele extrai os bytes C3 e A9. A decodificação UTF-8 os interpreta como o caractere é. Se uma sequência estiver incompleta, como apenas %C3, o resultado será um erro. O decodificador sabe pelos bits de prefixo UTF-8 que C3 requer um segundo byte.
O caso não importa em dígitos hexadecimais; %C3%A9 e %c3%a9 decodificam de forma idêntica. RFC permite letras maiúsculas ou minúsculas, embora maiúsculas sejam preferidas. Mas maiúsculas e minúsculas são importantes para caracteres: é (como %C3%A9) não é o mesmo que É (como %C3%89). A comparação URL deve normalizar a codificação percentual ou corre o risco de tratar recursos idênticos como diferentes. As estruturas normalizam antes do armazenamento em cache.
Por que o caso não importa em dígitos hexadecimais, mas em outros lugares - regras de normalização e comparação URL
RFC 3986 menciona punycode para nomes de domínio e codificação de formulário para envios como regras separadas. Punycode codifica nomes de domínio não ASCII sem sinais de porcentagem para compatibilidade com DNS. O domínio 😀.example passa a ser "xn--js8h.example". A codificação do formulário modifica a codificação percentual com uma exceção: os espaços tornam-se sinais de mais em vez de %20. Formulários enviados como application/x-www-form-urlencoded usam mais para espaços.
A ferramenta do codificador URL mostra todos os três modos: codificação de componente, codificação inteira-URL e codificação de formulário. A codificação de componentes com encodeURIComponent codifica todos os caracteres especiais, incluindo delimitadores, adequados para valores de consulta. A codificação Whole-URL com encodeURI preserva caracteres estruturais para URLs completos. A codificação do formulário é para corpos POST. Cada um usa UTF-8; eles diferem apenas em quais bytes ficam sem codificação.
Punycode e codificação de formulário: padrões irmãos, não extensões de codificação percentual
A perspectiva do byte resolve URL mistérios. Por que um emoji precisa de doze caracteres? Porque UTF-8 usa quatro bytes, cada um se tornando %HH. Por que alguns URLs possuem %2F para barras enquanto outros possuem barras simples? Porque o modo de codificação decide: uma barra em um segmento de caminho permanece não codificada, mas dentro de um valor de consulta deve ser %2F para evitar leitura incorreta.
Pense em bytes para uma codificação percentual previsível. Um caractere é um ponto de código Unicode. UTF-8 é sua representação de bytes. A codificação percentual é o formato de transmissão. A expansão do personagem acontece na camada UTF-8. O caso hexadecimal não afeta a decodificação, mas o caso do caractere sim. Sequências de bytes inválidas falham em UTF-8 devido a regras rígidas de prefixo. A ferramenta codificadora URL mostra essa progressão.
Conclusão: pense em bytes - como o codificador e decodificador URL mostra a saída %XX exata para qualquer texto que você colar no navegador
Exemplo resolvido: codificação "café 😀". A palavra café tem letras c, a, f como ASCII bytes únicos: 63, 61, 66. O é tem UTF-8 dois bytes: C3 A9. O espaço é 20. Emoji 😀 tem quatro bytes: F0 9F 98 80. As letras ASCII não reservadas permanecem visíveis. Resultado: "caf%C3%A9%20%F0%9F%9880". Isso mostra por que um emoji se expande para doze caracteres.
Conclusão: pense em bytes, não em caracteres. A codificação percentual é aplicada após a codificação UTF-8. Cada byte se torna% HH. UTF-8 de comprimento variável significa que os caracteres se expandem de maneira diferente: ASCII torna-se %XX (dois caracteres), acentos de dois bytes tornam-se %XX%XX (seis caracteres), emoji de quatro bytes torna-se %XX%XX%XX%XX (doze caracteres). Cole o texto na ferramenta do codificador URL e observe a progressão.