Herramientas de desarrollo · Codificador y decodificador de URL
WHATWG URL Standard vs RFC 3986: por qué los navegadores y las bibliotecas no están de acuerdo
· Antecedentes
codificación de URL estándares herramientas de desarrollador
Existen dos definiciones vivas de una URL y no coinciden a propósito. Esta publicación explica por qué WHATWG escribió su propio estándar, dónde los dos difieren en codificación y análisis, y cuál sigue su código.
La URL que una biblioteca estricta rechaza y el navegador carga felizmente: una cadena, dos veredictos
Su navegador puede interpretar sin problemas una cadena con una barra invertida en JavaScript como parte de la ruta URL. La misma cadena llega al backend de una biblioteca de Python y se niega a analizarla porque no se permiten barras invertidas. Una URL, dos resultados diferentes. Ninguno de los dos está mal: siguen estándares diferentes. El estándar WHATWG describe lo que realmente hacen los navegadores con las URL del mundo real, incluido cómo manejan la entrada con formato incorrecto. RFC 3986 define una gramática formal a la que idealmente deberían ajustarse las URL. Muchas bibliotecas de backend creadas sobre RFC 3986 aplican esa gramática estrictamente y rechazan cualquier cosa fuera de ella.
Esta divergencia es importante cuando mueve datos entre entornos. Una URL que los navegadores aceptan puede fallar en la validación en una herramienta de backend. Comprender qué estándar implementa su código evita la depuración de problemas fantasma: las URL funcionan bien en un lugar pero fallan misteriosamente en otro lugar sin motivo aparente.
Por qué WHATWG comenzó de nuevo: describiendo lo que realmente hacen los navegadores con entradas mal formadas en lugar de lo que es válido
El Grupo de Trabajo WHATWG se formó en 2004 para estandarizar cómo los navegadores manejan realmente las URL en la práctica, en lugar de definir reglas formales más estrictas que los navegadores no seguirían. RFC 2396 describió una especificación gramatical formal, pero en la práctica los navegadores nunca la siguieron exactamente correctamente. Los navegadores del mundo real desarrollaron reglas prácticas para tolerar espacios, manejar caracteres de escape y recuperarse de entradas con formato incorrecto que el RFC no anticipó ni esperaba.
RFC 3986 llegó a 2005 con gramática formal para URL bien formadas y requisitos estrictos. Los navegadores implementan WHATWG; Las bibliotecas de backend a menudo implementan RFC 3986.
Conjuntos de codificación versus caracteres reservados: cómo se relacionan las listas por componente del estándar de URL con las categorías del RFC 3986
RFC 3986 divide los caracteres en tres categorías: reservados, no reservados y todo lo demás que debe codificarse. Los caracteres reservados como dos puntos, barra diagonal, signo de interrogación y almohadilla tienen un significado estructural en las URL. Los caracteres no reservados son letras, dígitos, guión, guión bajo, punto y tilde; Estos siempre son seguros. Todo lo demás se codifica en porcentaje como bytes. El estándar proporciona una regla clara: saber a qué categoría pertenece tu personaje.
El estándar de URL WHATWG adopta un enfoque basado en componentes. Especifica diferentes reglas de codificación para esquema, autoridad, ruta, consulta y fragmento por separado en lugar de utilizar categorías globales. Un signo comercial puede codificarse en una ruta pero dejarse solo en una cadena de consulta. Un espacio siempre está codificado, pero la representación exacta varía según el contexto. Este diseño por componente coincide mucho mejor con el comportamiento del navegador, pero requiere saber qué parte de la URL está codificando.
Tolerancia a errores: espacios, barras invertidas y tabulaciones: ingresa un estándar que rechaza y el otro repara
Los espacios deben convertirse en %20 según ambos estándares, pero los navegadores convierten espacios literales de forma silenciosa. Ambos estándares prohíben las barras invertidas, aunque algunos navegadores las tratan como separadores de ruta. Se prohíben las tabulaciones, las nuevas líneas y los caracteres de control. WHATWG especifica un comportamiento indulgente del analizador: conviértalos o ignórelos.
Los caracteres que no son ASCII como é o 中 deben codificarse en porcentaje usando la codificación UTF-8. RFC 3986 en realidad no especifica el paso de codificación de caracteres en sí; asume que existen bytes pero no dice cómo obtenerlos del texto. El estándar WHATWG requiere explícitamente UTF-8: primero convierta la cadena en UTF-8 bytes y luego codifíquelos en porcentaje. Ambos estándares alcanzan el mismo resultado de codificación, pero parten de suposiciones subyacentes diferentes y no son explícitos sobre las mismas cosas.
Ejemplo resuelto: analizar una URL con una barra invertida y un espacio en ambos modelos: los resultados comparados
Tome la cadena de ejemplo "https://example.com/café\ búsqueda". Un navegador encuentra la barra invertida y la ve como un carácter de ruta; ve el espacio y lo codifica como %20, produciendo algo como https://example.com/café%5C%20search.. Un analizador RFC 3986 rechaza la URL completa inmediatamente porque las barras invertidas están prohibidas y los espacios están prohibidos. El navegador continúa analizando; el analizador estricto se detiene por completo. Pruebe con otro ejemplo: "https://user@example.com:80/path?q=a&b=c". Ambos estándares identifican claramente la información del usuario, el host, el puerto, la ruta y la consulta. Están completamente de acuerdo en esta URL estructurada. El desacuerdo ocurre solo en entradas inusuales o con formato incorrecto.
Abra el codificador y decodificador de URL y compare el modo RFC 3986 con el comportamiento del navegador. Pegue una cadena con espacios, barras invertidas u otros casos extremos. La herramienta le muestra exactamente cómo cada estándar transforma la misma entrada de manera diferente. Ves enseguida cuál es más estricto y qué hace cada uno.
Cuál utiliza su entorno: los navegadores y Node siguen el estándar de URL; Muchas bibliotecas de servidor siguen el RFC, que se describe de forma general.
En los navegadores, JavaScript utiliza el estándar de URL WHATWG de forma predeterminada. La API de URL lo implementa exactamente. Node.js también usa WHATWG. Las bibliotecas de Python tienden a implementar RFC 3986; urllib lo sigue de cerca. Las bibliotecas de Java varían; java.net.URL tiende hacia RFC 3986. La caja de URL de Rust sigue WHATWG. La red/url de Go está influenciada por WHATWG. Éste es un patrón general, no una regla absoluta.
Cuando crea URL mediante programación y se mueven entre el navegador y el backend, elija un estándar y cúmplalo. Utilice la API de URL del navegador para WHATWG. Si su biblioteca de backend es más estricta, no es una contradicción sino una elección de diseño.
Lo que esto no cubre: análisis de nombres de host, literales IPv6 y procesamiento de IDNA
El análisis de nombres de host implica IDNA, punycode y reglas de registro que van más allá del análisis de URL en sí. Las direcciones IPv6, los esquemas especiales como mailto: o data: y los componentes vacíos son temas separados y distintos de la codificación porcentual por completo. Los límites de longitud del dominio y la validez del nombre de host varían según el registrador y no son relevantes para esta discusión. También se excluyen: referencias relativas y reglas de análisis específicas del esquema. Esta publicación se centra únicamente en la codificación y el análisis de diferencias.
Esta discusión se centra en las diferencias de codificación y análisis que distinguen estos estándares. La exclusión de las reglas de nombre de host, las reglas de DNS y el comportamiento específico del esquema evita la confusión sobre las reglas de codificación porcentual.
Conclusión: la misma URL es válida en un mundo y un error en otro: cómo el codificador y descodificador de URL le proporciona la codificación RFC 3986 simple para que pueda ver lo que el navegador normalizó
La misma cadena de URL puede ser válida según un estándar e inválida según el otro. Ambos son correctos dentro de sus propios objetivos de diseño. Al codificar componentes URL mediante programación, utilice la herramienta adecuada para su entorno. WHATWG describe lo que realmente hacen los navegadores; RFC 3986 define la gramática formal. El codificador y decodificador de URL muestra reglas RFC 3986 junto con el comportamiento del navegador para que pueda ver las diferencias exactas y elegir cuál se adapta a su situación.
Los problemas aparecen con mayor frecuencia cuando las URL cruzan los límites del navegador al backend. Comprender esta diferencia significa manejar ese cruce intencionalmente y no accidentalmente o por error.