Cookies de estadística y publicidad
Usamos cookies de estadística y de publicidad, y ambas van a Google. Si rechazas, para ti no cambia nada visible.Ir a la página de privacidad
Pega una cadena y recíbela escapada en porcentaje para usarla en una URL. La única decisión que importa se ofrece como elección en vez de adivinarse: si estás codificando un valor que va dentro de una dirección, o una dirección entera cuyas barras e interrogantes son estructura y tienen que sobrevivir. Quien confunde las dos cosas obtiene una URL que parece correcta y lleva a otro sitio.
Dónde se ejecuta
No se sube nada, porque no hay archivo: se calcula en esta misma página.
Sin cola y sin cuenta
Responde tan rápido como dé tu máquina, y nunca pregunta quién eres.
Tantas veces como quieras
No se cuenta nada ni se limita nada: volver a responder no nos cuesta nada.
Una URL está hecha de partes, y los caracteres que las separan — `/`, `?`, `&`, `=`, `#` — son estructura cuando cumplen esa función y datos cuando no. Codificar una dirección entera tiene que dejarlos en paz o deja de ser una dirección; codificar un valor suelto tiene que escaparlos o el valor termina y empieza otra cosa.
Esa es exactamente la diferencia entre `encodeURI` y `encodeURIComponent`, y de ahí sale la mayoría de los parámetros de redirección rotos que hay en la web: un `?volver=https://ejemplo.com/a?b=c` donde el segundo interrogante nunca se escapó, de modo que todo lo que va detrás pertenece a la URL exterior. El enlace funciona en pruebas, donde el destino no tiene query string, y falla en producción, donde sí lo tiene.
Una secuencia de porcentaje es un `%` seguido de dos dígitos hexadecimales y designa un byte. Los caracteres fuera de ASCII necesitan varias: una `ñ` es `%C3%B1` y no `%F1`, porque UTF-8 la escribe en dos bytes. Un emoji necesita cuatro secuencias.
La vieja función `escape()` producía `%F1` y está obsoleta justo por eso — es anterior a la decisión de que la web habla UTF-8. Su salida aún aparece en código antiguo y en algunas interfaces heredadas, donde decodifica al carácter equivocado en cualquier cosa que no sea un backend en Latin-1. Aquí es UTF-8 de principio a fin.
`encodeURIComponent` deja sin escapar el signo de exclamación, el apóstrofo, los dos paréntesis y el asterisco. El RFC 3986 los lista como reservados, así que un codificador estrictamente conforme sí los escapa — y ambos discrepan en cinco caracteres que aparecen constantemente en texto corriente.
Solo se nota cuando hay una firma de por medio. OAuth 1.0 y AWS Signature versión 4 calculan un hash sobre la cadena codificada, de modo que un solo apóstrofo sin escapar cambia el hash y la petición se rechaza — con un error sobre credenciales que te manda a buscar al sitio equivocado. La opción estricta de aquí escapa los cinco.
Aparecen los dos y no obedecen a la misma regla. `%20` es codificación de porcentaje y es correcta en cualquier parte de una URL. El signo más viene de `application/x-www-form-urlencoded`, el formato en el que envía un formulario HTML, donde un espacio se escribe como `+` — una convención anterior a la especificación actual que sobrevive porque los formularios lo hacen.
En una ruta, `+` es un más de verdad. En un query string, casi todos los servidores lo leen como espacio, porque así lo dice la codificación de formularios — de modo que un más real en un valor de query hay que escribirlo `%2B` o desaparece. Este codificador produce `%20`, que no es ambiguo en ninguno de los dos sitios.
Codificar una cadena ya codificada escapa el propio `%`, así que `%20` se convierte en `%2520`. Para ninguna de las piezas implicadas eso es un error — es una codificación perfectamente válida del texto literal «%20» —, y por eso la doble codificación sobrevive hasta el punto en que una usuaria ve `Hola%20mundo` en un titular.
La señal es un `%25` donde debería haber un `%`. Si ves uno, algo en la cadena está codificando un valor ya codificado, normalmente porque un framework lo hace por ti y una plantilla lo repite. La solución es quitar uno de los dos sitios, no decodificar dos veces al final.
Las letras, los dígitos y los cuatro caracteres `-`, `_`, `.` y `~` se llaman «unreserved» en el RFC 3986 y no deben escaparse jamás. Un codificador que produzca `%2E` en lugar de un punto no es más estricto: está mal, porque algunos sistemas lo normalizan de vuelta y otros no, y así dos URLs que deberían ser la misma dejan de serlo.
En la práctica: una cadena codificada con muchísimas secuencias de porcentaje cuando el texto es sobre todo letras suele venir de una herramienta que sobrecodifica. Es inofensivo hasta que alguien calcula una firma o una clave de caché sobre ella — y entonces es la razón por la que dos sistemas no se entienden.
Todo lo que va después de `#` se queda en el navegador. No aparece en ninguna petición, no llega a ningún servidor y no consta en ningún registro de acceso. Es una propiedad de HTTP, no una función de privacidad, y corta en las dos direcciones.
Es útil porque un valor en el fragmento no llega al servidor — históricamente, el motivo por el que los tokens de OAuth viajaban ahí. Es incómodo porque aun así queda en el historial del navegador, en la cadena de referrer de algunos scripts y en cualquier enlace que se comparta. «No llega al servidor» no significa «es privado».
Un dominio con eñe o con tilde no se escapa: se convierte a Punycode. `español.example` se vuelve `xn--espaol-zwa.example`, que es la forma que existe realmente en el DNS, porque el sistema de nombres solo conoce ASCII.
Un codificador que trate el host como si fuera un valor produce una dirección que ningún DNS resuelve. Por eso aquí el modo de dirección entera deja el host intacto — y por eso, si estás componiendo una URL con un dominio acentuado, la conversión del host es un paso aparte y no parte de esta operación.
Lo que se codifica suele ir a parar a una URL, y las URLs quedan en el registro del servidor, en el historial del navegador y en la cabecera de referrer del siguiente clic. Si el valor lleva un correo, un identificador o un término de búsqueda personal, ya está en varios sitios en cuanto se usa.
La parte que resuelve esta página es que la codificación ocurre en tu equipo: el valor no se nos comunica. Lo que no puede resolver es lo otro, y merece decirse aquí — el sitio más frecuente donde un dato personal acaba registrado sin querer es un parámetro de URL.
Si el texto es un valor que va dentro de una dirección, el primero: escapa ? & = / y #. Si es una dirección entera, el segundo, que los conserva porque ahí son estructura. El tercero solo hace falta cuando hay una firma de por medio.
Porque la codificación de porcentaje transporta bytes y UTF-8 escribe la ñ en dos: %C3%B1. La forma antigua %F1 venía de escape(), que está obsoleta y decodifica al carácter equivocado en cualquier sistema que no sea Latin-1.
Que se ha codificado dos veces: %20 volvió a pasar por un codificador y su % se escapó. La solución es quitar una de las dos etapas, no decodificar dos veces al final.
%20 es correcto en cualquier parte de una URL. El + solo significa espacio en un query string, por herencia de la codificación de formularios; en una ruta es un más de verdad. Aquí se produce %20, que no es ambiguo.
No. Se codifica en esta página. Ten en cuenta, eso sí, que una vez usada la URL el valor queda en registros de servidor, en el historial y en la cabecera de referrer.