online - En una URL, ¿los espacios deben codificarse usando% 20 o+?

url encode php

Question

Esta pregunta ya tiene una respuesta aquí:

• URL que codifica el carácter de espacio: + o% 20? 4 respuestas

En una URL, ¿debo codificar los espacios usando %20 o + ? Por ejemplo, en el siguiente ejemplo, ¿cuál es el correcto?

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

Nuestra empresa se inclina por la primera, pero utilizando el método de Java URLEncoder.encode(String, String) con "xbox 360" (y "UTF-8" ) devuelve la última .

Entonces, ¿cuál es la diferencia?

Answer 1

Al codificar valores de consulta, la forma, más o porcentaje-20, es válida; sin embargo, dado que el ancho de banda de Internet no es infinito, debe usar más, ya que son dos bytes menos.

Answer 2

Esta confusión se debe a que la URL todavía está "rota" hasta el día de hoy

Tome " http://www.google.com ", por ejemplo. Esta es una URL. Una URL es un localizador uniforme de recursos y en realidad es un puntero a una página web (en la mayoría de los casos). Las URL en realidad tienen una estructura muy bien definida desde la primera especificación en 1994.

Podemos extraer información detallada sobre la URL " http://www.google.com ":

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

Si observamos una URL más compleja como " https://bob:[email protected]:8080/file;p=1?q=2#third ", podemos extraer la siguiente información:

+-------------------+---------------------+
| 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 |
+-------------------+---------------------+

Los caracteres reservados son diferentes para cada parte

Para las URL HTTP, un espacio en una parte del fragmento de ruta debe estar codificado en "% 20" (no, absolutamente no "+"), mientras que el carácter "+" en la parte del fragmento de ruta puede dejarse sin codificar.

Ahora en la parte de consulta, los espacios pueden codificarse como "+" (para compatibilidad con versiones anteriores: no intente buscarlos en el estándar URI) o "% 20" mientras que el carácter "+" (como resultado de esta ambigüedad ) tiene que ser escapado a "% 2B".

Esto significa que la cadena "azul + azul claro" debe codificarse de manera diferente en la ruta y las partes de la consulta: " http://example.com/blue+light%20blue?blue%2Blight+blue ". A partir de ahí, puede deducir que la codificación de una URL completamente construida es imposible sin una conciencia sintáctica de la estructura de la URL.

Lo que esto se reduce a es

deberías tener %20 antes que ? y + después

Source

Answer 3

Los datos de formulario (para GET o POST) generalmente se codifican como application/x-www-form-urlencoded : esto especifica + para espacios.

Las URL están codificadas como RFC 1738, que especifica %20 .

En teoría, ¿debería tener% 20 antes de ? y + después:

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

Answer 4

No debería importar, al igual que si codificaras la letra A como% 41.

Sin embargo, si se trata de un sistema que no reconoce un formulario, parece que tendrá que darle lo que espera, independientemente de lo que diga la "especificación".

Answer 5

Puede usar cualquiera de los dos, lo que significa que la mayoría de las personas opta por "+" ya que es más legible por humanos.

Answer 6

Según el W3C (y son la fuente oficial de estas cosas), un carácter de espacio en la cadena de consulta (y solo en la cadena de consulta) puede codificarse como " %20 " o " + ". Desde la sección "Cadenas de consulta" en "Recomendaciones":

Dentro de la cadena de consulta, el signo más se reserva como notación abreviada para un espacio. Por lo tanto, los signos más reales deben estar codificados. Este método se utilizó para hacer que los URI de consulta fueran más fáciles de pasar en sistemas que no permitían espacios.

De acuerdo con la sección 3.4 de RFC2396 que es la especificación oficial sobre los URI en general, el componente de "consulta" depende de la URL:

3.4. Componente de consulta El componente de consulta es una cadena de información para ser interpretada por el recurso.

 query = *uric

Dentro de un componente de consulta, los caracteres ";", "/", "?", ":", "@", "&", "=", "+", "," Y "$" están reservados.

Por lo tanto, es un error en el otro software si no acepta las URL con espacios en la cadena de consulta codificados como " + " caracteres.

En cuanto a la tercera parte de su pregunta, una forma (aunque ligeramente desagradable) de corregir la salida de URLEncoder.encode() es call replaceAll("//+","%20") en el valor de retorno.