Herramientas de desarrollo · Codificador y decodificador de URL
Del RFC 1738 al estándar de URL: cómo han evolucionado las reglas de codificación porcentual
· Antecedentes
codificación de URL historial-rfc estándares web
Las reglas para los caracteres de escape en las URL se han reescrito varias veces desde 1994. Esta publicación sigue RFC 1738, RFC 2396, RFC 3986 y el estándar de URL WHATWG y explica qué cambió cada vez.
Del RFC 1738 al estándar de URL: cómo evolucionaron las reglas de codificación porcentual
Tilde (~) ejemplifica cómo las reglas de codificación cambian entre generaciones e implementaciones de estándares. RFC 1738 (1994) requería %7E en todas partes; RFC 2396 (1998) movió la tilde a sin reservar permitiendo no codificar. RFC 3986 (2005) confirmó el estado sin reservas. Las URL antiguas con %7E siguen siendo válidas; Salida de nuevos constructores ~. La evolución refleja las lecciones de implementación a medida que la web maduró y la infraestructura se estandarizó. RFC 1738 fue conservador porque la infraestructura inicial era heterogénea y variada.
RFC 1738 codificó el comportamiento del navegador 1994. Implementaciones estandarizadas el UTF-8; las restricciones resultaron innecesarias. Los estándares posteriores relajaron las restricciones de carácter. RFC 3986 permite la decodificación segura de caracteres no reservados.
RFC 1738 (1994): personajes 'inseguros' y las primeras reglas de escape: qué se consideraba peligroso y por qué
RFC 1738 definió caracteres "inseguros" como aquellos que entran en conflicto con la sintaxis de URI (espacio, barra diagonal), utilizados históricamente en protocolos (caracteres de control) o que los sistemas no podían transmitir de forma segura. Lista conservadora codificada en porcentajes mucho más de lo necesario para la Internet moderna. Muchos de los primeros sistemas son anteriores a RFC; codificó su comportamiento. Los personajes de control eran realmente peligrosos en los protocolos; Los espacios eran problemas de transmisión para los clientes HTTP que leían desde líneas de comando. Los sistemas modernos manejan estos casos de manera más elegante mediante codificación explícita.
Las pruebas contra RFC 1738 revelan lo que esperaban los sistemas antiguos. Codifique un carácter de la especificación de URL de la década de 1990 y compárelo con el RFC moderno 3986. Las diferencias muestran lo que se relajó. El conjunto no reservado se expandió con el tiempo. El guión, el punto y el guión bajo siempre estuvieron a salvo. Tilde necesitaba RFC 2396 para estar a salvo. El enfoque conservador significaba compatibilidad con versiones anteriores. Las URL antiguas creadas según las reglas RFC 1738 siguen siendo válidas en la actualidad. La normalización en la sección 6 del RFC 3986 permite decodificar de forma segura caracteres no reservados innecesariamente codificados por porcentaje.
RFC 2396 (1998) — reservado versus no reservado, la sintaxis genérica y la tilde rehabilitada
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 de URI en lugar de los no reservados como datos literales. Ampliado sin reservas que incluye guión, punto, guión bajo y tilde. Reconoció la sintaxis genérica de URI separada de las reglas específicas del esquema. RFC 2396 introdujo la distinción entre gen-delims (:, /, ?, #, [, ], @) y sub-delims (!, $, &, ', (, ), *, +, ,, ;, =). La denominación aclara que los personajes reservados se dividen en dos grupos con diferentes roles estructurales.
RFC 2396 introdujo una guía de normalización que especifica qué caracteres codificados porcentualmente se podían decodificar sin cambio de significado. Se normaliza la decodificación de caracteres no reservados. Sticks de codificación de caracteres reservados. RFC 3986 simplificó aún más la notación. Los estándares mantienen ferozmente la compatibilidad con versiones anteriores.
RFC 3986 (2005) — ! * ' ( ) se mueve a sub-delims, se nombran gen-delims y llega la guía de normalización
RFC 3986 (2005) es un estándar de referencia moderno para codificación porcentual. Mantuvo la distinción reservada/unreserved pero simplificó la notación y agregó orientación de normalización. Tilde se movió claramente y sin reservas. Los caracteres no reservados codificados por porcentaje y clarificados estándar se pueden decodificar sin cambio de significado. La sección 3 del RFC 3986 describe la sintaxis de URI con precisión. La sección 2 define categorías de caracteres. La sección 6 dedica reglas formales a la normalización sintáctica. La normalización basada en comparaciones considera que los URI son idénticos si las formas normalizadas coinciden. La eliminación de segmentos de puntos de las rutas se normaliza sin cambiar el significado.
La normalización es importante para análisis, almacenamiento en caché y seguimiento de enlaces. Las URL que difieren solo en mayúsculas y minúsculas (RFC 3986 prefiere mayúsculas) deberían ser idénticas en la práctica. La normalización evita entradas de registro duplicadas y errores de caché. Los cachés codificados en URL normalizadas ofrecen contenido independientemente de la preferencia de codificación del solicitante. La guía de normalización RFC 3986 permite a los sistemas tomar decisiones coherentes. Pero una aplicación estricta impide que las URL funcionen bien en la Internet actual.
El estándar de URL WHATWG: análisis de lo que los navegadores realmente reciben: conjuntos de codificación, esquemas especiales y tolerancia a errores
WHATWG URL Standard (2016–presente) surgió de la experiencia del navegador con URL que no seguían perfectamente el RFC 3986. Los navegadores se enfrentaban a espacios no codificados, codificaciones mixtas y peculiaridades. WHATWG describe el análisis real del navegador, no la gramática teórica. Los navegadores del mundo real habían desarrollado reglas prácticas para tolerar espacios, manejar caracteres escapados y recuperarse de entradas con formato incorrecto. RFC 3986 llegó a 2005 y definió la gramática formal, pero los navegadores en la práctica ya habían divergido ligeramente.
WHATWG define nueve conjuntos de codificación con reglas específicas del contexto. Space in path becomes %20; slash in userinfo becomes %2F. Browser applies narrower standard for web. RFC 3986 provides baseline; WHATWG se basa en ello.
Ejemplo resuelto: una URL con una tilde, un espacio y un carácter no ASCII: cómo la codifica cada generación de reglas
Los dominios internacionalizados utilizan codificación punycode (München se convierte en xn--mnchen-3ya). Las rutas y consultas todavía usan percent-encoding. La parte del dominio utiliza punycode; Las partes de ruta y consulta utilizan percent-encoding. Las capas no se mezclan ni interfieren.
IDNA (Nombres de dominio internacionalizados en aplicaciones) resuelve el problema del nombre de host. Punycode codifica no ASCII en ASCII para compatibilidad con DNS. El prefijo xn-- indica codificación punycode. El algoritmo es determinista: münchen siempre se convierte en xn--mnchen-3ya. Los caracteres que no son ASCII deben convertirse antes de la resolución DNS. La codificación porcentual no funciona para nombres de host debido a restricciones de DNS y límites de etiquetas. Cada enfoque resuelve correctamente un problema diferente. Los estándares evolucionaron por separado por buenas razones.
Lo que esto no cubre: IRI y nombres de dominio internacionalizados, que tienen su propia historia.
La elección de estándares depende del contexto. ¿Crear URL para navegadores? Siga RFC 3986; Los navegadores aplican WHATWG. ¿Sistemas más antiguos? Implementaciones de prueba. Comprender la evolución evita la confusión.
Los constructores modernos deben seguir RFC 3986 o WHATWG contextualmente. Las URL antiguas y nuevas coexisten, lo que requiere un análisis cuidadoso de la compatibilidad. El codificador y descodificador de URL sigue el RFC 3986 en todo momento y ofrece una referencia fija independiente del comportamiento del navegador. WHATWG agrega conjuntos de codificación específicos de componentes más allá de los conceptos básicos de RFC. Saber qué cambió y cuándo ayuda a comprender por qué los sistemas no están de acuerdo. Probar su URL con ambos estándares revela qué estándar controla en su entorno. Ambos estándares son correctos.
Conclusión: conozca qué libro de reglas sigue su código: cómo el codificador y descodificador de URL le proporciona el comportamiento RFC 3986 como punto de referencia fijo La normalización
RFC 3986 permite decodificar de forma segura caracteres no reservados codificados por porcentaje innecesariamente. %41 se normaliza a A. Los caracteres reservados codificados como %2F nunca se decodifican; el cambio de significado rompe la estructura. Los organismos de normalización mantienen fervientemente la compatibilidad con versiones anteriores. La solución requeriría una coordinación mundial imposible después de décadas. Los libros de estándares no rompen la web de manera retroactiva. Cambiar las decisiones de codificación rompe miles de millones de sistemas existentes simultáneamente.
La codificación porcentual abarca tres décadas de cuidadosa evolución: desde RFC 1738 pasando por RFC 2396 y RFC 3986 hasta el moderno estándar de URL WHATWG. El código moderno debe seguir la línea base RFC 3986. Las URL antiguas con codificación anterior siguen siendo válidas. Las pruebas de ida y vuelta garantizan la corrección y la compatibilidad.