Inspector de codificación porcentual

La codificación porcentual — también llamada codificación de URL, y en documentos antiguos escapado — es la regla que permite que una URL lleve caracteres que no tiene permiso para contener. Un escape porcentual son tres caracteres ASCII: un signo de porcentaje y dos dígitos hexadecimales, que representan un byte. %20 es el byte 0x20, que es un espacio. %2F es el byte 0x2F, que es una barra. No interviene nada más: el escape nombra un byte, no un carácter.

Como nombra bytes, primero hay que convertir el texto en bytes, y la codificación de bytes es UTF-8. De ahí vienen los escapes largos: un carácter chino son tres bytes UTF-8 y, por tanto, tres escapes, y un emoji son cuatro bytes y doce caracteres ASCII.

Un URI se define como una secuencia de caracteres ASCII (RFC 3986, sección 2.1), y dentro de ese rango ASCII algunos caracteres son reservados: son los signos de puntuación que dan estructura a la URL. Dos puntos y dos barras separan el esquema, una arroba separa la información de usuario del host, una interrogación empieza la consulta, una almohadilla empieza el fragmento, un ampersand separa los parámetros de consulta, y un signo de porcentaje introduce un escape.

Eso crea un problema y una laguna. El problema: un valor que contiene en sí uno de esos caracteres — un cuadro de búsqueda con «a&b», un nombre de archivo con una barra, una contraseña con dos puntos — cambiaría la estructura de la URL en la que viaja. La laguna: el propio signo de porcentaje, así que el codificador puede simplemente ampliar su propio alfabeto. % se escribe como %25, y los dos dígitos hexadecimales que siguen son caracteres no reservados normales.

Estas son las salidas exactas de los tres codificadores que ejecuta esta página, con entradas elegidas porque se comportan de forma distinta entre sí. La página las recalcula delante de usted, y su Autocomprobación vuelve a verificar cada fila contra las implementaciones propias de la plataforma.

La versión corta que evita la mayoría de los errores: todo lo que vaya a un único valor de parámetro pasa por encodeURIComponent (o por un serializador de formularios, que hace el mismo trabajo con un conjunto seguro distinto), y una URL completa ya ensamblada pasa por encodeURI si necesita escaparse en absoluto. Elegir el incorrecto de esos dos es el error de codificación porcentual más habitual en código web.

Un espacio es el único carácter cuya codificación depende de adónde va el texto, y el signo más es la razón.

La trampa está en medio de esa tabla. En datos de formulario un signo más significa un espacio, así que un valor que contiene de verdad un signo más — un número de teléfono escrito como +44 20 7946 0958, una expresión aritmética, una dirección de correo con una etiqueta con más — tiene que viajar como %2B. Si viaja como signo más literal, el receptor lo lee como espacio, y +44 llega como « 44».

Una doble codificación ocurre cuando una cadena ya está escapada y después se vuelve a escapar. El signo de porcentaje del primer escape es un carácter más, así que se convierte en %25, y la capa de debajo sobrevive como texto visible.

Reconocerlo es cuestión de contar: decodifique la cadena una vez y mire el resultado. Si todavía contiene escapes que parecen deliberados — un %XX válido o un signo más de formulario donde se espera un espacio — hay otra capa. Si contiene %25 seguido de dos dígitos hexadecimales, la capa siguiente es seguramente un escape.

Dos notas prácticas. Primero, decodificar dos veces no es inofensivo: es una forma conocida de conseguir que un filtro de seguridad y el código que hay detrás vean cadenas distintas, así que un filtro que se ejecuta antes de una segunda decodificación filtra el texto equivocado. Segundo, el recuento de capas de aquí es una propiedad de la cadena, no una promesa sobre la intención: un valor legítimo puede tener una sola capa de profundidad, y uno roto puede tener dos.

• Un valor codificado con encodeURI. Los separadores sobreviven, así que un valor que contiene & o = se parte en varios parámetros al otro lado. Compare las dos columnas de arriba de esta página con la entrada a&b=c: la columna de componente escapa los dos caracteres, la columna de encodeURI los mantiene.
• Un signo más literal enviado como datos de formulario. Llega como espacio. Use %2B.
• Un valor escapado dos veces «para estar seguro». No es más seguro. El receptor decodifica una vez y obtiene una cadena que todavía contiene escapes porcentuales, que es el mismo fallo que un juego de caracteres incorrecto, una capa más abajo.
• Decodificar lo que nunca se codificó. Un signo de porcentaje literal en un texto — 100% seguro — no es un escape. En una lectura estricta es uno roto, en la posición que informa esta página; en una lectura permisiva sobrevive, por eso permisiva es el valor predeterminado aquí y no al revés.
• Suponer que el escape debe ir en mayúsculas. La decodificación trata %2f y %2F como el mismo byte, y ambos son válidos. Las mayúsculas son solo la grafía canónica que recomienda la RFC 3986, y la que producirán otras herramientas.
• Suponer que la codificación porcentual hace seguro el texto. Lo hace inequívoco dentro de una URL. No detiene la inyección, no es cifrado y no es un sanitizador: el escape tiene que ser el último paso antes del ensamblado, para el contexto en el que va a entrar el texto.

«¿Es un signo más un espacio en una URL?»

Solo en datos de formulario, y solo en la parte de consulta de un envío de formulario. En una ruta, en un fragmento y en la consulta de un enlace normal, un signo más es un signo más literal. Por eso esta página tiene un interruptor para ello en lugar de adivinar.

«¿Por qué mi enlace muestra %25?»

Porque algo codificó un signo de porcentaje. O bien un signo de porcentaje literal pasó por un codificador — 100% seguro se convierte en 100%25%20seguro — o bien una cadena que ya contenía un escape se codificó por segunda vez. Decodifique la cadena una vez y mire lo que sale: si el resultado todavía contiene %XX, hay otra capa.

«¿Importa que una barra dentro de un valor de consulta sea %2F o /?»

Para el analizador de URL, no: ambas llegan al servidor como una barra, y el conjunto de consulta de WHATWG deja la barra tal cual. Para la interoperabilidad, a veces sí: muchos frameworks de servidor ejecutan su propia decodificación sobre una cadena de consulta sin procesar, y algunos no se ponen de acuerdo sobre caracteres que nunca se escaparon. Cuando un valor se ensambla a mano en lugar de con un serializador, escapar explícitamente los caracteres reservados es el hábito más seguro.

«¿Por qué la columna de formulario escapa una tilde que las otras dos dejan tal cual?»

Porque el conjunto seguro del codificador de formularios es más estrecho: solo letras, dígitos y -_.*. El codificador de formularios de WHATWG escapa ~ ! ' ( ) aunque la RFC 3986 incluye ~ entre los no reservados. Ambas grafías se decodifican al mismo valor; la diferencia solo importa cuando se comparan cadenas byte a byte.

«¿Pueden aparecer los mismos caracteres sin escapar en la barra de direcciones del navegador?»

Sí, y eso es la barra de direcciones, no la URL. Los navegadores muestran una forma legible de la URL y la codifican al enviarla, así que 中文 en un enlace se convierte en %E4%B8%AD%E6%96%87 en la red. Si copia la URL desde la barra de direcciones puede obtener cualquiera de las dos formas según el navegador.

«Todos los escapes de aquí parecen válidos, pero el carácter que sale no es el que esperaba. ¿Por qué?»

Hay dos fallos distintos detrás de «se decodificó mal», y la página los informa de forma diferente. El primero es un escape roto: un signo de porcentaje que no va seguido de dos dígitos hexadecimales, como un 100% al final o un %zz. Es un problema de sintaxis, y la lectura estricta lo rechaza y dice dónde está, mientras que la lectura permisiva lo conserva como texto literal y lo enumera. El segundo es un escape cuyo byte es perfectamente legal pero cuyos bytes no forman un carácter UTF-8 válido, como un %FF suelto o un carácter de tres bytes cortado como %E4%B8. Eso no es un problema de sintaxis, así que ambas lecturas devuelven el texto, sustituyen los bytes que no se pueden decodificar por el carácter de reemplazo U+FFFD («�») y muestran una advertencia que lo indica. Esa advertencia es la parte útil: un texto que llega con caracteres de reemplazo suele significar que el remitente usó otro juego de caracteres, o que la cadena se escapó una vez de más. La codificación porcentual nombra bytes, y esta página, como el estándar de URL, siempre lee esos bytes como UTF-8.

«¿Qué no hace esta página?»

No divide una URL en esquema, host, ruta y consulta — para eso está el Analizador de URL. No comprueba si un enlace es seguro de abrir, no contacta con nada, y no adivina el juego de caracteres de los bytes que hay detrás de un escape: siempre los lee como UTF-8, que es lo que exige el estándar de URL.

«¿Qué alternativa necesita la decodificación, y cómo sé que es correcta?»

Pulse Autocomprobación. Compara los codificadores propios de la página con encodeURIComponent, encodeURI y URLSearchParams de la plataforma para cada carácter ASCII imprimible, vuelve a ejecutar cada ejemplo de las tablas de arriba, vuelve a comprobar las cadenas de capas registradas, y después informa del número de comprobaciones aquí.

La codificación porcentual está especificada en la RFC 3986, sección 2.1, con la definición de caracteres reservados y no reservados en las secciones 2.2 y 2.3, y la regla de mayúsculas en la sección 6.2.2.1. Los conjuntos que usa realmente un navegador al construir una URL están en el Estándar URL de WHATWG, que los divide por contexto: un conjunto para el fragmento, otro para la consulta, otro para la consulta especial, otro para la ruta, otro para la información de usuario, y el más estrecho para un componente individual. El envío de formularios, incluido el signo más, está en el Estándar HTML bajo application/x-www-form-urlencoded. Las dos funciones encodeURI y encodeURIComponent forman parte del propio ECMAScript.

Esta página rellena las columnas de ruta, consulta y fragmento a partir de sus propios conjuntos por contexto, e imprime la lista exacta de cada contexto junto al resultado. Esos conjuntos derivan de los de WHATWG y difieren de ellos en dos puntos deliberados: un hash se escapa dentro de una consulta, porque un hash sin escapar empezaría el fragmento, y el conjunto de componentes se fija exactamente a los caracteres que escapa encodeURIComponent. Cuando una función de la plataforma es la definición de la respuesta — encodeURIComponent, encodeURI y la serialización de formularios — esa función se llama directamente, así que esas columnas son el comportamiento propio del navegador y no una reimplementación.

El texto de la página se escribió para este sitio. Cada valor de las tablas de arriba lo produce el propio código de la página al cargarse, y se verificó contra las implementaciones de la plataforma con las herramientas de prueba de este sitio; la Autocomprobación repite esa comparación en su navegador.