Codificador/Decodificador URL

La Ciencia e Historia de la Codificación Porcentual

La codificación porcentual surgió de una limitación fundamental de los primeros días de internet: la restricción ASCII. Cuando Tim Berners-Lee diseñó la sintaxis de URL en 1994, la especificación del Localizador Uniforme de Recursos (RFC 1738) restringía las direcciones web a un pequeño subconjunto de caracteres ASCII. Esto tenía sentido para el internet predominantemente en inglés de principios de los 90, pero significaba que cualquier carácter fuera de este conjunto seguro necesitaba un mecanismo de representación. La solución fue elegantemente simple: representar cada byte no seguro como un signo de porcentaje seguido de su valor hexadecimal de dos dígitos. Un espacio (valor de byte 32, hex 20) se convierte en %20, un signo de interrogación (valor de byte 63, hex 3F) se convierte en %3F. Este esquema podía representar cualquier valor de byte de 00 a FF, haciéndolo capaz de codificar cualquier carácter en cualquier conjunto de caracteres. La introducción de UTF-8 como la codificación de caracteres estándar de la web transformó la codificación porcentual de un simple esquema de mapeo de bytes a un sistema de codificación multibyte. Un único carácter chino puede requerir tres bytes en UTF-8, produciendo tres tripletes consecutivos. El signo del euro, por ejemplo, ocupa tres bytes (E2, 82, AC) y se convierte en la secuencia de seis caracteres %E2%82%AC. Por eso las URLs codificadas con texto no latino pueden parecer dramáticamente más largas. RFC 3986, publicado en 2005, refinó la especificación original de URL y formalizó las reglas modernas para la codificación porcentual. Estableció el concepto de conjuntos de caracteres reservados y no reservados, clarificando cuáles sirven como delimitadores estructurales y cuáles pueden aparecer literalmente. Esta distinción es la razón por la que existen dos funciones de codificación en JavaScript: encodeURI preserva caracteres estructurales para URLs completas, mientras que encodeURIComponent codifica todo para incrustación segura dentro de componentes URL. La especificación también introdujo el principio de normalización, definiendo cuándo dos URLs codificadas de forma diferente deben considerarse equivalentes.

Metodología

La codificación URL reemplaza caracteres ASCII no seguros con un signo de porcentaje (%) seguido de dos dígitos hexadecimales que representan el valor en bytes del carácter. Por ejemplo, un espacio se convierte en %20 (hex 20 = decimal 32), un ampersand se convierte en %26 y un signo más se convierte en %2B. La codificación sigue RFC 3986, que define el conjunto de caracteres no reservados que nunca necesitan codificación: letras mayúsculas y minúsculas (A-Z, a-z), dígitos (0-9) y cuatro caracteres especiales (guion, punto, guion bajo, tilde). Esta herramienta proporciona dos modos de codificación que se corresponden directamente con las funciones nativas de JavaScript. El modo Componente usa encodeURIComponent(), que codifica cada carácter excepto el conjunto no reservado, haciéndolo ideal para valores de parámetros de consulta donde caracteres como & y = deben escaparse. El modo URL Completa usa encodeURI(), que además preserva caracteres estructurales de URL como : / ? # [ ] @ ! $ & ' ( ) * + , ; = para que una URL completa permanezca funcional tras la codificación. Para caracteres internacionales y emojis, la herramienta primero convierte el texto a su representación de bytes UTF-8, luego codifica cada byte individualmente. Un único carácter Unicode como el signo del euro puede producir múltiples tripletes codificados (%E2%82%AC) porque UTF-8 usa codificación de longitud variable de uno a cuatro bytes por carácter.

Comprendiendo tus Resultados

Usar el modo Componente (encodeURIComponent) siempre que se codifique un valor que se colocará después de un signo igual en una cadena de consulta. Esto asegura que caracteres como &, = y # dentro del valor no rompan accidentalmente la estructura de la URL. Usar el modo URL Completa (encodeURI) cuando se tenga una URL completa y solo se quieran codificar espacios y caracteres no ASCII manteniendo intactos los delimitadores estructurales. Si aparece %25 en la salida, significa que el signo de porcentaje en sí fue codificado, lo que típicamente indica doble codificación—la entrada ya estaba codificada antes de procesarla. Decodificar tales cadenas dos veces recuperará el texto original. Este es uno de los errores de codificación URL más comunes en aplicaciones web y APIs. La decodificación es útil para hacer URLs legibles durante la depuración, analizar registros del servidor o inspeccionar parámetros de consulta que contienen valores codificados. Los nombres de dominio internacionales (IDN) usan una codificación diferente llamada Punycode en lugar de codificación porcentual, por lo que los nombres de dominio con caracteres no latinos requieren manejo separado. Codificar siempre la entrada del usuario antes de insertarla en URLs para prevenir ataques de inyección.

Ejemplos Prácticos

Parámetro de consulta de búsqueda: codificar 'coffee & tea' en modo Componente produce 'coffee%20%26%20tea', escapando de forma segura tanto los espacios como el ampersand para que el servidor reciba el texto literal. Envío de formulario: un usuario ingresa 'price=50$' en un campo de búsqueda, que debe codificarse como 'price%3D50%24' para evitar que el signo igual se interprete como separador clave-valor. URLs de redirección API: al pasar una URL de callback como 'https://app.com/auth?token=abc' como parámetro a otra URL, el modo Componente codifica todo el callback incluyendo su propia cadena de consulta, previniendo conflictos estructurales. Contenido multilingüe: codificar texto japonés produce secuencias de bytes UTF-8 como tripletes porcentuales, asegurando que los caracteres sobrevivan la transmisión. Decodificación de depuración: pegar una URL completa de registros del servidor como 'search?q=hello%20world%26lang%3Den' y decodificarla para ver instantáneamente la consulta original para solución rápida de problemas.

Consejos y Mejores Practicas

Usar siempre el modo Componente al codificar valores individuales de parámetros de consulta. El modo URL Completa deja sin codificar caracteres estructurales como & y =, lo que romperá la URL si esos caracteres aparecen en los datos mismos en lugar de como delimitadores. Evitar la doble codificación verificando si la entrada ya está codificada. Si se ven secuencias como %20 o %26 en la entrada, decodificar primero antes de recodificar para prevenir el apilamiento (donde %20 se convierte en %2520). Al construir URLs programáticamente, codificar cada valor de parámetro por separado y luego ensamblar la URL completa. Nunca codificar toda la cadena URL de una vez, ya que esto corromperá los caracteres estructurales que separan esquema, host, ruta y componentes de consulta. Para depurar llamadas API, pegar la URL codificada completa en modo decodificación para leer rápidamente todos los valores de parámetros en forma legible. Esto es especialmente útil al solucionar URLs de webhooks o redirecciones OAuth que contienen valores codificados anidados.

Codificaciones URL Comunes

Fuentes

• RFC 3986 – Sintaxis Genérica de URI
• MDN – encodeURIComponent