Herramientas de desarrollo · Codificador y decodificador de URL
RFC 3986 caracteres reservados y no reservados: lo que dice el estándar URI
· Antecedentes
codificación de URL rfc3986 codificación porcentual
RFC 3986 divide los caracteres en reservados, no reservados y todo lo demás, y esa división explica cada regla de codificación porcentual que ha cumplido. Esta publicación lee las secciones relevantes claramente.
RFC 3986 caracteres reservados y no reservados: lo que importa al crear URL
RFC 3986 divide los caracteres en tres categorías: no reservados, reservados y todo lo demás que debe codificarse. Los caracteres no reservados nunca necesitan codificación: son letras, dígitos, guión, punto, guión bajo y tilde. El RFC los enumera explícitamente en la sección 2.3, indicando que es seguro dejarlos sin codificar en cualquier contexto de URI. Las pruebas en el codificador y decodificador de URL con estos caracteres muestran que pasan sin cambios. Los caracteres reservados se subdividen en gen-delims (: /? # [ ] @) y sub-delims (! $ & ' ( ) * + , ; =), cada uno con un significado estructural en diferentes componentes de URL.
¿Cuándo es necesario codificar un carácter? Los caracteres reservados deben codificarse en porcentaje sólo cuando creen ambigüedad. Una barra diagonal marca los segmentos del camino; en un valor de consulta debe ser %2F. Un signo y separa los parámetros; & en un valor requiere %26. Los caracteres no reservados nunca necesitan codificación: un guión permanece como guión. El estándar de URL garantiza un análisis correcto. Pruebas con codificador y decodificador de URL: ingresar "hello/world" con encodeURIComponent produce "hello%2Fworld"; con encodeURI conserva la barra diagonal.
Sin reserva: letras, dígitos, guión, punto, guión bajo y tilde: los caracteres que nunca necesitan codificación y que nunca deben codificarse
La codificación porcentual utiliza %HH, donde HH es notación hexadecimal. La letra ASCII A (código 65) se convierte en %41. é no ASCII requiere codificación UTF-8: é (U+00E9) se convierte en %C3%A9. Los estándares modernos especifican UTF-8 de manera uniforme en todos los navegadores.
Las URL completas deben tener la sintaxis estructural intacta; Los valores de consulta necesitan caracteres internos reservados que sean inofensivos. El parámetro de consulta ?q=R&D debe codificar & como %26 si es manual; de lo contrario, el signo comercial se convierte en separador. Los valores con barras diagonales se convierten en %2F en el modo de componente. La codificación de componentes (encodeURIComponent) maneja esto codificando todo excepto letras, dígitos y - _ no reservados. ! ~*'( ). Las pruebas muestran claramente la diferencia entre los métodos.
Reservado: gen-delims y sub-delims: los dos grupos, sus miembros y sus roles estructurales
Las cadenas de consulta demuestran por qué son importantes los caracteres reservados. El signo comercial separa los pares clave=valor: ?utm_source=email&utm_campaign=sale significa dos parámetros. Dentro de un valor, el signo comercial sin escape finaliza el par. Igual separa las claves de los valores. El análisis se produce en varias capas; cada uno aplica las mismas reglas.
Los caracteres que requieren codificación en los valores de consulta incluyen ampersand, igual, almohadilla, signo de interrogación, espacios y letras que no son ASCII. El hash es el más astuto: #anything se convierte en un identificador de fragmento, nunca se envía al servidor. Los nombres de campaña que terminan con hash pierden todo lo que sigue antes de que la solicitud abandone el navegador. Los espacios deben convertirse en %20. Las pruebas con codificador y decodificador de URL muestran los modos de componente y formulario. Comprender la posición determina la necesidad de codificación.
Cuándo se deben codificar los caracteres reservados, solo cuando se puedan confundir con un delimitador, componente por componente
La codificación porcentual persiste en RFC 3986. El conjunto no reservado permanece pequeño, lo que garantiza la portabilidad. Los caracteres no reservados codificados por porcentaje se pueden decodificar sin cambio de significado. La decodificación de %41 a A es correcta porque A no está reservado. Decodificar %2F a / cambia el significado cuando la barra diagonal es datos, no separador. La sección de normalización del RFC 3986 6 cubre enfoques sintácticos.
Los personajes reservados en diferentes posiciones tienen diferentes roles. Los dos puntos en el esquema marcan el esquema: límite de autoridad; Los dos puntos en la información del usuario son datos. El signo de interrogación abre la sección de consulta; La barra diagonal en el valor de la consulta es literal. Inicio del fragmento de marcas hash. La posición determina la necesidad de codificación. Las cadenas de consulta contienen valores que son en sí mismos URI. Codificar una URL de redireccionamiento como https://example.com/page?param=value como parámetro requiere codificar barras y dos puntos en %2F y %3A. El contexto siempre define caracteres seguros.
Ejemplo resuelto: clasificar cada carácter de una URL real: no reservado, reservado como delimitador, reservado como datos
RFC 1738 (1994) consideró que muchos caracteres no eran seguros. A medida que las implementaciones se estandarizaron el UTF-8, los estándares posteriores relajaron las restricciones. La tilde (~) ejemplifica la evolución: RFC 1738 requiere %7E, RFC 2396 (1998) movió la tilde a sin reserva, RFC 3986 confirmó el estado sin reserva. La evolución refleja las lecciones de implementación. Los estándares preservan la compatibilidad con versiones anteriores.
La normalización RFC permite decodificar caracteres no reservados codificados por porcentaje innecesariamente. %41 se normaliza de forma segura a A. Los caracteres reservados codificados como %2F nunca se decodifican; el cambio de significado rompe la estructura. El consenso moderno utiliza RFC 3986 como base de referencia. El codificador y descodificador de URL sigue RFC 3986 en todo momento y ofrece una referencia fija independiente del comportamiento del navegador. WHATWG URL Standard agrega conjuntos de codificación específicos de componentes más allá de RFC. Coexisten estándares: RFC 3986 para análisis general de URL, WHATWG para navegadores web. Las bibliotecas difieren; consultar documentación.
Guía de normalización en la sección 6: mayúsculas y minúsculas, decodificación sin reservas y reglas de segmento de ruta
Las pruebas contra RFC 3986 garantizan que las URL funcionen en software que abarca décadas. El codificador y decodificador de URL proporciona la línea base de codificación RFC 3986 para aplicar a los componentes construidos. Lea la documentación estándar que explica cada decisión de codificación en las bibliotecas de URL. WHATWG URL se basa en RFC 3986 en lugar de reemplazarlo por completo. ¿Crear URL para navegadores generales? Siga RFC 3986; Los navegadores aplican reglas WHATWG en la parte superior. ¿Sistemas más antiguos? Pruebe implementaciones reales. ¿Normalizando para el almacenamiento? Aplique RFC 3986 de manera consistente. Comprender la distinción reservada/unreserved le indica los caracteres seguros.
La codificación de URL no es un saneamiento de seguridad. Cada contexto (SQL, HTML, JavaScript, URI) necesita su propia codificación de salida. La codificación porcentual protege únicamente la estructura de la URL. Aplicar defensa derecha en la capa derecha.
Lo que esto no cubre: los diferentes conjuntos de codificación y el manejo de IRI del estándar WHATWG URL
RFC 2396 (1998) aclaró los conjuntos de caracteres de manera más rigurosa que RFC 1738. Formalizó los caracteres reservados que sirven a la estructura URI y los no reservados como datos literales. Ampliado sin reservas que incluye guión, punto, guión bajo y tilde sobre las definiciones originales. RFC 2396 introdujo la distinción entre gen-delims (:, /, ?, #, [, ], @) y sub-delims (!, $, &, ', (, ), *, +, ,, ;, =). Cada grupo tiene diferentes roles estructurales en las URL. La denominación aclara que los caracteres reservados se dividen en dos grupos. Conocer los nombres ayuda en las discusiones técnicas.
RFC 3986 (2005) es una referencia moderna. Mantuvo la distinción reservada/unreserved pero simplificó la notación. Los organismos de normalización no rompen la web de forma retroactiva. Codifique deliberadamente conociendo su estándar. El codificador y descodificador de URL proporciona la referencia RFC 3986.
Conclusión: el estándar es breve y preciso: cómo los dos modos del codificador y decodificador de URL se corresponden con la codificación de datos versus la preservación de delimitadores
La elección de estándares depende del contexto. ¿Crear URL para navegadores generales? Siga RFC 3986; Los navegadores aplican las reglas WHATWG. ¿Sistemas más antiguos? Pruebe implementaciones reales. ¿Normalizando para el almacenamiento? Aplique RFC 3986 de manera consistente. Las reglas de codificación porcentual evolucionaron desde el RFC conservador 1738 hasta el RFC 2396 y RFC 3986 clarificados hasta el estándar de URL WHATWG en capas. Cada generación reflejó la experiencia. Los constructores modernos siguen RFC 3986 o WHATWG contextualmente. Las URL antiguas y nuevas coexisten, lo que requiere pensar en compatibilidad. Comprender las categorías evita errores de codificación.
Verifique que las URL se codifiquen correctamente antes de la implementación. El codificador y decodificador de URL demuestra las reglas RFC 3986 de un extremo a otro. Vea valores hexadecimales exactos y comprenda qué caracteres codifican. Utilice esta herramienta al crear URL concatenando piezas. RFC 3986 categorías reservadas y no reservadas dividen conjuntos de caracteres para un análisis de URI coherente.