Explicación de la codificación de URL: por qué los espacios se convierten en %20

Lo has visto en direcciones web: %20 donde debería estar un espacio, o %3D en lugar de un signo igual. Eso es codificación de URL (también llamada codificación porcentual) y, aunque parezca un galimatías, resuelve un problema real que mantiene la web funcionando. Esto es lo que está pasando.

Por qué las URL necesitan codificación

Las URL solo pueden contener de forma segura un conjunto limitado de caracteres: letras, dígitos y algunos símbolos. Muchos caracteres tienen un significado especial (? inicia una cadena de consulta, & separa parámetros, / separa segmentos de ruta) o no están permitidos en absoluto (espacios). Si coloca esos caracteres en una URL tal como están, los navegadores y los servidores se confunden. La codificación los reemplaza con una representación segura.

Cómo funciona

La codificación porcentual reemplaza un carácter no seguro con un % seguido de su valor de byte hexadecimal de dos dígitos. Un espacio es el byte 32, que es 20 en hexadecimal; por lo tanto, %20. Un signo igual se convierte en %3D, un signo %26, etc. Codifique o decodifique cualquier cadena al instante con nuestro codificador de URL y decodificador de URL.

Un ejemplo práctico

Supongamos que desea una URL de búsqueda para "café y bar". El espacio y el signo deben estar codificados:

https://example.com/search?q=caf%C3%A9%20%26%20bar

Aviso que "é" se convirtió en %C3%A9: los caracteres que no son ASCII se codifican como sus bytes UTF-8, que pueden tener más de un par porcentual. La referencia de codificación porcentual de MDN cubre los detalles.

Donde importa

• Parámetros de consulta: la entrada del usuario en la búsqueda y en los formularios debe codificarse para que los caracteres especiales no interrumpan la URL.
• API: pasar valores en una URL requiere codificación para seguir siendo válido.
• Enlaces con seguimiento: las URL de campaña suelen contener valores codificados.

Errores comunes

Dos grandes: doble codificación (codificar una cadena ya codificada, convirtiendo %20 en %2520) y olvidarse de codificar la entrada del usuario, lo que puede romper enlaces o abrir agujeros de seguridad. En caso de duda, decodifica una URL para comprobar lo que realmente contiene.

Caracteres reservados y no reservados

No todos los caracteres necesitan codificación. El estándar define caracteres no reservados: letras, dígitos y - _ . ~: que siempre están seguros tal como están. ¿Caracteres reservados como /? # & = tienen un significado estructural especial en una URL, por lo que deben codificarse cuando se usan como datos en lugar de como separadores. Este es el quid de la razón por la que se codifica la entrada del usuario: un término de búsqueda que contenga "&" debe convertirse en %26, o "&" se interpretaría erróneamente como el inicio de un nuevo parámetro.

Los signos más y la confusión espacial

Un problema clásico: en la cadena de consulta de envíos de formularios más antiguos, a veces un espacio se codifica como + en lugar de %20, porque así es como históricamente funcionaban los datos del formulario HTML (el formato application/x-www-form-urlencoded). En la ruta de una URL, un espacio siempre es %20 y un literal + significa un plus. Esta división es la razón por la que el mismo "espacio" puede aparecer de dos maneras y por la que decodificar el contexto incorrecto puede dañar los datos. En caso de duda, decodifica e inspecciona.

Codificación y seguridad

La codificación adecuada no se trata solo de enlaces válidos: es un límite de seguridad. No codificar (o validar) la entrada del usuario que termina en una URL puede permitir ataques de inyección y redirecciones rotas. Los marcos suelen proporcionar funciones de codificación integradas; Úselos en lugar de hacerlos manualmente y nunca confíe en la entrada sin formato del usuario en una URL. La codificación correcta mantiene tus enlaces válidos y tu aplicación más segura.

Conclusión

La codificación de URL intercambia caracteres no seguros por un % más su valor de byte hexadecimal, por lo que las URL siguen siendo válidas sin importar lo que contengan. Los espacios se convierten en %20, los símbolos especiales obtienen sus propios códigos y los caracteres que no son ASCII usan sus bytes UTF-8. Codifique la entrada del usuario, evite la doble codificación y utilice una herramienta para comprobarlo, y esos crípticos signos de porcentaje dejarán de ser un misterio.