Codificación de porcentaje

La codificación de porcentaje (también llamada codificación de URL) es el mecanismo que usan las URL para representar caracteres que no son legales en la gramática de URL, o que tienen significados reservados. Definida en RFC 3986 §2.

El esquema: cada byte a escapar se escribe como % seguido de dos dígitos hexadecimales que representan el valor del byte. El espacio se convierte en %20. El signo de interrogación se convierte en %3F. La barra diagonal se convierte en %2F. El símbolo de almohadilla se convierte en %23.

Para los caracteres no ASCII (umlauts, acentos, CJK, emoji), el carácter se codifica primero en UTF-8 a una secuencia de bytes, y luego cada byte se codifica en porcentaje. El único carácter “é” (U+00E9) se convierte en los bytes 0xC3 0xA9 en UTF-8, codificados en porcentaje como %C3%A9.

Tres clases de caracteres que conviene conocer:

• No reservados — A-Z, a-z, 0-9 y -_.~. Nunca se escapan.
• Reservados — caracteres con significado sintáctico (:/?#[]@!$'()*+,;=). Se escapan cuando aparecen en datos que no deben analizarse como sintaxis de URL.
• Otros — todo lo demás (espacios, no ASCII, caracteres de control). Siempre se escapan.

Codifica o decodifica cualquier cadena en nuestro codificador de URL, que maneja UTF-8 correctamente (algunas implementaciones heredadas tratan las cadenas como ISO-8859-1 y producen salidas diferentes para la misma entrada).

La nota al pie del espacio como signo más: en la ruta y el fragmento de una URL, un espacio se codifica como %20. Pero en la cadena de consulta de un cuerpo application/x-www-form-urlencoded, los espacios se codifican como + — una convención específica de formularios que es anterior a la especificación moderna de URL. El encodeURIComponent() de JavaScript siempre emite %20; el antiguo escape() (obsoleto) emitía +. Para los envíos de formularios y la mayoría de las bibliotecas de URL, ambas representaciones se decodifican correctamente como un espacio, pero mezclarlos en una URL construida manualmente rompe las comprobaciones de igualdad de cadenas. El consejo moderno: usa las APIs de URL estándar (URLSearchParams de WHATWG en navegadores, url.URL en Node) y deja que la implementación elija la codificación correcta para el contexto.

La doble codificación — el error de producción más común: si un valor pasa por dos codificadores sin un decodificador intermedio, el % original del primer paso se convierte en %25, y el usuario ve algo ininteligible como %2520 en lugar de %20. La causa raíz es casi siempre una capa del sistema que asume que su entrada es texto plano cuando ya está codificada en URL. La solución es trazar un límite claro: la entrada es texto plano hasta el constructor de URL, codificada en porcentaje solo en forma de URL, decodificada de vuelta a texto plano en el momento en que sale del contexto de URL. Relacionados: UTF-8, ASCII. Referencia: RFC 3986 §2.1 — Codificación de porcentaje.

Ejemplo práctico

Codifica la consulta de búsqueda café & thé en una cadena de consulta de URL. Paso uno — UTF-8 de cada carácter: c a f é <espacio> & <espacio> t h é se convierte en los bytes 63 61 66 C3 A9 20 26 20 74 68 C3 A9. Paso dos — aplica las reglas de codificación de porcentaje: los caracteres no reservados (c a f t h) se mantienen; las secuencias UTF-8 multibyte y los caracteres reservados (&) se escapan. Resultado: caf%C3%A9%20%26%20th%C3%A9. URL completa: https://example.com/search?q=caf%C3%A9%20%26%20th%C3%A9. En el extremo receptor, el servidor decodifica invirtiendo ambos pasos: reemplaza cada %XX con su valor en bytes para obtener los bytes UTF-8, luego decodifica UTF-8 para recuperar café & thé. Si el servidor trata los bytes como Latin-1 en lugar de UTF-8, “café” aparece como “café” — el clásico mojibake.

Cuándo y por qué importa

Cada URL construida por concatenación de cadenas es un posible error de inyección o enrutamiento. Un nombre de archivo proporcionado por el usuario como ../../../etc/passwd incrustado sin procesar en una URL se convierte en un intento de path traversal; codificado en porcentaje como ..%2F..%2F..%2Fetc%2Fpasswd es seguro como un único segmento, pero puede decodificarse en la capa equivocada y reintroducir el traversal. Las consultas de búsqueda con & o # se truncan silenciosamente si no se codifican. Los frameworks HTTP modernos (Express, FastAPI, ASP.NET) manejan esto automáticamente cuando usas sus constructores de parámetros de consulta; los errores se concentran en las URL de redirección construidas manualmente, los ID de correlación de logs y los generadores de URL firmadas donde los desarrolladores concatenan cadenas. El hábito defensivo: nunca uses + para la concatenación de cadenas al construir una URL — siempre pasa por URLSearchParams o el equivalente de tu framework. Referencia: Estándar de URL WHATWG — Bytes codificados en porcentaje.