urlencode - online - ¿Cuándo codificar el espacio a más(+) o% 20?
urlencode php (5)
Cual es la diferencia: ver otras respuestas.
Cuando se usa + lugar de %20 ? Utilice + si, por alguna razón, desea que la cadena de consulta de URL ( ?..... ) o el fragmento de hash ( #.... ) sea más legible. Ejemplo: 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í)
Pensaría que es poco probable que + rompa algo, ya que Google usa + (vea el primer enlace arriba) y probablemente hayan pensado en esto. Voy a usar + yo solo porque legible + Google piensa que está bien.
A veces, los espacios obtienen la URL codificada en el signo + , otras veces en %20 . ¿Cuál es la diferencia y por qué debería suceder esto?
Es mejor siempre codificar espacios como% 20, no como "+".
Era RFC-1866 (especificación HTML 2.0), que especificaba que los caracteres de espacio deberían codificarse como "+" en "pares de clave-valor de tipo de contenido de application / x-www-form-urlencoded". (Ver párrafo 8.2.1. subpárrafo 1.). Esta forma de codificar datos de formularios también se proporciona en las especificaciones HTML posteriores, busque los párrafos relevantes sobre application / x-www-form-urlencoded.
Este es un ejemplo de una cadena de este tipo en la URL donde RFC-1866 permite codificar espacios como ventajas: "http://example.com/over/there?name=foo+bar". Entonces, solo después de "?", Los espacios pueden ser reemplazados por ventajas, de acuerdo con RFC-1866. En otros casos, los espacios deben estar codificados a% 20. Pero como es difícil determinar el contexto, es la mejor práctica nunca codificar espacios como "+".
Recomendaría codificar en porcentaje todos los caracteres excepto "sin reservas" definido en RFC-3986, p.2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Por lo tanto, 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 codificar espacios. Si solo utiliza esta especificación, un espacio debe codificarse como ''% 20''.
La mención de usar ''+'' para codificar espacios proviene de varias 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 utiliza para publicar datos de formulario.
Ahora, la especificación HTML 2.0 (RFC1866) dijo explícitamente, en la sección 8.2.2, que la parte de la consulta de la cadena de 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 de ''?'').
Pero ... ¿de 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 siguen definiendo ''+'' como legal en el contenido de ''application / x-www-form-urlencoded'', omiten completamente la parte que dice que las cadenas de consulta de solicitud GET se definen como ese tipo. De hecho, no hay mención alguna sobre la codificación de la cadena de consulta en nada después de la especificación 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 un montón de código que también lo genera. Así que las probabilidades son buenas que no se romperá si usa ''+''. (Y, de hecho, hice toda la investigación sobre esto recientemente porque descubrí un sitio importante que no aceptó ''% 20'' en una consulta GET como un espacio. En realidad, no pudieron decodificar CUALQUIER carácter codificado en porcentaje. 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 transferido a versiones posteriores, las URL están cubiertas por completo por RFC3986, lo que significa que los espacios deben convertirse a ''% 20''. Y definitivamente ese debería ser el caso si está solicitando algo que no sea un documento HTML.
http://www.example.com/some/path/to/resource?param1=value1
La parte antes del signo de interrogación debe usar% de codificación (por lo tanto, %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 .
+ significa un espacio solo en la application/x-www-form-urlencoded contenido, 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 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. Entonces, si necesita codificar una cadena para incluirla en parte de una URL, siempre es seguro reemplazar los espacios con %20 y las ventajas con %2B . Esto es lo que por ejemplo. 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