Ferramentas de desenvolvedor · Codificador e decodificador URL
Do padrão RFC 1738 ao padrão URL: como as regras de codificação percentual evoluíram
· Fundo
codificação de URL história rfc padrões da web
As regras para caracteres de escape em URLs foram reescritas diversas vezes desde 1994. Esta postagem segue RFC 1738, RFC 2396, RFC 3986 e o padrão WHATWG URL e explica o que mudou a cada vez.
De RFC 1738 ao padrão URL – como as regras de codificação percentual evoluíram
Til (~) exemplifica como as regras de codificação mudam entre gerações e implantações de padrões. RFC 1738 (1994) necessário %7E em todos os lugares; RFC 2396 (1998) moveu o til para não reservado, permitindo não codificado. RFC 3986 (2005) confirmou status não reservado. URLs antigos com %7E permanecem válidos; saída de novos construtores ~. A evolução reflete as lições de implantação à medida que a web amadurece e a infraestrutura é padronizada. RFC 1738 era conservador porque a infraestrutura inicial era heterogênea e variada.
RFC 1738 comportamento do navegador 1994 codificado. Implantações padronizadas em UTF-8; as restrições revelaram-se desnecessárias. Os padrões posteriores relaxaram as restrições de caráter. RFC 3986 permite a decodificação segura de caracteres não reservados.
RFC 1738 (1994): personagens ‘inseguros’ e as primeiras regras de fuga — o que foi considerado perigoso e por quê
RFC 1738 definiu caracteres "inseguros" como aqueles que conflitam com a sintaxe URI (espaço, barra), historicamente usados em protocolos (caracteres de controle) ou que os sistemas não podiam transmitir com segurança. Lista conservadora codificada em porcentagem muito mais do que o necessário para a Internet moderna. Muitos sistemas anteriores são anteriores a RFC; codificou seu comportamento. Os personagens de controle eram genuinamente perigosos nos protocolos; espaços eram problemas de transmissão para clientes HTTP lendo linhas de comando. Os sistemas modernos lidam com esses casos de maneira mais elegante por meio de codificação explícita.
O teste em RFC 1738 revela o que os sistemas antigos esperavam. Codifique um caractere da especificação URL da década de 1990 e compare com o RFC 3986 moderno. As diferenças mostram o que ficou relaxado. Conjunto não reservado expandido ao longo do tempo. Hífen, ponto final e sublinhado sempre foram seguros. Tilde precisava de RFC 2396 para ficar segura. A abordagem conservadora significava compatibilidade com versões anteriores. URLs antigos criados de acordo com as regras RFC 1738 permanecem válidos até hoje. A normalização na seção RFC 3986 6 permite a decodificação de caracteres não reservados codificados desnecessariamente por cento com segurança.
RFC 2396 (1998) — reservado versus não reservado, a sintaxe genérica e o til reabilitado
RFC 2396 (1998) esclareceu conjuntos de caracteres com mais rigor do que RFC 1738. Ele formalizou caracteres reservados que atendem à estrutura URI versus não reservados como dados literais. Expandido sem reservas, incluindo hífen, ponto final, sublinhado, til. Reconheceu a sintaxe genérica URI separada das regras específicas do esquema. RFC 2396 introduziu distinção entre gen-delims (:, /, ?, #, [, ], @) e sub-delims (!, $, &, ', (, ), *, +, ,, ;, =). A nomenclatura esclarece que os caracteres reservados são divididos em dois grupos com funções estruturais diferentes.
RFC 2396 introduziu orientações de normalização especificando quais caracteres codificados por porcentagem poderiam ser decodificados sem alteração significativa. A decodificação de caracteres não reservados é normalizada. Sticks de codificação de caracteres reservados. RFC 3986 notação simplificada ainda mais. Os padrões mantêm ferozmente a compatibilidade com versões anteriores.
RFC 3986 (2005) — ! * ' ( ) passa para subdelims, gen-delims são nomeados e a orientação de normalização chega
RFC 3986 (2005) é um padrão de referência moderno para codificação percentual. Ele manteve a distinção reservado/unreserved, mas simplificou a notação e adicionou orientações de normalização. Tilde moveu-se inequivocamente sem reservas. Caracteres não reservados codificados por porcentagem esclarecidos padrão podem ser decodificados sem alteração de significado. A seção RFC 3986 3 descreve a sintaxe URI com precisão. A seção 2 define categorias de caracteres. A seção 6 dedica regras formais à normalização sintática. A normalização baseada em comparação considera os URIs idênticos se os formulários normalizados corresponderem. A remoção de segmentos de pontos dos caminhos normaliza sem alteração significativa.
A normalização é importante para análises, armazenamento em cache e acompanhamento de links. URLs que diferem apenas em letras hexadecimais (RFC 3986 prefere letras maiúsculas) devem ser idênticos na prática. A normalização evita entradas de log duplicadas e falhas de cache. Caches codificados em URLs normalizados servem conteúdo independentemente da preferência de codificação do solicitante. A orientação de normalização RFC 3986 permite que os sistemas tomem decisões consistentes. Mas a aplicação estrita impede que os URLs funcionem bem na Internet atual.
O padrão WHATWG URL: analisando o que os navegadores realmente recebem — conjuntos de codificação, esquemas especiais e tolerância a erros
WHATWG URL Padrão (2016–presente) surgiu da experiência do navegador com URLs que não seguem RFC 3986 perfeitamente. Os navegadores enfrentaram espaços não codificados, codificações mistas, peculiaridades. WHATWG descreve a análise real do navegador, não a gramática teórica. Os navegadores do mundo real desenvolveram regras práticas para tolerar espaços, lidar com caracteres escapados e recuperar-se de entradas malformadas. RFC 3986 chegou em 2005 e definiu a gramática formal, mas os navegadores na prática já divergiram um pouco.
WHATWG define nove conjuntos de codificação com regras específicas de contexto. O espaço no caminho passa a ser %20; a barra nas informações do usuário se torna %2F. O navegador aplica um padrão mais restrito para a web. RFC 3986 fornece linha de base; WHATWG se baseia nisso.
Exemplo resolvido: um URL com um til, um espaço e um caractere não ASCII — como cada geração de regras o codifica
Domínios internacionalizados usam codificação punycode (München se torna xn--mnchen-3ya). Caminhos e consultas ainda usam codificação percentual. A parte do domínio usa punycode; as partes do caminho e da consulta usam codificação percentual. As camadas não se misturam nem interferem.
IDNA (Nomes de Domínio Internacionalizados em Aplicativos) resolve o problema de nome de host. Punycode codifica não-ASCII em ASCII para compatibilidade com DNS. O prefixo xn-- sinaliza a codificação punycode. O algoritmo é determinístico: münchen sempre se torna xn--mnchen-3ya. Caracteres não ASCII devem ser convertidos antes da resolução DNS. A codificação percentual não funciona para nomes de host devido a restrições DNS e limites de rótulo. Cada abordagem resolve problemas diferentes corretamente. Os padrões evoluíram separadamente por boas razões.
O que isso não cobre — IRIs e nomes de domínio internacionalizados, que têm sua própria história
A escolha dos padrões depende do contexto. Construindo URLs para navegadores? Siga RFC 3986; navegadores aplicam WHATWG. Sistemas mais antigos? Implementações de teste. Compreender a evolução evita confusão.
Os construtores modernos devem seguir RFC 3986 ou WHATWG contextualmente. URLs antigos e novos coexistem, exigindo uma reflexão cuidadosa sobre compatibilidade. O codificador e decodificador URL segue RFC 3986 por toda parte, oferecendo referência fixa separada do comportamento do navegador. WHATWG adiciona conjuntos de codificação específicos de componentes além do básico de RFC. Saber o que mudou e quando ajuda a entender por que os sistemas discordam. Testar seu URL com ambos os padrões revela qual padrão controla seu ambiente. Ambos os padrões estão corretos.
Conclusão: saiba qual livro de regras seu código segue - como o codificador e decodificador URL fornece o comportamento RFC 3986 como um ponto de referência fixo
A normalização RFC 3986 permite a decodificação de caracteres não reservados codificados desnecessariamente por cento com segurança. %41 normaliza para A. Caracteres reservados codificados como %2F nunca são decodificados; mudar o significado quebra a estrutura. Os órgãos de padronização mantêm ferozmente a compatibilidade com versões anteriores. A resolução exigiria uma coordenação mundial impossível após décadas. Os livros de padrões não quebram a web retroativamente. A alteração das decisões de codificação quebra bilhões de sistemas existentes simultaneamente.
A codificação percentual abrange três décadas de evolução cuidadosa: de RFC 1738 a RFC 2396 e RFC 3986 até o moderno padrão WHATWG URL. O código moderno deve seguir a linha de base RFC 3986. URLs antigos com codificação anterior permanecem válidos. Testar viagens de ida e volta garante correção e compatibilidade.