La codificación de URL , oficialmente conocida como codificación porcentual , es un método para codificar datos arbitrarios en un identificador uniforme de recursos (URI) utilizando solo los caracteres US-ASCII legales dentro de un URI. Aunque se conoce como codificación de URL , también se usa de manera más general dentro del conjunto principal de Identificador uniforme de recursos (URI), que incluye tanto el Localizador uniforme de recursos (URL) como el Nombre uniforme de recursos (URN). Como tal, también se utiliza en la preparación de datos del application/x-www-form-urlencoded tipo de medio , como se utiliza a menudo en el envío de datos de formulario HTML en solicitudes HTTP .
Los caracteres permitidos en un URI están reservados o no reservados (o un carácter de porcentaje como parte de una codificación porcentual). Los caracteres reservados son aquellos caracteres que en ocasiones tienen un significado especial. Por ejemplo, los caracteres de barra diagonal se utilizan para separar diferentes partes de una URL (o más generalmente, una URI). Los caracteres no reservados no tienen tales significados. Al utilizar codificación porcentual, los caracteres reservados se representan mediante secuencias de caracteres especiales. Los conjuntos de caracteres reservados y no reservados y las circunstancias bajo las cuales ciertos caracteres reservados tienen un significado especial han cambiado ligeramente con cada revisión de las especificaciones que rigen los URI y los esquemas de URI.
Otros caracteres en un URI deben estar codificados en porcentaje.
Cuando un carácter del conjunto reservado (un "carácter reservado") tiene un significado especial (un "propósito reservado") en un contexto determinado, y un esquema de URI dice que es necesario usar ese carácter para algún otro propósito , entonces el El carácter debe estar codificado en porcentaje . La codificación porcentual de un carácter reservado implica convertir el carácter a su valor de byte correspondiente en ASCII y luego representar ese valor como un par de dígitos hexadecimales (si hay un solo dígito hexadecimal, se agrega un cero a la izquierda ). Los dígitos, precedidos por un signo de porcentaje ( %) como carácter de escape , se utilizan en el URI en lugar del carácter reservado. (Para un carácter que no es ASCII, normalmente se convierte a su secuencia de bytes en UTF-8 y luego cada valor de byte se representa como se muestra arriba).
El carácter reservado /, por ejemplo, si se utiliza en el componente "ruta" de un URI , tiene el significado especial de ser un delimitador entre segmentos de ruta. Si, de acuerdo con un esquema de URI determinado, /debe estar en un segmento de ruta, entonces se deben usar tres caracteres %2Fo en el segmento en lugar de un archivo raw .%2f/
Los caracteres reservados que no tienen ningún propósito reservado en un contexto particular también pueden estar codificados en porcentaje, pero no son semánticamente diferentes de aquellos que no lo están.
En el componente " consulta " de un URI (la parte después de un ?carácter), por ejemplo, /todavía se considera un carácter reservado pero normalmente no tiene ningún propósito reservado, a menos que un esquema de URI particular indique lo contrario. No es necesario codificar el carácter en porcentaje cuando no tiene un propósito reservado.
Los URI que difieren sólo en si un carácter reservado está codificado en porcentaje o aparece literalmente normalmente no se consideran equivalentes (denotan el mismo recurso) a menos que se pueda determinar que los caracteres reservados en cuestión no tienen un propósito reservado. Esta determinación depende de las reglas establecidas para los caracteres reservados por esquemas de URI individuales.
Los caracteres del conjunto no reservado nunca necesitan estar codificados en porcentaje.
Los URI que difieren sólo en si un carácter no reservado está codificado en porcentaje o aparece literalmente son equivalentes por definición, pero es posible que los procesadores de URI, en la práctica, no siempre reconozcan esta equivalencia. Por ejemplo, los consumidores de URI no deberían tratar %41de manera diferente Ao %7Ediferente a ~, pero algunos sí lo hacen. Para lograr la máxima interoperabilidad, se desaconseja a los productores de URI codificar caracteres no reservados con porcentajes.
Debido a que el carácter de porcentaje ( %) sirve como indicador para octetos codificados en porcentaje, debe estar codificado en porcentaje para %25que ese octeto se utilice como datos dentro de un URI.
La mayoría de los esquemas de URI implican la representación de datos arbitrarios, como una dirección IP o una ruta del sistema de archivos , como componentes de un URI. Las especificaciones del esquema URI deberían proporcionar, aunque a menudo no lo hacen, una asignación explícita entre los caracteres URI y todos los valores de datos posibles representados por esos caracteres.
Desde la publicación de RFC 1738 en 1994, se ha especificado que los esquemas que proporcionan la representación de datos binarios en un URI deben dividir los datos en bytes de 8 bits y codificar porcentualmente cada byte de la misma manera que antes. [1] El valor del byte 0x0F, por ejemplo, debe representarse mediante %0F, pero el valor del byte 0x41 puede representarse mediante A, o %41. Normalmente se prefiere el uso de caracteres no codificados para caracteres alfanuméricos y otros caracteres no reservados, ya que da como resultado URL más cortas.
El procedimiento para la codificación porcentual de datos binarios a menudo se ha extrapolado, a veces de manera inapropiada o sin especificarse completamente, para aplicarlo a datos basados en caracteres. En los años de formación de la World Wide Web , cuando se trataba de caracteres de datos en el repertorio ASCII y se utilizaban sus bytes correspondientes en ASCII como base para determinar secuencias codificadas en porcentaje, esta práctica era relativamente inofensiva; simplemente se suponía que los caracteres y bytes estaban asignados uno a uno y eran intercambiables. Sin embargo, la necesidad de representar caracteres fuera del rango ASCII creció rápidamente y los esquemas y protocolos de URI a menudo no proporcionaban reglas estándar para preparar datos de caracteres para su inclusión en un URI. En consecuencia, las aplicaciones web comenzaron a utilizar diferentes codificaciones multibyte, con estado y otras codificaciones no compatibles con ASCII como base para la codificación porcentual, lo que generó ambigüedades y dificultades para interpretar los URI de manera confiable.
Por ejemplo, muchos esquemas y protocolos de URI basados en los RFC 1738 y 2396 suponen que los caracteres de datos se convertirán en bytes de acuerdo con alguna codificación de caracteres no especificada antes de ser representados en un URI mediante caracteres no reservados o bytes codificados por porcentaje. Si el esquema no permite que el URI proporcione una pista sobre qué codificación se utilizó, o si la codificación entra en conflicto con el uso de ASCII para codificar porcentualmente caracteres reservados y no reservados, entonces el URI no se puede interpretar de manera confiable. Algunos esquemas no tienen en cuenta la codificación en absoluto y, en cambio, simplemente sugieren que los caracteres de datos se asignen directamente a los caracteres URI, lo que deja a las implementaciones decidir si codificar porcentualmente los caracteres de datos que no están en los conjuntos reservados ni en los no reservados y cómo hacerlo.
Los datos de caracteres arbitrarios a veces se codifican en porcentajes y se utilizan en situaciones que no son URI, como para programas de ofuscación de contraseñas u otros protocolos de traducción específicos del sistema.
La sintaxis genérica de URI recomienda que los nuevos esquemas de URI que proporcionan la representación de datos de caracteres en un URI deberían, de hecho, representar caracteres del conjunto no reservado sin traducción y deberían convertir todos los demás caracteres a bytes de acuerdo con UTF-8 , y luego en porcentaje. -codificar esos valores. Esta sugerencia se introdujo en enero de 2005 con la publicación del RFC 3986. Los esquemas de URI introducidos antes de esta fecha no se ven afectados.
La especificación actual no aborda qué hacer con los datos de caracteres codificados. Por ejemplo, en las computadoras, los datos de caracteres se manifiestan en forma codificada, en algún nivel, y por lo tanto podrían tratarse como datos binarios o de caracteres cuando se asignan a caracteres URI. Presumiblemente, depende de las especificaciones del esquema URI tener en cuenta esta posibilidad y requerir uno u otro, pero en la práctica, pocos, si es que hay alguno, lo hacen.
Existe una codificación no estándar para caracteres Unicode: , donde xxxx es una unidad de código UTF-16 representada como cuatro dígitos hexadecimales. Este comportamiento no está especificado en ningún RFC y ha sido rechazado por el W3C. La decimotercera edición de ECMA-262 todavía incluye una función que utiliza esta sintaxis, que aplica la codificación UTF-8 a una cadena y luego escapa porcentualmente los bytes resultantes. [2]%uxxxxescape
Cuando se envían datos que se ingresaron en formularios HTML , los nombres y valores de los campos del formulario se codifican y se envían al servidor en un mensaje de solicitud HTTP utilizando el método GET o POST o, históricamente, por correo electrónico . [3] La codificación utilizada de forma predeterminada se basa en una versión anterior de las reglas generales de codificación porcentual de URI, [4] con una serie de modificaciones, como la normalización de nuevas líneas y la sustitución de espacios por +en lugar de %20. El tipo de medio de datos codificados de esta manera es application/x-www-form-urlencodedy actualmente está definido en las especificaciones HTML y XForms . Además, la especificación CGI contiene reglas sobre cómo los servidores web decodifican datos de este tipo y los ponen a disposición de las aplicaciones.
Cuando se envían datos de formulario HTML en una solicitud HTTP GET, se incluyen en el componente de consulta del URI de solicitud utilizando la misma sintaxis descrita anteriormente. Cuando se envían en una solicitud HTTP POST o por correo electrónico, los datos se colocan en el cuerpo del mensaje y application/x-www-form-urlencodedse incluyen en el encabezado Tipo de contenido del mensaje.
Todas las especificaciones siguientes analizan y definen caracteres reservados, caracteres no reservados y codificación porcentual, de una forma u otra:
Varias implementaciones: