Herramientas de desarrollo · Codificador y decodificador de URL
Codificación de URL doble: cómo sucede %2520 y cómo detectarlo y deshacerlo
· Cómo funciona
codificación de URL javascript flujo de trabajo del desarrollador depuración
Un %2520 en una URL significa que un espacio se codificó dos veces. Esta publicación explica los errores de canalización que lo causan, cómo reconocer la firma y cuántos pases de decodificación son seguros.
Codificación de URL doble: cuando %2520 significa que un espacio pasó por dos codificadores
Que un nombre de archivo llegue como "my%20file.pdf" en vez de "my file.pdf" indica una doble codificación: el espacio se convirtió en %20 y luego el signo de porcentaje en %25, produciendo %2520 en la URL final. Cada capa —código cliente, framework web o proxy inverso— puede codificar una vez; si dos capas lo hacen, el carácter queda alterado.
La codificación doble aparece con mayor frecuencia en cadenas de redireccionamiento complejas y sistemas de plantillas. Un desarrollador puede generar una URL codificada dentro de un marco que a su vez codifica todos los resultados de forma predeterminada. Un proxy inverso o una red de entrega de contenido puede volver a codificar las URL que ya llegaron codificadas desde el sistema backend. Un parámetro que contiene un valor ya codificado se codifica nuevamente antes de anidarse dentro de otra estructura de URL.
Por qué %25 es la indicación: el signo de porcentaje en sí se codifica, por lo que %20 se convierte en %2520 y %C3%A9 se convierte en %25C3%25A9
El signo revelador de doble codificación es que %25 aparece donde normalmente se esperaría ver un signo de porcentaje único en la URL o los datos. En una URL normalmente codificada, nunca verá %25 a menos que envíe el literal "%25". Si un espacio codificado como %20 se codifica nuevamente, se convierte en %2520.
Un carácter acentuado como é, que normalmente codifica %C3%A9, se convierte en %25C3%25A9 cuando se codifica dos veces mediante dos sistemas diferentes en secuencia. Aprender a detectar el patrón %25 en barras de URL, registros y mensajes de error ahorra innumerables horas de frustrante trabajo de depuración en entornos de producción donde los datos fluyen a través de múltiples servicios.
Donde se introduce la codificación doble: código de cliente más marco, redireccionamientos, servidores proxy y ayudas de plantilla
La doble codificación destruye la legibilidad y la capacidad del servidor para interpretar correctamente la URL. Un archivo llamado "my file.pdf" se convierte en "my%20file.pdf" al codificarse bien. Si esa cadena se vuelve a codificar —por ejemplo, mediante un formulario— pasa a ser "my%2520file.pdf".
Cuando el servidor lo recibe y lo decodifica una vez, ve "my%20file.pdf" como nombre literal en lugar de reconocer "my file.pdf". Las aplicaciones que esperan una sola decodificación obtendrán un resultado alterado. Peor aún, decodificar dos veces valores codificados solo una vez corrompe los datos legítimos.
Ejemplo resuelto: decodificar una URL doblemente codificada paso a paso: qué revela cada paso y cuándo detenerse
El código JavaScript del lado del cliente y los valores predeterminados del marco del lado del servidor son las fuentes más comunes de doble codificación accidental en los sistemas de producción. Una aplicación JavaScript puede usar encodeURIComponent en un valor y luego pasarlo directamente a un marco que codifica toda la salida de cadenas de forma predeterminada, codificando así el signo de porcentaje por segunda vez. Una capa de proxy inverso destinada a desinfectar las URL podría volver a codificar parámetros que ya vienen precodificados desde la aplicación backend.
Una URL de redireccionamiento creada mediante la concatenación de entradas proporcionadas por el usuario con una función auxiliar del marco puede codificar en ambos pasos simultáneamente. Ejemplo resuelto: un usuario envía "prueba y valor" a través de un formulario HTML, el navegador lo codifica como "prueba%26valor". El marco ve el porcentaje literal de texto y lo codifica, produciendo "test%2526value". Una decodificación da "valor de prueba% 26", todavía incorrecto.
Cuando se delibera la doble codificación: una URL incluida dentro del parámetro de consulta de otra URL
La doble codificación deliberada es válida en un caso específico: cuando una URL debe viajar dentro del parámetro de consulta de otra URL. Los flujos de OAuth y los enlaces de retorno de inicio de sesión a veces requieren anidar una URL completa dentro de otra. Primero, la URL interna debe codificarse completamente en porcentaje y luego toda la cadena codificada debe codificarse nuevamente como valor de parámetro para la URL externa.
Esta doble codificación es deliberada y absolutamente necesaria en estos casos. El analizador de parámetros externos se decodifica una vez y genera la URL interna aún codificada. Luego, el sistema interno vuelve a decodificar, recuperando la URL original. La clave fundamental es comprender la intención y documentarla claramente en comentarios de código para futuros mantenedores.
Errores comunes: decodificar hasta que nada cambie, lo que corrompe los valores que contienen legítimamente %25
El error clásico y peligroso es decodificar repetidamente hasta que nada cambie, lo que corromperá los valores que legítimamente contienen signos de porcentaje en los datos reales. Un parámetro como "discount%2525" (que representa un literal "%25" codificado como valor de parámetro y luego codificado nuevamente para transporte) es completamente correcto por diseño. Decodificarlo una vez produce "descuento%25", que sigue siendo correcto. Decodificarlo por segunda vez produce "% de descuento", lo cual es incorrecto y pierde información.
Un desarrollador podría asumir que "%25" es un error y decodificarlo repetidamente, perdiendo el signo de porcentaje. En su lugar, decodifique exactamente tantas veces como lo requiera su arquitectura: una vez para un parámetro, dos veces anidado. Cuente capas para conocer las operaciones de decodificación correctas.
Lo que esto no cubre: codificación de entidad HTML superpuesta a las URL, que maneja el escape de entidad HTML
Los errores comunes incluyen codificar una URL completa con encodeURIComponent y luego esperar que las barras y los dos puntos funcionen como delimitadores estructurales, algo que no pueden hacer después de la codificación. Otro error frecuente es mezclar diferentes estándares de codificación: algunos códigos usan codificación porcentual según RFC 3986 y otros códigos usan codificación de formularios con signos más que representan espacios. Un valor como "mi+archivo" se vuelve genuinamente ambiguo: podría significar "mi archivo" o podría significar el texto literal "mi+archivo" con un signo más.
Si la codificación porcentual toca "mi+archivo" primero, se convierte en "mi%2Barchivo". Si sigue la decodificación de formas, esperando más como espacio, sigue siendo incorrecto. La coherencia entre capas es esencial. Cada sistema debe utilizar el mismo estándar de codificación o cada capa debe estar documentada explícitamente.
Conclusión: codifique exactamente una vez por capa: cómo el codificador y decodificador de URL le permite decodificar un paso a la vez y ver cada resultado intermedio
Una vez que haya identificado con éxito la doble codificación que se produce en los sistemas de producción, la solución depende completamente de dónde se produce la duplicación en el proceso. Si tanto el código del cliente como un marco están codificados, elimine completamente la codificación de uno de ellos. Si un parámetro viaja a través de varios servicios backend, rastree la ruta completa a través de cada servicio y encuentre qué servicio está codificando cuando no debería hacerlo.
Pruebe la solución a fondo pasando datos de muestra a través del proceso completo de un extremo a otro y verifique que los datos lleguen sin cambios al destino. Documente claramente la suposición de codificación en cada límite: "este punto final devuelve parámetros codificados en porcentaje" o "este middleware espera UTF-8 sin procesar y le aplica codificación". Incluya la cantidad de pases de decodificación esperados en esa documentación para futuros desarrolladores.