Em um URL, os espaços devem ser codificados usando% 20 ou +?

Em um URL, devo codificar os espaços usando %20 ou + ? Por exemplo, no exemplo a seguir, qual deles está correto?

 www.mydomain.com?type=xbox%20360 www.mydomain.com?type=xbox+360 

Nossa empresa está inclinada para o primeiro, mas usando o método Java URLEncoder.encode(String, String) com "xbox 360" (e "UTF-8" ) retorna o último .

Então, qual a diferença?

Os dados de formulário (para GET ou POST) geralmente são codificados como application/x-www-form-urlencoded : isso especifica + para espaços.

URLs são codificados como RFC 1738, que especifica %20 .

Em teoria, acho que você deveria ter 20% antes do ? e + depois:

 example.com/foo%20bar?foo+bar 

De acordo com o W3C (e eles são a fonte oficial sobre essas coisas), um caractere de espaço na seqüência de consulta (e na seqüência de consulta somente) pode ser codificado como ” %20 ” ou ” + “. Na seção “Sequências de consulta” em “Recomendações”:

Dentro da string de consulta, o sinal de mais é reservado como notação abreviada para um espaço. Portanto, sinais reais mais devem ser codificados. Esse método foi usado para facilitar a passagem de URIs de consulta em sistemas que não permitiam espaços.

De acordo com a seção 3.4 do RFC2396, que é a especificação oficial em URIs em geral, o componente “consulta” é dependente de URL:

3.4. Componente de Consulta O componente de consulta é uma cadeia de informações a ser interpretada pelo recurso.

  query = *uric 

Dentro de um componente de consulta, os caracteres “;”, “/”, “?”, “:”, “@”, “&”, “=”, “+”, “,” E “$” são reservados.

Portanto, é um bug no outro software se ele não aceitar URLs com espaços na string de consulta codificados como ” + “.

Quanto à terceira parte da sua pergunta, uma maneira (embora um pouco feia) de corrigir a saída de URLEncoder.encode() é chamar replaceAll("\\+","%20") no valor de retorno.

Essa confusão ocorre porque a URL ainda está “quebrada” até hoje

Pegue ” http://www.google.com.br “, por exemplo. Este é um URL. Uma URL é um localizador de resources uniforme e é realmente um ponteiro para uma página da Web (na maioria dos casos). Na verdade, as URLs têm uma estrutura muito bem definida desde a primeira especificação em 1994.

Podemos extrair informações detalhadas sobre o URL ” http://www.google.com.br “:

 +---------------+-------------------+ | Part | Data | +---------------+-------------------+ | Scheme | http | | Host address | www.google.com | +---------------+-------------------+ 

Se olharmos para um URL mais complexo, como ” https: // bob: bobby@www.lunatech.com: 8080 / file; p = 1? Q = 2 # terceiro “, podemos extrair as seguintes informações:

 +-------------------+---------------------+ | Part | Data | +-------------------+---------------------+ | Scheme | https | | User | bob | | Password | bobby | | Host address | www.lunatech.com | | Port | 8080 | | Path | /file | | Path parameters | p=1 | | Query parameters | q=2 | | Fragment | third | +-------------------+---------------------+ 

Os caracteres reservados são diferentes para cada parte

Para URLs HTTP, um espaço em uma parte de fragment de caminho tem que ser codificado para “% 20” (não, absolutamente não “+”), enquanto o caractere “+” na parte de fragment de caminho pode ser deixado sem codificação.

Agora, na parte de consulta, os espaços podem ser codificados para “+” (para compatibilidade com versões anteriores: não tente procurá-lo no padrão de URI) ou “% 20” enquanto o caractere “+” (como resultado dessa ambiguidade ) tem que ser escapado para “% 2B”.

Isso significa que a string “azul + azul claro” precisa ser codificada de maneira diferente no caminho e nas partes da consulta: ” http://example.com/blue+light%20blue?blue%2Blight+blue “. A partir daí, você pode deduzir que a codificação de uma URL totalmente construída é impossível sem uma percepção sintática da estrutura da URL.

O que isso se resume é

você deveria ter %20 antes do ? e + depois

Fonte

Não deveria importar mais do que se você codificasse a letra A como% 41.

No entanto, se você está lidando com um sistema que não reconhece um formulário, parece que você vai ter que dar o que ele espera, independentemente do que a “especificação” diz.

Você também pode usar – o que significa que a maioria das pessoas opta por “+”, pois é mais legível para humanos.

Quando codificar valores de consulta, seja forma, mais ou por cento-20, é válido; no entanto, como a largura de banda da Internet não é infinita, você deve usar plus, já que são dois bytes a menos.