Ferramentas de desenvolvedor · Codificador e decodificador URL
Mais versus %20: o histórico do aplicativo/x-www-form-urlencoded
· Fundo
codificação de URL formulários html padrões http
Os formulários codificam um espaço como + enquanto o padrão URI diz %20, e o motivo é histórico. Esta postagem traça a convenção desde os primeiros formulários HTML até a definição atual de WHATWG e explica por que ela nunca desapareceu.
Mais versus %20 — por que formulários e URIs codificam espaços de maneira diferente
Os formulários HTML enviados como GET codificam espaços como sinais de mais na string de consulta. O mesmo espaço se torna %20 em URLs após RFC 3986. Ambos estão corretos porque seguem padrões diferentes. Os campos de formulário contendo espaços tornam-se nome=valor+com+espaços na codificação do formulário, mas %20 em RFC 3986. A distinção de mais por cento e vinte marca qual padrão se aplica aos seus dados.
A codificação de formulário usa mais para espaços como convenção histórica da definição original de envio de formulário de RFC 1866 (1995), HTML 2.0. GET solicita espaços codificados como sinais de mais, reservando mais para literal + codificado como %2B. Esta regra se aplica apenas à sintaxe application/x-www-form-urlencoded, e não à sintaxe geral URI. Bilhões de estruturas de servidores tornaram-se dependentes desta convenção. Testar ambos mostra diferenças claras: o modo formulário produz mais; O modo URI produz %20. O codificador e decodificador URL oferece ambos os modos para comparação direta.
Formulários HTML anteriores e envios GET anteriores — como a codificação do formulário foi definida e por que + foi escolhido
RFC 1866 (1995) definiu o envio de formulário onde os espaços se tornam mais e o sinal de mais literal se torna %2B. Isso se aplica apenas ao aplicativo/x-www-form-urlencoded. RFC 3986 especificado %20 para sintaxe geral URI. Dois padrões coexistiram deliberadamente.
RFC 2396 esclareceu os conjuntos de caracteres com mais rigor do que os padrões anteriores. Ele formalizou caracteres reservados que atendem à estrutura URI versus não reservados como dados literais. Os órgãos de padronização codificam o comportamento do navegador e do proxy à medida que ele evolui. RFC 3986 veio depois sem alterar o comportamento da codificação, apenas esclarecendo a notação. Todos os navegadores atuais padronizam a codificação UTF-8. HTML formulários por meio de botões de envio enviam o formato do aplicativo/x-www-form-urlencoded com mais para espaços. A construção manual de URI usa %20. A compreensão de ambos os padrões evita surpresas de integração.
Especificações de RFC 1866 e HTML posteriores — onde a regra foi escrita e como ela divergiu da sintaxe de URI
WHATWG URL O padrão especifica que URLSearchParams.toString() produz a saída do aplicativo/x-www-form-urlencoded com sinais de mais para espaços. URL codificações percentuais do construtor seguindo RFC 3986. Navegador navegando para URL com espaço codificado %20; formulário enviado como GET codifica plus. Essas ferramentas fundamentalmente diferentes servem a propósitos diferentes. O encodeURIComponent manual fornece %20 para espaços — estilo RFC 3986. Formulários enviados para o mesmo URL enviam plus. Os servidores que analisam os envios de formulários esperam mais; receber %20 causa falhas silenciosas de parâmetros.
Testar ambos revela suposições do lado do servidor das quais você depende. JavaScript URLSearchParams fornece ocultação segura de codificação em estilo de formulário, além de complexidade. Construa URLSearchParams, anexe entradas, chame toString() para obter application/x-www-form-urlencoded com o sinal de adição adequado. Como alternativa, crie strings de consulta com encodeURIComponent; você obtém RFC 3986 %20. Nunca misture abordagens. Strings de consulta com plus manual e encodeURIComponent criam ambiguidade. Os receptores não conseguem distinguir se mais significa espaço ou mais literal. As abordagens padrão são tratadas de forma consistente.
O padrão URL hoje — aplicação/x-www-form-urlencoded como um serializador separado com suas próprias regras
APIs JSON normalmente rejeitam o plus como espaço, esperando %20 por RFC 3986. Os clientes que enviam plus falham silenciosamente: os parâmetros desaparecem. Testar APIs com ambas as codificações revela qual padrão elas aceitam. URLSearchParams em JavaScript lida com a codificação de formulário. O codificador e decodificador URL produz RFC 3986 %20.
O envio do formulário HTML trata automaticamente da codificação. A estrutura do seu servidor decide quais regras se aplicam. Rails, Django, PHP tratam o plus como espaço nos dados do formulário recebidos automaticamente. Mas construir manualmente strings de consulta para os mesmos endpoints é extremamente importante. Um plus carregado cria ambiguidade. A conformidade das especificações e o comportamento do servidor no mundo real divergem ligeiramente. Documente qual padrão seus endpoints esperam. Teste os dois estilos de codificação. O código defensivo lida com ambos normalmente.
Exemplo resolvido: o mesmo campo de formulário visto como uma string de consulta e como um corpo de solicitação — com + em um lugar e %20 em outro
JavaScript URLSearchParams aplica codificação de formulário: o espaço torna-se mais, não %20. new URLSearchParams({q: "hello world"}) produz "q=hello+world", não "q=hello%20world". Esta é a regra histórica do aplicativo/x-www-form-urlencoded incorporada especificamente em JavaScript. Mas passar essa string como consulta bruta para new URL mantém o sinal de mais como mais; apenas URLSearchParams o decodifica como espaço. O construtor é fiel ao que vê. A diferença do sinal de mais causa erros comuns ao misturar funções incorretamente.
O construtor URL e encodeURIComponent são ferramentas diferentes. encodeURIComponent codifica quase tudo, exceto letras, dígitos e - _ não reservados. ! ~ * ' ( ). Não assume nenhum contexto. O construtor URL analisa URL reais e aplica regras WHATWG por componente. encodeURIComponent transforma "hello/world" em "hello%2Fworld"; new URL vê barras como separadores de caminho. Mesma entrada, saída diferente. Use encodeURIComponent ao criar URLs concatenando partes. Use o construtor URLSearchParams ou URL para URLs completos ou parciais.
Por que não pode ser consertado – décadas de servidores e clientes que dependem do comportamento atual
As regras de codificação percentual evoluíram de RFC 1738 (1994) através de RFC 2396 (1998) para RFC 3986 (2005). Cada geração esclareceu ambigüidades. RFC 1738 era conservador, tratando os personagens como inseguros porque a web inicial tinha suporte limitado a personagens. Implantações padronizadas em UTF-8, as implementações tornaram-se consistentes. Os padrões posteriores relaxaram as restrições aos caracteres que se mostravam seguros em todos os sistemas. Consenso moderno: UTF-8 em todos os lugares. Os órgãos de padronização mantêm ferozmente a compatibilidade com versões anteriores. A reparação exigiria coordenação mundial – impossível após três décadas. Dois padrões coexistem deliberadamente.
Testar com plus e %20 revela suposições do servidor. Os logs do servidor mostram o que os clientes enviam. Formulários usam mais; URLs manuais usam %20. Escolha por contexto e siga a documentação API.
O que isso não cobre — corpos multipart/form-data e JSON
Testar ambas as codificações revela o comportamento do servidor. Envie a+b nos dois sentidos. Muitos servidores de produção esperam codificação de formulário; APIs mais recentes esperam %20. Sua escolha depende das expectativas do receptor. URLSearchParams lida com codificação de formulário; encodeURIComponent lida com a codificação RFC.
Nunca combine métodos de codificação. O valor codificado com encodeURIComponent %2B e então passado para URLSearchParams é codificado duas vezes como %252B. A decodificação uma vez produz% 2B em vez de mais. O caractere torna-se uma string literal de porcentagem dois-seis em vez de um sinal de mais. Verifique as etapas intermediárias em seu processo de construção. A codificação acontece exatamente uma vez por valor. Documente qual padrão de codificação seu pipeline usa. Teste com caracteres especiais, incluindo mais, espaço, e comercial.
Conclusão: dois padrões, ambos corretos em seu contexto - como o codificador e decodificador URL fornece o formato RFC 3986, com %20 para espaços, para que você saiba qual deles está olhando
A divisão de mais versus vinte não é um bug a ser corrigido. É um artefato histórico de padrões que resolvem problemas distintos de maneira diferente. A reparação exigiria coordenação mundial – impossível após trinta anos. Os órgãos de padronização não quebram a web retroativamente. RFC 3986, regras de formulário, construção de navegador URL têm padrões e motivos. A codificação de formulário RFC 1866 e a codificação RFC 3986 URI atendem a camadas diferentes. Codifique deliberadamente conhecendo seu padrão. Teste contra cargas realistas.
Escolha a codificação por contexto. Os formulários usam plus de acordo com os padrões HTML. URIs manuais usam %20 por RFC 3986. As APIs especificam o que esperar; siga a documentação ou teste ambos. O codificador e decodificador URL mostra RFC 3986. Precisa de codificação de formulário? URLSearchParams faz isso. Ferramenta não mistura codificações; compreender os padrões evita surpresas. A inconsistência de codificação entre as camadas causa perda sutil de parâmetros, truncamento e corrupção de dados. Ambos os padrões estão corretos em seu domínio. Aplique deliberadamente e documente.