Codificador y decodificador de URL
Codificación porcentual en los tres sabores, uno al lado del otro, para que puedas ver cuál quieres.
Tres reglas, y equivocarse de regla es el error
La codificación por porcentaje sustituye un carácter por % seguido del valor de su byte en hexadecimal. Bastante simple. Lo que da problemas es que hay tres opiniones distintas sobre qué caracteres hay que sustituir, y discrepan justo en los que importan.
| Regla | Escapa / ? & = # | El espacio se vuelve | Sirve para |
|---|---|---|---|
encodeURIComponent | Sí | %20 | Un valor que va dentro de una URL |
encodeURI | No | %20 | Arreglar una URL completa |
| Codificación de formulario | Sí | + | Lo que envía un formulario HTML |
La herramienta muestra las tres a la vez precisamente por eso. Leerlas una al lado de la otra es más rápido que decidir en abstracto cuál querías.
El error que esto evita
Supón que un valor de búsqueda es coffee & cake. Codificado como componente queda coffee%20%26%20cake, y la URL es:
/search?q=coffee%20%26%20cakeUn parámetro, con el valor intacto. Codificado con encodeURI, el ampersand sobrevive tal cual:
/search?q=coffee%20&%20cakeAhora el servidor ve dos parámetros: q vale «coffee » y hay un segundo, vacío, llamado « cake». Nada da error. La búsqueda sencillamente devuelve resultados equivocados sin decir nada, y este es el tipo de fallo que sobrevive a una revisión porque la URL tiene buen aspecto.
El + que no es un más
La otra fuente fiable de confusión. En datos codificados como formulario, un + significa un espacio, y el signo más literal tiene que ser %2B. Así que descodificar C%2B%2B con la regla de formulario da C++, pero descodificar C++ da C: dos espacios, y el nombre del lenguaje ha desaparecido.
Donde más muerde es en los números de teléfono. +44 20 7946 0958 enviado por un formulario y descodificado con la regla equivocada se convierte en 44 20 7946 0958, pierde el prefijo del país, y en ningún sitio salta un error.
Qué hacer en vez de codificar a mano
En JavaScript, construye las cadenas de consulta con URLSearchParams en lugar de concatenar. Aplica la regla correcta a cada valor y maneja las claves repetidas:
const url = new URL('https://example.com/search');
url.searchParams.set('q', 'coffee & cake');
url.searchParams.set('page', '2');
// https://example.com/search?q=coffee+%26+cake&page=2Todos los demás lenguajes tienen un equivalente, y cualquiera de ellos es más fiable que decidir carácter a carácter. Esta página es para las veces en que estás leyendo una URL que te ha mandado alguien, o depurando una que ya salió mal.
Leer una URL codificada
Merece la pena reconocer unas cuantas secuencias de un vistazo, porque aparecen constantemente en los registros:
| Secuencia | Carácter | Por qué importa |
|---|---|---|
%20 | espacio | Con diferencia, la más común |
%2F | / | Una barra codificada dentro de una ruta suele ser un intento de atravesar directorios |
%3A | : | Habitual en URL codificadas dentro de parámetros de redirección |
%25 | % | La doble codificación aparece como %2520 |
%00 | nulo | Casi nunca es legítimo |
%2520 en particular conviene conocerlo: es %20 codificado una segunda vez. Suele significar que un valor ha pasado por dos capas que lo codificaron cada una, y es la firma de una cadena de redirecciones o de un proxy haciendo algo mal.
Relacionado
Para codificar bytes en lugar de escapar texto, el trabajo distinto es Base64. Si el valor descodificado resulta ser JSON, el formateador te lo leerá, y si es un token, lo hará el descodificador de JWT.
Preguntas sobre codificación
¿Cuál es la diferencia entre encodeURI y encodeURIComponent?
encodeURIComponent escapa de los caracteres que tienen significado estructural en una URL - / ? & = # : y otros, porque supone que lo que estás codificando es un valor que se ubicará dentro de una URL. encodeURI los deja en paz, porque supone que le está entregando una URL completa que necesita ser ordenada. Codificar un parámetro de consulta con encodeURI es un error común: un & dentro del valor sobrevive y divide silenciosamente su parámetro en dos.
¿Por qué un espacio a veces es %20 y otras veces +?
Ambos son correctos en su propio contexto. %20 es la codificación porcentual general para un espacio y funciona en cualquier parte de una URL. La convención + proviene de application/x-www-form-urlencoded, el formato en el que se envían los formularios HTML, donde + significa espacio y se debe escribir un signo más literal %2B. Entonces, un espacio en una ruta es %20 y un espacio en los datos del formulario enviado es +. Decodificar los datos del formulario con la regla incorrecta convierte cada signo más en el texto del usuario en un espacio.
Recibí un error de URI con formato incorrecto. ¿Qué lo causa?
Un signo de porcentaje que no va seguido de dos dígitos hexadecimales. Por lo general, es un % literal en texto que nunca se codificó; un código de descuento como "50 % de descuento" será suficiente, porque %20 se lee como una secuencia de escape y %off no es válido. Un porcentaje literal debe escribirse %25. La otra causa es la doble decodificación: ejecutar decode dos veces en algo codificado una vez finalmente alcanza un % que debía permanecer.
¿Debo codificar toda la URL o sólo los valores?
Sólo los valores, esencialmente siempre. Cree la URL estructuralmente y codifique cada parámetro a medida que lo inserte; en JavaScript, URLSearchParams hace esto por usted y es más confiable que codificar a mano. Codificar una URL completa sólo tiene sentido cuando te han entregado una que ya tiene un formato incorrecto y la estás reparando.
¿Codificar una URL la hace segura?
No. La codificación porcentual tiene que ver con la sintaxis, no con la seguridad: garantiza que un valor sobreviva al colocarse en una URL sin cambiar la estructura de la URL. No hace nada sobre dónde apunta la URL y no es una defensa contra la inyección: un valor que ha sido codificado correctamente para una URL sigue siendo peligroso si luego se inserta en HTML o SQL sin el escape apropiado para ellos.
Última revisión . ¿Has visto algo desactualizado? Dínoslo.