URL que codifica el carácter de espacio: ¿+ o %20?
¿Cuándo se codifica un espacio en una URL +y cuándo se codifica %20?
De Wikipedia (énfasis y enlace agregados):
Cuando se envían datos ingresados en formularios HTML, los nombres y valores de los campos del formulario se codifican y se envían al servidor en un mensaje de solicitud HTTP utilizando el método GET o POST o, históricamente, por correo electrónico. La codificación utilizada de forma predeterminada se basa en una versión muy temprana de las reglas generales de codificación porcentual de URI, con una serie de modificaciones , como la normalización de nueva línea y el reemplazo de espacios con "+" en lugar de "%20". El tipo MIME de datos codificados de esta manera es application/x-www-form-urlencoded, y actualmente está definido (aún de una manera muy desactualizada) en las especificaciones HTML y XForms.
Por lo tanto, el porcentaje real%20 de codificación se utiliza , mientras que los datos del formulario en las URL están en una forma modificada que utiliza +. Por lo tanto, lo más probable es que solo veas +URL en la cadena de consulta después de un archivo ?.
Esta confusión se debe a que las URL todavía están "rotas" hasta el día de hoy.
De una publicación de blog :
Tomemos como ejemplo "http://www.google.com". 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). En realidad, las URL 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 | www.google.com | +---------------+-------------------+Si miramos una URL más compleja como por ejemplo:
"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 | www.lunatech.com | | Port | 8080 | | Path | /file;p=1 | | Path parameter | p=1 | | Query | q=2 | | Fragment | third | +-------------------+---------------------+ https://bob:[email protected]:8080/file;p=1?q=2#third \___/ \_/ \___/ \______________/ \__/\_______/ \_/ \___/ | | | | | | \_/ | | Scheme User Password Host Port Path | | Fragment \_____________________________/ | Query | Path parameter AuthorityLos personajes reservados son diferentes para cada parte.
Para las URL HTTP, un espacio en una parte del fragmento de ruta debe codificarse como "%20" (no, en absoluto, "+"), mientras que el carácter "+" en la parte del fragmento de ruta se puede dejar sin codificar.
Ahora, en la parte de consulta, los espacios pueden codificarse como "+" (para compatibilidad con versiones anteriores: no intente buscarlo en el estándar URI) o "%20", mientras que el carácter "+" (como resultado de esta ambigüedad ) debe escaparse a "%2B".
Esto significa que la cadena "azul+azul claro" debe codificarse de manera diferente en la ruta y en las partes de consulta:
"http://example.com/blue+light%20blue?blue%2Blight+blue".
A partir de ahí se puede deducir que codificar una URL completamente construida es imposible sin un conocimiento sintáctico de la estructura de la URL.
Esto se reduce a:
Deberías tener %20antes ?y +después.
Fuente
Un espacio solo puede codificarse como "+" en la parte de consulta de pares clave-valor de tipo contenido "application/x-www-form-urlencoded" de una URL. En mi opinión, esto es algo que se puede hacer , no una obligación . En el resto de URL se codifica como %20.
En mi opinión, es mejor codificar siempre los espacios como %20, no como "+", incluso en la parte de consulta de una URL, porque es la especificación HTML ( RFC 1866 ) la que especifica que los caracteres de espacio deben codificarse como "+ " en pares clave-valor de tipo contenido "application/x-www-form-urlencoded" (consulte el párrafo 8.2.1. subpárrafo 1.)
Esta forma de codificar los datos del formulario también se proporciona en especificaciones HTML posteriores. Por ejemplo, busque párrafos relevantes sobre application/x-www-form-urlencoded en la especificación HTML 4.01, etc.
Aquí hay una cadena de ejemplo en una URL donde la especificación HTML permite codificar espacios como ventajas: "http://example.com/over/there?name=foo+bar". Entonces, solo después de "?", los espacios se pueden reemplazar por signos más . En otros casos, los espacios deben codificarse en %20. Pero como es difícil determinar el contexto correctamente, la mejor práctica es no codificar nunca espacios como "+".
Recomendaría codificar porcentualmente todos los caracteres excepto "no reservado" definido en RFC 3986 , p.2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
La implementación depende del lenguaje de programación que elijas.
Si su URL contiene caracteres nacionales, primero codifíquelos en UTF-8 y luego codifique el resultado en porcentaje.
