¿Cuándo codificar el espacio a más (+) o% 20?

Algunas veces, los espacios reciben la URL codificada en el signo + , otras veces en %20 . ¿Cuál es la diferencia y por qué debería suceder esto?

+ significa un espacio solo en application/x-www-form-urlencoded content, como la parte de consulta de una URL:

 http://www.example.com/path/foo+bar/path?query+name=query+value 

En esta URL, el nombre del parámetro es el nombre de la query name con un espacio y el valor es el valor de la query value con un espacio, pero el nombre de la carpeta en la ruta es literalmente foo+bar , no foo bar .

%20 es una forma válida de codificar un espacio en cualquiera de estos contextos. Por lo tanto, si necesita codificar URL para incluir una cadena en parte de una URL, siempre es seguro reemplazar espacios con %20 y más con %2B . Esto es lo que ej. encodeURIComponent() hace en JavaScript. Desafortunadamente, no es lo que hace urlencode en PHP ( rawurlencode es más seguro).

Consulte también HTML 4.01 Aplicación de especificación / x-www-form-urlencoded

http://www.example.com/some/path/to/resource?param1=value1

La parte anterior al signo de interrogación debe usar% de encoding (así que %20 para el espacio), después del signo de interrogación puede usar %20 o + para un espacio. Si necesita un + real después del signo de interrogación, use %2B .

Entonces, las respuestas aquí son un poco incompletas. El uso de un ‘% 20’ para codificar un espacio en URL se define explícitamente en RFC3986 , que define cómo se construye un URI. No se menciona en esta especificación el uso de un ‘+’ para espacios de encoding; si solo se utiliza esta especificación, un espacio debe codificarse como ‘% 20’.

La mención de usar ‘+’ para espacios de encoding proviene de las diversas encarnaciones de la especificación HTML, específicamente en la sección que describe el tipo de contenido ‘application / x-www-form-urlencoded’. Esto se usa para publicar datos de formulario.

Ahora, la especificación HTML 2.0 (RFC1866) dice explícitamente, en la sección 8.2.2, que la parte de consulta de una cadena URL de una solicitud GET debe codificarse como ‘application / x-www-form-urlencoded’. Esto, en teoría, sugiere que es legal usar un ‘+’ en la URL en la cadena de consulta (después del ‘?’).

Pero … ¿verdad? Recuerde, HTML es en sí mismo una especificación de contenido, y las URL con cadenas de consulta se pueden usar con contenido que no sea HTML. Además, mientras que las versiones posteriores de la especificación HTML continúan definiendo ‘+’ como legal en el contenido ‘application / x-www-form-urlencoded’, omiten por completo la parte que indica que las cadenas de consulta de solicitud GET se definen como ese tipo. De hecho, no se menciona en absoluto la encoding de cadena de consulta en nada después de la especificación de HTML 2.0.

Lo que nos deja con la pregunta: ¿es válida? Ciertamente, hay MUCHO código heredado que admite ‘+’ en cadenas de consulta, y una gran cantidad de código que también lo genera. Entonces, las probabilidades son buenas, no se romperá si usa ‘+’. (Y, de hecho, hice toda la investigación sobre esto recientemente porque descubrí un sitio principal que no aceptaba ‘% 20’ en una consulta GET como espacio. De hecho, no lograron decodificar CUALQUIER carácter porcentual codificado. el uso puede ser relevante también).

Pero a partir de una lectura pura de las especificaciones, sin el lenguaje de la especificación HTML 2.0 trasladado a versiones posteriores, las URL están cubiertas completamente por RFC3986, lo que significa que los espacios deben convertirse a ‘% 20’. Y definitivamente ese debería ser el caso si está solicitando algo más que un documento HTML.

Es mejor codificar siempre los espacios como% 20, no como “+”.

Era RFC-1866 (especificación HTML 2.0), que especificaba que los caracteres espaciales deberían codificarse como “+” en los pares clave-valor de tipo de contenido “application / x-www-form-urlencoded”. (ver párrafo 8.2.1, subpárrafo 1.). Esta forma de codificar los datos del formulario también se proporciona en las especificaciones HTML posteriores, busque los párrafos relevantes sobre application / x-www-form-urlencoded.

Aquí hay un ejemplo de una cadena en URL donde RFC-1866 permite espacios de encoding como ventajas: “http://example.com/over/there?name=foo+bar”. Entonces, solo después de “?”, Los espacios pueden ser reemplazados por más, de acuerdo con RFC-1866. En otros casos, los espacios deben codificarse en% 20. Pero dado que es difícil determinar el contexto, la mejor práctica es nunca codificar espacios como “+”.

Recomendaría codificar porcentualmente todos los caracteres excepto “sin reserva” definido en RFC-3986, p.2.3

 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 

¿Cuál es la diferencia? Ver otras respuestas.

¿Cuándo usar + lugar de %20 ? Use + si, por algún motivo, desea hacer que la cadena de consulta de URL ( ?..... ) o el fragmento de hash ( #.... ) sean más legibles. Ejemplo: realmente puedes leer esto:

https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces ( %2B = +)

Pero lo siguiente es mucho más difícil de leer: (al menos para mí)

https://www.google.se/#q=google%20doesn%27t%20oops%20:%20%20this%20text%20%2B%20is%20different%20spaces

Creo que es poco probable que + se rompa nada, ya que Google usa + (ver el primer enlace arriba) y probablemente hayan pensado en esto. Voy a usar + yo solo porque es legible + Google cree que está bien.