Decodificar URL

Un `+` en un query string casi siempre significa espacio, porque así lo escribe un formulario HTML. En una ruta no: ahí es un carácter más, literal. La misma cadena, por tanto, se lee de dos maneras según de qué parte de la URL venga.

La consecuencia que muerde son los valores con un más real dentro: números de teléfono en formato internacional y correos con subdirección. Un `[email protected]` leído con la regla de formulario se convierte en `a [email protected]`, y el fallo aparece en la entrega, donde ya nadie relaciona la causa.

Cada `%` seguido de dos dígitos hexadecimales es un byte, y los caracteres fuera de ASCII ocupan varios: `%C3%B1` es una eñe, `%C3%A1` es una á, y un emoji son cuatro secuencias seguidas. Decodificar consiste en juntar los bytes y luego leerlos como UTF-8.

Por eso una secuencia suelta puede ser inválida aunque los dígitos sean correctos. Un `%F1` a secas era una eñe en Latin-1 y no es UTF-8 válido; aquí se dice en lugar de devolver un símbolo de sustitución que parecería el resultado. Ver esa secuencia es la pista de que el valor lo generó una herramienta anterior a UTF-8.

Si después de decodificar todavía quedan secuencias de porcentaje, la cadena estaba codificada dos veces. Es el resultado correcto: una pasada convierte `%2520` en `%20`, y una herramienta que siguiera decodificando hasta que no quedara nada destruiría los valores que contienen un `%` de verdad.

La solución no es pasarla dos veces por aquí de forma rutinaria, sino encontrar en tu cadena de procesamiento la etapa que codifica algo ya codificado — casi siempre un framework que lo hace por ti y una plantilla que lo repite.

Si decodificas una dirección completa, los `%2F` se convierten en barras y los `%3F` en interrogantes, y el resultado deja de tener la misma estructura: lo que era un valor pasa a parecer una ruta o un query string nuevo.

Eso es útil para leer y peligroso para reutilizar. Una redirección abierta se construye exactamente así — el atacante mete una URL codificada como valor y algo la decodifica antes de comprobarla. La regla es decodificar para mirar y validar siempre la forma original.

Si estás leyendo una URL de un registro de servidor, todo lo que iba después de `#` no está ahí: el navegador no lo envía nunca. La dirección que ves está incompleta por diseño, y eso explica más de un caso en el que un parámetro «desaparece» entre lo que la usuaria tenía y lo que consta.

En una exportación de analítica sí puede aparecer, porque ahí lo escribe un script que sí lo ve. Saber de qué fuente viene la cadena que estás mirando cambia lo que se puede concluir de ella, y es el tipo de detalle que ahorra una hora de confusión.

Términos de búsqueda, destinos de redirección, correos, tokens de confirmación y parámetros UTM. Los tres primeros son datos personales con bastante frecuencia, y el cuarto es una credencial de un solo uso.

Que estén codificados no los protege de nada: la codificación de porcentaje es legible para cualquiera, y esa cadena está en el registro del servidor, en el historial del navegador y en la cabecera de referrer del siguiente clic. Si aquí te sale algo que parece un secreto, ese es el hallazgo — no que se haya podido decodificar.

`utm_source`, `utm_medium`, `utm_campaign`, `utm_term` y `utm_content` vienen de Urchin, la herramienta de la que salió Google Analytics. No hacen nada en el servidor: son texto que lee un script de medición en el navegador.

Como no hacen nada, se pueden quitar sin consecuencias al reenviar un enlace, si no quieres mezclar la estadística de quien te lo mandó con tu reenvío. Y como van en la dirección, acaban en historiales, en enlaces compartidos y en marcadores — la razón por la que algunos enlaces de newsletter son absurdamente largos.

Aquí se decodifica y no se visita. No hay petición al host, no hay resolución de redirecciones y no hay previsualización, y es una decisión: quien está examinando una URL sospechosa es el último que quiere que la herramienta la abra.

Abrirla además delataría algo. La petición saldría de un servidor, su IP y la hora quedarían en el registro del otro lado, y con una dirección de un solo uso — un enlace de confirmación, un restablecimiento de contraseña — la gastaría por el camino.

Las URLs de registros y de exportaciones de analítica llevan con frecuencia datos personales: términos de búsqueda, correos como parámetro, identificadores que se asocian a una cuenta. Como aquí se decodifica en la página, nada de eso se nos comunica.

Es lo que hace posible mirar esa clase de exportación con una herramienta online. Un servicio que decodificara en remoto habría recibido la línea y la tendría en sus registros — exactamente el supuesto que la mayoría de las políticas internas existen para impedir.