Codificador/Decodificador URL

La codificación URL (también llamada codificación porcentual) es un mecanismo para convertir caracteres en un formato que pueda transmitirse de forma segura en una URL. Dado que las URL solo pueden contener ciertos caracteres del conjunto ASCII, otros caracteres (como caracteres acentuados, espacios y símbolos especiales) deben codificarse como %XX, donde XX es el valor hexadecimal del carácter. Por ejemplo: un espacio se codifica como %20, y el carácter ñ se codifica como %C3%B1. La codificación URL convierte caracteres en una forma segura para transmitirse dentro de URLs. Espacios, texto no ASCII, caracteres reservados y símbolos pueden percent-encoded según el contexto. Lo clave es distinguir una URL completa de un segmento de ruta, parámetro query, cuerpo de formulario o fragmento, porque cada posición tiene reglas distintas. Doble codificación o falta de codificación puede romper enlaces, APIs, firmas, redirecciones y parámetros de búsqueda.

La codificación URL (codificación porcentual) está definida por la RFC 3986 §2.1 y transforma caracteres al formato %XX, donde XX es la representación hexadecimal en mayúsculas de dos dígitos del valor del byte en UTF-8. La RFC define dos clases de caracteres: caracteres no reservados (A-Z a-z 0-9 - _ . ~) que nunca se codifican, y caracteres reservados (gen-delims : / ? # [ ] @ y sub-delims ! $ & ' ( ) * + , ; =) cuya codificación depende del contexto: tienen significado estructural en algunos componentes de la URL pero son datos literales en otros. JavaScript proporciona dos funciones integradas con alcances diferentes. encodeURIComponent() codifica cada carácter excepto A-Z a-z 0-9 - _ . ! ~ * ' ( ); esta es la elección correcta para codificar valores individuales de parámetros de consulta, segmentos de ruta e identificadores de fragmento. encodeURI() además preserva los caracteres estructurales : / ? # [ ] @ ! $ & ' ( ) * + , ; = y está diseñada para codificar URIs completas manteniendo su estructura sintáctica intacta. La distinción crítica es que encodeURIComponent() codifica / y &, lo que rompería una URL si se aplicara a toda la cadena, mientras que encodeURI() los preserva. El manejo de espacios es la trampa de interoperabilidad más común. La RFC 3986 especifica %20 como la codificación porcentual canónica para el carácter espacio (U+0020). Sin embargo, el tipo MIME application/x-www-form-urlencoded (usado por envíos de formularios HTML desde HTML 4.01) codifica espacios como +. Los dos no son intercambiables: un servidor que espera %20 interpretará + literalmente, y un servidor que espera + tratará %20 como un signo de porcentaje literal seguido de 20. La herramienta usa encodeURIComponent() que produce %20, coincidiendo con la RFC 3986. Los usuarios que decodifican payloads x-www-form-urlencoded (de cuerpos POST o cadenas de consulta analizadas por middleware heredado) deben ser conscientes de esta diferencia. El manejo de caracteres multibyte es automático pero vale la pena entenderlo: la cadena de entrada primero se codifica a bytes UTF-8, luego cada byte se codifica individualmente con percent-encoding. Un carácter CJK como '你' (U+4F60) ocupa 3 bytes UTF-8 (E4 BD A0), produciendo %E4%BD%A0. Si el servidor analiza con un juego de caracteres diferente como GBK, el mismo carácter se codifica como %C4%E3 (2 bytes), y el resultado decodificado será ilegible a menos que ambas partes acuerden UTF-8. La doble codificación es otro error común: %2520 significa un signo de porcentaje literal (%25) seguido de 20, indicando que la entrada ya estaba codificada en porcentaje y fue codificada una segunda vez. El modo de descodificación detecta secuencias mal formadas (%XX incompleto) y muestra el error en lugar de producir basura silenciosamente.

• encodeURIComponent vs encodeURI: encodeURIComponent codifica / ? & # y es correcto para valores de consulta, segmentos de ruta y fragmentos; encodeURI preserva estos caracteres estructurales y es correcto para URLs completas; usar la función incorrecta es el error de codificación URL más común.
• Juegos de caracteres reservados de la RFC 3986: gen-delims (: / ? # [ ] @) llevan sintaxis de URL; sub-delims (! $ & ' ( ) * + , ; =) pueden ser delimitadores o datos según el componente de la URL; el contexto determina si un carácter reservado se codifica en porcentaje.
• Codificación de espacios: La forma canónica de la RFC 3986 es %20 (producida por encodeURIComponent); application/x-www-form-urlencoded usa + (predeterminado de formularios HTML); los dos son semánticamente incompatibles y mezclarlos rompe los analizadores del lado del servidor.
• Codificación multibyte UTF-8: '你' (U+4F60) → bytes UTF-8 E4 BD A0 → %E4%BD%A0 (3 octetos codificados en porcentaje); el mismo carácter en GBK → %C4%E3 (2 octetos); el acuerdo de juego de caracteres entre cliente y servidor es obligatorio para texto no ASCII.
• Detección de doble codificación: %2520 se decodifica primero a %20 y luego a espacio; la salida del modo de descodificación revela este patrón; secuencias mal formadas como %ZZ o %2 (incompleto) se detectan y reportan como errores.
• IRI (RFC 3987): Los Identificadores de Recursos Internacionalizados permiten caracteres Unicode directamente en URLs; los navegadores muestran la forma decodificada en la barra de direcciones pero transmiten la forma UTF-8 codificada en porcentaje por el canal; el modo de codificación de la herramienta muestra lo que realmente se envía por HTTP.
• Manejo de errores de decodeURIComponent: Pasar una cadena con una secuencia de porcentaje incompleta (% seguido de menos de 2 dígitos hexadecimales) lanza un URIError; la herramienta envuelve la llamada en try/catch y muestra el mensaje de error en lugar de devolver silenciosamente una cadena vacía.