Codificación de espacios en URL: ¿%20 o signo más?

Un espacio en los datos de una URL suele convertirse en %20, pero la serialización de consultas con formato de formulario lo representa como +. Ambas opciones pueden ser correctas. La salida adecuada depende del destino: utilice codificación porcentual para un componente URI individual y la convención del signo más solo cuando el flujo receptor espere datos application/x-www-form-urlencoded.

El codificador de URL de ClockTools hace explícito ese contexto mediante los perfiles Componente URI, URL completa y Datos del formulario. Pegue green tea, cambie de perfil y compare la salida antes de modificar el código de la aplicación.

Comience con el destino

No pregunte «¿Qué símbolo significa siempre un espacio?». Pregunte qué analizador recibirá el valor.

Para un segmento de ruta, un valor de fragmento o un valor de consulta individual, la codificación porcentual es la representación fiable. El byte UTF-8 del carácter de espacio es el hexadecimal 20, por lo que su triplete de codificación porcentual es %20.

Para datos con formato de formulario HTML, la convención de serialización utiliza + para los espacios y codifica un signo más literal como %2B. El estándar de URL de WHATWG define este comportamiento de form-urlencoded por separado del análisis general de URL.

La sintaxis de URI de RFC 3986 define un octeto con codificación porcentual como % seguido de dos dígitos hexadecimales. También distingue los delimitadores reservados de los caracteres de datos no reservados. Esa distinción explica por qué codificar un valor no es lo mismo que codificar una dirección completa.

Tabla de decisión: %20 frente al signo más

La última fila evita un error habitual. Si el valor previsto es C++, enviar C++ a través de un decodificador de formularios puede producir C . Codifique cada signo más literal como %2B antes de analizar el formulario.

Cuatro pruebas reproducibles de ClockTools

Probamos cuatro entradas pequeñas con la implementación actual de la herramienta. Su perfil Componente URI utiliza JavaScript encodeURIComponent. Datos del formulario aplica la misma codificación de componentes y después sustituye %20 por +. URL completa utiliza encodeURI, que conserva la estructura de la URL.

Estos son resultados de transformaciones deterministas, no pruebas sobre el posicionamiento en buscadores. Puede reproducirlos localmente en el navegador. La página actualiza la salida inmediatamente, informa de las secuencias de escape porcentuales y del número de bytes, y no necesita enviar la entrada a un servidor para realizar la conversión.

Utilice el decodificador de URL para realizar la comprobación inversa. Decodifique green%20tea con el perfil de componentes y green+tea con Datos del formulario. El decodificador advierte cuando aparece un signo más en un perfil que no es de formulario, porque su significado previsto es ambiguo.

¿Qué protege la codificación de componentes?

Una URL utiliza signos de puntuación como gramática. En una cadena de consulta, & puede iniciar otro parámetro y = separa un nombre de un valor. # inicia un fragmento. ? inicia una consulta. Si uno de esos caracteres forma parte de los datos del usuario, dejarlo sin codificar puede alterar la estructura.

Considere el valor timer & alarm. La codificación de componentes produce timer%20%26%20alarm. El signo & se convierte en %26, por lo que un analizador recibe un único valor en lugar de interpretar alarm como un parámetro nuevo.

La codificación es una representación, no una validación ni un cifrado. Una redirección con codificación porcentual puede seguir apuntando a un host no autorizado después de decodificarla. Un script codificado sigue siendo una entrada no fiable. Valide los esquemas, los hosts, los nombres de parámetros y las reglas de negocio permitidos después del análisis. Evite incluir contraseñas, tokens u otros secretos en las URL, porque las direcciones pueden aparecer en el historial, los registros, las herramientas de analítica, las capturas de pantalla y los datos de referencia.

Cuando necesite comparar una cadena de consulta antes y después de una modificación, el comprobador de diferencias de texto mostrará cada secuencia de escape modificada. Es más fiable que buscar a simple vista un único %25 que falta en una URL de retorno larga.

¿Por qué la doble codificación crea %2520?

La doble codificación ocurre cuando el texto ya codificado se trata como datos sin procesar y se codifica nuevamente.

Comience con un espacio:

space -> %20

Codifique %20 como un componente nuevo. El signo de porcentaje se convierte en %25, mientras que los dígitos permanecen literales:

%20 -> %2520

Una decodificación devuelve %2520 a %20. Una segunda decodificación convierte %20 en un espacio. Si su aplicación espera una sola decodificación pero recibe un valor codificado dos veces, el usuario puede ver %20 en lugar de un espacio en blanco.

La solución no consiste en decodificar repetidamente hasta que el texto parezca correcto. La decodificación repetida puede alterar delimitadores codificados deliberadamente y crear problemas de seguridad. Identifique qué capa es responsable: exactamente una debe codificar el componente y una capa correspondiente debe decodificarlo.

Cómo depurar discrepancias en la codificación de espacios

Siga estos pasos cuando un sistema envíe %20 y otro muestre +, %2520 o un espacio en blanco literal.

1. Capture el valor sin procesar antes de que lo modifique cualquier analizador del framework.
2. Identifique si el campo es un segmento de ruta, un componente de consulta, una URL completa o un cuerpo de formulario.
3. Registre el valor decodificado esperado, incluidos los signos más literales.
4. Reproduzca la misma entrada en el perfil ClockTools correspondiente.
5. Decodifique una sola vez con el perfil receptor.
6. Compare el resultado con el valor esperado.
7. Busque un segundo codificador o decodificador en el flujo de la aplicación si %25 aparece de forma inesperada.

Esta ruta de depuración es intencionalmente estrecha. Separa el contexto de los datos de las conjeturas y cada paso tiene una entrada y una salida visibles.

¿Cuándo debería codificar una URL completa?

Utilice el perfil URL completa solo cuando quiera que la dirección siga siendo una dirección. Conserva los signos estructurales, como los dos puntos del esquema, las barras, el signo de interrogación, el signo igual, el signo & y el marcador de fragmento, mientras codifica caracteres como los espacios.

Utilice Componente URI cuando una URL completa esté anidada dentro de otro parámetro. Por ejemplo, una dirección de retorno situada en redirect= es un dato desde la perspectiva de la URL externa. Codificar la dirección anidada como un único componente impide que su ? y su & se incorporen a la consulta externa.

No pase repetidamente una dirección por distintos perfiles esperando obtener una cadena universalmente segura. Especifique el límite de forma explícita:

outer URL structure + encodeURIComponent(inner callback URL)

La aplicación receptora debe analizar la URL externa, extraer el componente de retorno, decodificarlo una sola vez, analizar la URL interna resultante y validar el destino. La codificación mantiene intacta la sintaxis; la validación determina si el destino está permitido.