Ferramentas de desenvolvedor · Codificador e decodificador URL
RFC 3986 caracteres reservados e não reservados: o que diz o padrão URI
· Fundo
codificação de URL rfc3986 codificação percentual
RFC 3986 divide os caracteres em reservados, não reservados e tudo mais, e essa divisão explica cada regra de codificação percentual que você conheceu. Esta postagem lê as seções relevantes com clareza.
RFC 3986 caracteres reservados e não reservados – o que importa quando você cria URLs
RFC 3986 divide os caracteres em três categorias: não reservados, reservados e tudo o mais que deve ser codificado. Caracteres não reservados nunca precisam de codificação - são letras, dígitos, hífen, ponto final, sublinhado e til. O RFC lista-os explicitamente na seção 2.3, afirmando que é seguro deixá-los sem codificação em qualquer contexto URI. O teste no codificador e decodificador URL com esses caracteres mostra que eles passam inalterados. Os caracteres reservados subdividem-se em gen-delims (: / ? # [ ] @) e sub-delims (! $ & ' ( ) * + , ; =), cada um com significado estrutural em diferentes componentes URL.
Quando um caractere precisa de codificação? Os caracteres reservados devem ser codificados por porcentagem somente onde criarem ambigüidade. Uma barra marca os segmentos do caminho; em um valor de consulta deve ser %2F. Um E comercial separa os parâmetros; & em um valor requer %26. Caracteres não reservados nunca precisam de codificação – um hífen continua sendo um hífen. O padrão URL garante a análise correta. Testando com codificador e decodificador URL: inserir "hello/world" com encodeURIComponent produz "hello%2Fworld"; com encodeURI preserva a barra.
Sem reservas: letras, dígitos, hífen, ponto final, sublinhado e til — os caracteres que nunca precisam de codificação e nunca devem ser codificados
A codificação percentual usa% HH, onde HH é a notação hexadecimal. ASCII letra A (código 65) torna-se %41. Não-ASCII é requer codificação UTF-8: é (U+00E9) torna-se %C3%A9. Os padrões modernos especificam UTF-8 uniformemente em todos os navegadores.
URLs completos precisam de sintaxe estrutural intacta; os valores de consulta precisam de caracteres reservados internos inofensivos. O parâmetro de consulta ?q=R&D deve codificar & como %26 se for manual, caso contrário, o "e" comercial se torna um separador. Valores com barras tornam-se %2F no modo de componente. A codificação de componentes (encodeURIComponent) lida com isso codificando tudo, exceto letras, dígitos e - _ não reservados. ! ~ * ' ( ). Os testes mostram claramente a diferença entre os métodos.
Reservado: gen-delims e sub-delims — os dois grupos, seus membros e suas funções estruturais
As strings de consulta demonstram por que os caracteres reservados são importantes. O e comercial separa pares chave=valor: ?utm_source=email&utm_campaign=sale significa dois parâmetros. Dentro de um valor, o E comercial sem escape encerra o par. Equals separa chaves de valores. A análise ocorre em múltiplas camadas; cada um aplica as mesmas regras.
Os caracteres que exigem codificação em valores de consulta incluem E comercial, igual, hash, ponto de interrogação, espaços e letras não ASCII. Hash é o mais sorrateiro: #anything se torna um identificador de fragmento, nunca enviado ao servidor. Os nomes de campanha que terminam com hash perdem tudo o que vem depois dele antes que a solicitação saia do navegador. Os espaços devem se tornar %20. Testar com codificador e decodificador URL mostra modos de componente e formulário. A compreensão da posição determina a necessidade de codificação.
Quando caracteres reservados devem ser codificados — somente onde seriam confundidos com um delimitador, componente por componente
A codificação percentual persiste em RFC 3986. O conjunto não reservado permanece pequeno, garantindo a portabilidade. Caracteres não reservados com codificação percentual podem ser decodificados sem alteração de significado. A decodificação de %41 para A está correta porque A não tem reservas. A decodificação de %2F para / muda o significado quando a barra é um dado, não um separador. RFC 3986 seção de normalização 6 cobre abordagens sintáticas.
Personagens reservados em posições diferentes têm funções diferentes. Dois pontos no esquema marcam esquema:limite de autoridade; dois pontos em userinfo são dados. O ponto de interrogação abre a seção de consulta; a barra no valor da consulta é literal. Hash marca o início do fragmento. A posição determina a necessidade de codificação. As strings de consulta carregam valores que são URIs. A codificação de um redirecionamento URL como https://example.com/page?param=value como parâmetro requer a codificação de barras e dois pontos para %2F e %3A. O contexto sempre define caracteres seguros.
Exemplo resolvido: classificando cada caractere de um URL real - não reservado, reservado como delimitador, reservado como dados
RFC 1738 (1994) considerou muitos caracteres inseguros. À medida que as implantações foram padronizadas em UTF-8, os padrões posteriores relaxaram as restrições. Til (~) exemplifica a evolução: RFC 1738 necessário %7E, RFC 2396 (1998) moveu til para não reservado, RFC 3986 confirmou status não reservado. A evolução reflete lições de implantação. Os padrões preservam a compatibilidade com versões anteriores.
A normalização RFC permite a decodificação de caracteres não reservados codificados desnecessariamente por cento. %41 normaliza com segurança para A. Caracteres reservados codificados como %2F nunca são decodificados; mudar o significado quebra a estrutura. O consenso moderno usa RFC 3986 como linha de base de referência. O codificador e decodificador URL segue RFC 3986 por toda parte, oferecendo referência fixa separada do comportamento do navegador. WHATWG URL O padrão adiciona conjuntos de codificação específicos de componentes além de RFC. Os padrões coexistem: RFC 3986 para análise geral URL, WHATWG para navegadores da web. As bibliotecas são diferentes; verifique a documentação.
Orientação de normalização na seção 6 — caso hexadecimal, decodificação sem reserva e regras de segmento de caminho
Os testes em RFC 3986 garantem que os URLs funcionem em softwares que abrangem décadas. O codificador e decodificador URL fornece uma linha de base de codificação RFC 3986 para aplicar aos componentes construídos. Leia a documentação padrão que explica cada decisão de codificação nas bibliotecas URL. WHATWG URL baseia-se em RFC 3986 em vez de substituí-lo totalmente. Construindo URLs para navegadores gerais? Siga RFC 3986; os navegadores aplicam regras WHATWG na parte superior. Sistemas mais antigos? Teste implementações reais. Normalizando para armazenamento? Aplique RFC 3986 consistentemente. Compreender a distinção reservado/unreserved informa caracteres seguros.
A codificação URL não é uma sanitização de segurança. Cada contexto—SQL, HTML, JavaScript, URI—precisa de sua própria codificação de saída. A codificação percentual protege apenas a estrutura URL. Aplique a defesa certa na camada certa.
O que isso não cobre - os diferentes conjuntos de codificação do padrão WHATWG URL e o manuseio de IRI
RFC 2396 (1998) esclareceu conjuntos de caracteres com mais rigor do que RFC 1738. Ele formalizou caracteres reservados servindo à estrutura URI e não reservados como dados literais. Expandido sem reservas, incluindo hífen, ponto final, sublinhado e til sobre as definições originais. RFC 2396 introduziu distinção entre gen-delims (:, /, ?, #, [, ], @) e sub-delims (!, $, &, ', (, ), *, +, ,, ;, =). Cada grupo tem diferentes funções estruturais em URLs. A nomenclatura esclarece que os caracteres reservados são divididos em dois grupos. Saber os nomes ajuda nas discussões técnicas.
RFC 3986 (2005) é uma referência moderna. Manteve a distinção reservado/unreserved, mas a notação simplificada. Os órgãos de padronização não quebram a web retroativamente. Codifique deliberadamente conhecendo seu padrão. O codificador e decodificador URL fornece referência RFC 3986.
Conclusão: o padrão é curto e preciso - como os dois modos do codificador e decodificador URL correspondem à codificação de dados versus preservação de delimitadores
A escolha dos padrões depende do contexto. Construindo URLs para navegadores gerais? Siga RFC 3986; os navegadores aplicam regras WHATWG. Sistemas mais antigos? Teste implementações reais. Normalizando para armazenamento? Aplique RFC 3986 consistentemente. As regras de codificação percentual evoluíram do conservador RFC 1738 até o RFC 2396 e RFC 3986 esclarecido até o padrão WHATWG URL em camadas. Cada geração refletiu experiência. Os construtores modernos seguem RFC 3986 ou WHATWG contextualmente. URLs antigos e novos coexistem, exigindo pensamento de compatibilidade. Compreender as categorias evita erros de codificação.
Verifique a codificação dos URLs corretamente antes da implantação. O codificador e decodificador URL demonstra regras de RFC 3986 de ponta a ponta. Veja valores hexadecimais exatos e entenda quais caracteres são codificados. Use esta ferramenta ao construir URLs concatenando peças. RFC 3986 categorias reservadas e não reservadas particionam conjuntos de caracteres para análise URI consistente.