Codificador/Decodificador URL

La Ciencia e Historia de la Codificación Porcentual

La codificación porcentual surgio de una limitación fundamental de los primeros dias de internet: la restricción ASCII. Cuándo Tim Berners-Lee diseño la sintaxis de URL en 1994, la especificación del Localizador Uniforme de Recursos (RFC 1738) restringia las direcciones web a un pequeno subconjunto de caracteres ASCII. Esto tenia sentido para el internet predominantemente en ingles de principios de los 90, pero significaba que cualquier caracter 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 digitos. 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 podia representar cualquier valor de byte de 00 a FF, haciendolo capaz de codificar cualquier caracter en cualquier conjunto de caracteres. La introducción de UTF-8 como la codificación de caracteres estándar de la web transformo la codificación porcentual de un simple esquema de mapeo de bytes a un sistema de codificación multibyte. Un único caracter 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 dramaticamente mas largas. RFC 3986, publicado en 2005, refino la especificación original de URL y formalizo las reglas modernas para la codificación porcentual. Establecio el concepto de conjuntos de caracteres reservados y no reservados, clarificando cuales sirven como delimitadores estructurales y cuales pueden aparecer literalmente. Esta distinción es la razon 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 cuando 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 digitos hexadecimales que representan el valor en bytes del caracter. Por ejemplo, un espacio se convierte en %20 (hex 20 = decimal 32), un ampersand se convierte en %26 y un signo mas se convierte en %2B. La codificación sigue RFC 3986, que define el conjunto de caracteres no reservados que nunca necesitan codificación: letras mayusculas y minusculas (A-Z, a-z), digitos (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 caracter excepto el conjunto no reservado, haciendolo ideal para valores de parámetros de consulta donde caracteres como & y = deben escaparse. El modo URL Completa usa encodeURI(), que ademas 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 caracter Unicode como el signo del euro puede producir multiples tripletes codificados (%E2%82%AC) porque UTF-8 usa codificación de longitud variable de uno a cuatro bytes por caracter.

Comprendiendo tus Resultados

Use el modo Componente (encodeURIComponent) siempre que codifique un valor que se colocará después de un signo igual en una cadena de consulta. Esto asegura que caracteres como &, = y # dentro de su valor no rompan accidentalmente la estructura de la URL. Use el modo URL Completa (encodeURI) cuando tenga una URL completa y solo quiera codificar espacios y caracteres no ASCII manteniendo intactos los delimitadores estructurales. Si ve %25 en su 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. Codifique siempre la entrada del usuario antes de insertarla en URLs para prevenir ataques de inyección.

Ejemplos Prácticos

Parámetro de consulta de busqueda: 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. Envio de formulario: un usuario ingresa 'price=50$' en un campo de busqueda, 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 multilingue: codificar texto japones produce secuencias de bytes UTF-8 como tripletes porcentuales, asegurando que los caracteres sobrevivan la transmisión. Decodificación de depuración: pega una URL completa de registros del servidor como 'search?q=hello%20world%26lang%3Den' y decodificala para ver instantaneamente la consulta original para solución rápida de problemas.

Consejos y Mejores Practicas

Use 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á su URL si esos caracteres aparecen en los datos mismos en lugar de como delimitadores. Evite la doble codificación verificando si su entrada ya está codificada. Si ve secuencias como %20 o %26 en la entrada, decodifique primero antes de recodificar para prevenir el apilamiento (donde %20 se convierte en %2520). Al construir URLs programáticamente, codifique cada valor de parámetro por separado y luego ensamble la URL completa. Nunca codifique 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, pegue 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