Codificador/Decodificador de URL

Codificador/decodificador URL gratuito con encodeURIComponent vs encodeURI y modo RFC 3986 estricto para OAuth y AWS SigV4. Decodifica conservando el + literal.

¿Tienes comentarios? Reporta errores, sugiere funciones o comparte tus ideas — leemos todos

Codificador/Decodificador de URL - Codificar y Decodificar URLs Online

Una potente herramienta online de codificación y decodificación de URL que le ayuda a codificar texto para uso seguro en URLs o decodificar cadenas URL codificadas de vuelta a texto plano. Con manejo automático de caracteres especiales, espacios, Unicode y varias opciones de codificación. Esencial para desarrolladores web que trabajan con parámetros de consulta, endpoints de API, datos de formularios y manipulación de URL.

¿Por qué la codificación URL convierte un espacio en %20?

Las URLs originalmente estaban restringidas a un pequeño conjunto de caracteres ASCII por RFC 1738 (1994) y luego RFC 3986 (2005), excluyendo los espacios porque rompen los analizadores que delimitan componentes con espacios en blanco. Cualquier carácter que no esté en el conjunto no reservado (A-Z, a-z, 0-9, y -._~) debe codificarse como porcentaje: el byte se escribe como % seguido de su valor hexadecimal de dos dígitos. Un espacio es el byte 0x20, de ahí %20. En el formato más antiguo application/x-www-form-urlencoded usado por formularios HTML, un espacio puede codificarse como +. Ambas formas se decodifican a espacio, pero no son intercambiables en todos los contextos: en la cadena de consulta, + comúnmente significa espacio, pero en la ruta o el fragmento, + significa un + literal.

¿Cuál es la diferencia entre encodeURI y encodeURIComponent?

Estas dos funciones de JavaScript codifican conjuntos de caracteres diferentes porque tienen distintos alcances. encodeURI asume que estás pasando una URL completa y preserva los caracteres con significado estructural: : / ? # [ ] @ ! $ & ' ( ) * + , ; = ~ permanecen tal cual. encodeURIComponent asume que estás pasando un valor de un solo componente (un segmento de ruta, un valor de consulta, un fragmento) que debe poder incrustarse dentro de una URL sin romper la sintaxis, por lo que escapa también todos esos caracteres estructurales. Regla práctica: construye el esqueleto de la URL con encodeURI, pero siempre envuelve cada valor proporcionado por el usuario con encodeURIComponent antes de concatenar. Usar encodeURI para valores de consulta es la causa más común de enlaces de búsqueda y rastreo rotos.

¿Por qué encodeURIComponent no escapa ! * ' ( ) y cómo lo hago estricto según RFC 3986?

encodeURIComponent de JavaScript se implementó según la especificación RFC 2396 más antigua, que clasificaba ! * ' ( ) como marcas que no requerían escape. RFC 3986 los reclasificó como sub-delims reservados en algunos contextos. Para cumplir completamente con RFC 3986, postprocesa el resultado tú mismo: encodeURIComponent(str).replace(/[!*'()]/g, c => '%' + c.charCodeAt(0).toString(16).toUpperCase()). Esto importa cuando se generan firmas OAuth 1.0a (la especificación exige codificación estricta), al construir solicitudes canónicas de AWS Signature V4, o al interoperar con bibliotecas estrictas del lado del servidor. Para enlaces web típicos, la función incorporada de JavaScript está bien. Esta herramienta ofrece un modo estricto que escapa el conjunto reservado completo según RFC 3986 sección 2.2.

¿Qué método de codificación debo elegir: Componente, URL Completa o RFC 3986 Estricto?

Ajuste el método a lo que está construyendo:

Componente (encodeURIComponent) — el predeterminado. Úselo para UN ÚNICO valor que insertará en una URL: el valor de un parámetro de consulta, un segmento de ruta, un campo de formulario o cualquier entrada del usuario. Escapa los caracteres estructurales : / ? # & = + para que no rompan la URL circundante. Ejemplo: el término de búsqueda "café & té" se convierte en caf%C3%A9%20%26%20t%C3%A9 para que el & no se lea como separador de parámetros.

URL Completa (encodeURI) — úselo sobre una URL COMPLETA ya ensamblada, cuando solo desea corregir espacios y caracteres no ASCII manteniendo intacta la estructura. Deja intactos : / ? # & =. Ejemplo: https://ejemplo.com/ruta?q=hola mundo se convierte en https://ejemplo.com/ruta?q=hola%20mundo. Nunca lo use sobre un valor de consulta aislado: su & sobreviviría y corrompería la consulta.

RFC 3986 Estricto — Componente más el escape de ! * ' ( ), que la función integrada de JavaScript omite. Úselo cuando una firma o forma canónica dependa de una codificación byte a byte: las cadenas base de firma OAuth 1.0a y las solicitudes canónicas de AWS Signature V4 lo exigen. Codificar de menos aquí produce una firma inválida y una solicitud rechazada, aunque el mismo valor funcionaría como un enlace normal.

Regla práctica: construya el esqueleto con URL Completa, codifique cada valor insertado con Componente y cambie a Estricto solo al firmar solicitudes.

¿Cómo se codifican caracteres no ASCII como chino, vietnamita o emoji?

Según RFC 3986 sección 2.5 (y las especificaciones IRI anteriores en RFC 3987), el texto no ASCII en URLs primero debe convertirse a bytes UTF-8 y luego codificar cada byte como porcentaje. El carácter "é" son dos bytes en UTF-8 (C3 A9), por lo que se convierte en %C3%A9: dos escapes porcentuales, no uno. El emoji "🎉" son cuatro bytes UTF-8 (F0 9F 8E 89) y se convierte en %F0%9F%8E%89: cuatro escapes. Los sistemas antiguos a veces usaban Latin-1 o Windows-1252 y producían %E9 para é, que un decodificador UTF-8 moderno malinterpretará. Si ves ? o caracteres de reemplazo después de decodificar, la fuente probablemente usó una codificación de bytes no UTF-8. Esta herramienta siempre codifica y decodifica como UTF-8.

Codificador/Decodificador de URL — Codificador/decodificador URL gratuito con encodeURIComponent vs encodeURI y modo RFC 3986 estricto para OAuth y AWS Sig — **Codificador/Decodificador de URL**

¿Qué caracteres nunca necesitan codificarse en una URL?

RFC 3986 define el conjunto no reservado: A-Z mayúsculas, a-z minúsculas, dígitos 0-9, y las cuatro marcas - . _ ~. Estos 66 caracteres están garantizados de significar lo mismo en cada componente de URL y nunca requieren codificación. Los caracteres reservados se dividen en dos grupos: gen-delims (: / ? # [ ] @) que separan componentes de URL y deben codificarse dentro de un valor de componente, y sub-delims (! $ & ' ( ) * + , ; =) que tienen significado especial dentro de ciertos componentes. Si los sub-delims necesitan codificación depende del contexto: = y & son críticos dentro de cadenas de consulta pero inofensivos dentro de un segmento de ruta. Atajo seguro: codifica todo lo que esté fuera del conjunto no reservado.

¿Por qué la decodificación a veces deja un %25 literal en mi cadena?

Porque el propio % debe codificarse como %25 para distinguirlo de la secuencia de escape porcentual. Si tu cadena contenía un signo de porcentaje literal que se codificó correctamente una vez como %25, un solo paso de decodificación lo convierte de nuevo en %. Pero si la cadena se codificó dos veces (codificada una vez al almacenarla, codificada de nuevo al concatenarla en otra URL), una sola decodificación deja %25 en su lugar, lo que luego parece un escape extraviado. La doble codificación es común en pipelines donde una URL se pasa como parámetro de consulta a otro servicio: cada salto agrega otra capa. La cura es decodificar exactamente una vez por salto de codificación, nunca más, nunca menos.

¿Los fragmentos de URL (la parte después de #) se codifican igual que la ruta o la consulta?

Principalmente, pero con dos diferencias clave. RFC 3986 sección 3.5 define el alfabeto del fragmento como pchar / "/" / "?", lo que permite / y ? sin escapar dentro del fragmento sin ambigüedad (no hay más delimitadores después de #). Esto significa que encodeURIComponent escapará en exceso estos caracteres en fragmentos, produciendo %2F y %3F donde las formas sin escapar son legales. Además, el fragmento nunca se envía al servidor en solicitudes HTTP (es puramente del lado del cliente), por lo que los decodificadores del lado del servidor pueden nunca verlo. Al construir fragmentos de enlace profundo para SPAs que contienen JSON o rutas, el sobre-escape de encodeURIComponent suele estar bien. Esta herramienta expone un modo consciente del fragmento.

¿Cuál es la longitud máxima de una URL, y qué pasa si la excedo?

No hay límite estricto en las especificaciones HTTP o URL: RFC 7230 recomienda explícitamente que los servidores admitan "una línea de solicitud de al menos 8000 octetos". En la práctica, los navegadores, servidores e intermediarios imponen sus propios límites. Chrome acepta hasta 32 KB en la barra de direcciones pero trunca más allá de 2 MB internamente. Apache predetermina 8 KB (LimitRequestLine), Nginx 8 KB (large_client_header_buffers), e IIS 16 KB. AWS API Gateway limita a 8 KB. Más allá del límite del salto más bajo, obtienes un error 414 URI Too Long. Para datos de más de unos pocos cientos de bytes, cambia a un cuerpo POST o fragmenta los datos en múltiples solicitudes. Mantén las URLs por debajo de 2 KB para portabilidad.