Herramientas de desarrollo · Codificador y decodificador de URL
Plus versus %20: el historial de aplicación/x-www-form-urlencoded
· Antecedentes
codificación de URL formularios html estándares http
Los formularios codifican un espacio como + mientras que el estándar URI dice %20 y el motivo es histórico. Esta publicación rastrea la convención desde los primeros formularios HTML hasta la definición actual de WHATWG y explica por qué nunca desapareció.
Plus versus %20: por qué los formularios y los URI codifican espacios de manera diferente
Los formularios HTML enviados como GET codifican espacios como signos más en la cadena de consulta. El mismo espacio se convierte en %20 en las URL que siguen al RFC 3986. Ambos son correctos porque siguen estándares diferentes. Los campos de formulario que contienen espacios se convierten en nombre=valor+con+espacios en la codificación del formulario, pero %20 en RFC 3986. La distinción de más por ciento veinte marca qué estándar se aplica a sus datos.
La codificación de formularios utiliza plus para espacios como convención histórica de RFC 1866 (1995), la definición de envío de formulario original de HTML 2.0. GET solicita espacios codificados como signos más, reservando más para el literal + codificado como %2B. Esta regla se aplica solo a la aplicación/x-www-form-urlencoded,, no a la sintaxis general de URI. Miles de millones de estructuras de servidores se volvieron dependientes de esta convención. Probar ambos muestra diferencias claras: el modo de forma produce más; El modo URI produce %20. El codificador y decodificador de URL ofrece ambos modos para comparar directamente.
Formularios HTML iniciales y envío GET: cómo se definió la codificación del formulario y por qué se eligió +
RFC 1866 (1995) definió el envío de formulario donde los espacios se convierten en más y el literal más se convierte en %2B. Esto se aplicó solo a la aplicación/x-www-form-urlencoded. RFC 3986 especificada %20 para la sintaxis general de URI. Dos estándares coexistieron deliberadamente.
RFC 2396 aclaró los conjuntos de caracteres de manera más rigurosa que los estándares anteriores. Formalizó los caracteres reservados que sirven a la estructura de URI en lugar de los no reservados como datos literales. Los organismos de normalización codifican el comportamiento del navegador y del proxy a medida que evoluciona. RFC 3986 llegó más tarde sin cambiar el comportamiento de codificación, solo aclarando la notación. Todos los navegadores actuales están estandarizados en la codificación UTF-8. Los formularios HTML a través de los botones de envío envían la solicitud en formato /x-www-form-urlencoded con un signo más para los espacios. La construcción manual de URI utiliza %20. Comprender ambos estándares evita sorpresas en la integración.
RFC 1866 y especificaciones HTML posteriores: dónde se escribió la regla y cómo divergía de la sintaxis de URI
WHATWG URL Standard especifica que URLSearchParams.toString() produce la salida de la aplicación /x-www-form-urlencoded con signos más para los espacios. El constructor de URL codifica en porcentaje siguiendo el RFC 3986. Navegador navegando a una URL con códigos de espacio %20; formulario enviado como GET codifica plus. Estas herramientas fundamentalmente diferentes sirven para diferentes propósitos. El encodeURIComponent manual proporciona %20 para espacios: estilo RFC 3986. Los formularios enviados a la misma URL se envían más. Los servidores que analizan los envíos de formularios esperan más; recibir %20 provoca fallas silenciosas en los parámetros.
Probar ambos revela suposiciones del lado del servidor de las que usted depende. JavaScript URLSearchParams proporciona ocultación segura de codificación de estilo de formulario además de complejidad. Construya URLSearchParams, agregue entradas, llame a toString() para obtener application/x-www-form-urlencoded con el signo más adecuado. Alternativamente, cree cadenas de consulta con encodeURIComponent; obtienes RFC 3986 %20. Nunca mezcle enfoques. Las cadenas de consulta con manual plus y encodeURIComponent crean ambigüedad. Los receptores no pueden distinguir si más significa espacio o más literal. Los enfoques estándar se manejan de manera consistente.
El estándar de URL actual: aplicación/x-www-form-urlencoded como un serializador independiente con sus propias reglas
JSON Las API normalmente rechazan el signo plus como espacio, esperando %20 según RFC 3986. Los clientes que envían plus fallan silenciosamente: los parámetros desaparecen. Las pruebas de API con ambas codificaciones revelan qué estándar aceptan. URLSearchParams en JavaScript maneja la codificación de formularios. El codificador y decodificador de URL produce RFC 3986 %20.
El envío del formulario HTML maneja automáticamente la codificación. El marco de su servidor decide qué reglas se aplican. Rails, Django y PHP tratan automáticamente el plus como espacio en los datos del formulario recibido. Pero la creación manual de cadenas de consulta para los mismos puntos finales es muy importante. Un plus subido crea ambigüedad. El cumplimiento de las especificaciones y el comportamiento del servidor en el mundo real difieren ligeramente. Documente qué estándar esperan sus puntos finales. Pruebe ambos estilos de codificación. El código defensivo maneja ambos con gracia.
Ejemplo resuelto: el mismo campo de formulario visto como una cadena de consulta y como un cuerpo de solicitud, con + en un lugar y %20 en otro
JavaScript URLSearchParams aplica codificación de formulario: el espacio se convierte en más, no en %20. new URLSearchParams({q: "hello world"}) produce "q=hello+world", no "q=hello%20world". Esta es la regla de aplicación histórica /x-www-form-urlencoded integrada específicamente en JavaScript. Pero pasar esta cadena como consulta sin formato a una nueva URL mantiene plus como plus; sólo URLSearchParams lo decodifica como espacio. El constructor es fiel a lo que ve. La diferencia del signo más causa errores comunes al mezclar funciones incorrectamente.
El constructor de URL y encodeURIComponent son herramientas diferentes. encodeURIComponent codifica casi todo excepto letras, dígitos y - _ no reservados. ! ~*'( ). No asume ningún contexto. El constructor de URL analiza la URL real y aplica reglas WHATWG por componente. encodeURIComponent convierte "hello/world" en "hello%2Fworld"; la nueva URL ve barras como separadores de ruta. Misma entrada, diferente salida. Utilice encodeURIComponent al crear URL concatenando piezas. Utilice URLSearchParams o el constructor de URL para URL completas o parciales.
Por qué no se puede solucionar: décadas de servidores y clientes que dependen del comportamiento actual
Las reglas de codificación porcentual evolucionaron desde RFC 1738 (1994) pasando por RFC 2396 (1998) hasta RFC 3986 (2005). Cada generación aclaró ambigüedades. RFC 1738 era conservador y trataba a los personajes como inseguros porque la web inicial tenía soporte de caracteres limitado. Las implementaciones se estandarizaron el UTF-8, las implementaciones se volvieron consistentes. Los estándares posteriores relajaron las restricciones sobre los personajes que demostraban ser seguros en todos los sistemas. Consenso moderno: UTF-8 en todas partes. Los organismos de normalización mantienen ferozmente la compatibilidad con versiones anteriores. Para arreglarlo se necesitaría coordinación mundial, algo imposible después de tres décadas. Dos estándares coexisten deliberadamente.
Las pruebas con plus y %20 revelan suposiciones del servidor. Los registros del servidor muestran lo que envían los clientes. Uso de formularios más; Las URL manuales utilizan %20. Elija por contexto y siga la documentación de la API.
Lo que esto no cubre: cuerpos multiparte /form-data y JSON
La prueba de ambas codificaciones revela el comportamiento del servidor. Envíe a+b en ambos sentidos. Muchos servidores de producción esperan codificación de formularios; Las API más nuevas esperan %20. Su elección depende de las expectativas del receptor. URLSearchParams maneja la codificación de formularios; encodeURIComponent maneja la codificación RFC.
Nunca combine métodos de codificación. El valor codificado con encodeURIComponent %2B y luego pasado a URLSearchParams se codifica doblemente como %252B. Decodificar una vez produce %2B en lugar de plus. El carácter se convierte en una cadena literal de porcentaje dos-seis en lugar de un signo más. Verifique los pasos intermedios en su proceso de construcción. La codificación ocurre exactamente una vez por valor solamente. Documente qué estándar de codificación utiliza su canalización. Pruebe con caracteres especiales que incluyen más, espacio y ampersand.
Conclusión: dos estándares, ambos correctos en su contexto: cómo el codificador y decodificador de URL le proporciona el formulario RFC 3986, con %20 para espacios, para que sepa cuál está viendo
La división más contra veinte no es un error que deba corregirse. Es un artefacto histórico de estándares que resuelven distintos problemas de manera diferente. Para arreglarlo se necesitaría coordinación mundial, algo imposible después de treinta años. Los organismos de normalización no rompen la web de forma retroactiva. RFC 3986, reglas de formulario y construcción de URL del navegador tienen estándares y razones. La codificación de formulario RFC 1866 y la codificación de URI RFC 3986 sirven a diferentes capas. Codifique deliberadamente conociendo su estándar. Pruebe con cargas útiles realistas.
Elija codificación por contexto. Los formularios utilizan plus según los estándares HTML. Los URI manuales utilizan %20 según RFC 3986. Las API especifican qué esperar; siga la documentación o pruebe ambos. El codificador y decodificador de URL muestra RFC 3986. ¿Necesita codificación de formularios? URLSearchParams hace eso. La herramienta no mezcla codificaciones; comprender los estándares evita sorpresas. La inconsistencia de codificación entre capas provoca una sutil pérdida de parámetros, truncamiento y corrupción de datos. Ambos estándares son correctos en su ámbito. Aplicar deliberadamente y documentar.