La codificación URL , conocida oficialmente 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 URL , también se utiliza de forma más general dentro del conjunto principal de identificadores uniformes de recursos (URI), que incluye tanto el localizador uniforme de recursos (URL) como el nombre uniforme de recursos (URN). En consecuencia, 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 una URL son reservados o no reservados (o un carácter de porcentaje como parte de una codificación de porcentaje). Los caracteres reservados son aquellos caracteres que a veces tienen un significado especial. Por ejemplo, los caracteres de barra diagonal se utilizan para separar diferentes partes de una URL (o, de forma más general, una URL). Los caracteres no reservados no tienen ese significado. Al utilizar la codificación de porcentaje, los caracteres reservados se representan mediante secuencias de caracteres especiales. Los conjuntos de caracteres reservados y no reservados y las circunstancias en las que ciertos caracteres reservados tienen un significado especial han cambiado ligeramente con cada revisión de las especificaciones que rigen las URL y los esquemas de URL.
Los demás caracteres de una 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 URI indica que es necesario utilizar ese carácter para algún otro propósito, entonces el carácter debe codificarse 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 inicial ). Los dígitos, precedidos por un signo de porcentaje ( %) como carácter de escape , se utilizan luego en el URI en lugar del carácter reservado. (Un carácter que no es ASCII generalmente se convierte a su secuencia de bytes en UTF-8 y luego cada valor de byte se representa como se indicó anteriormente).
El carácter reservado /, por ejemplo, si se utiliza en el componente "path" de una URI , tiene el significado especial de ser un delimitador entre segmentos de ruta. Si, según un esquema de URI determinado, /debe estar en un segmento de ruta, entonces se deben utilizar los tres caracteres %2Fo %2fen el segmento en lugar de un /.
Los caracteres reservados que no tienen un propósito reservado en un contexto particular también pueden codificarse en porcentaje, pero no son semánticamente diferentes de aquellos que no lo tienen.
Por ejemplo, el componente " consulta " de una URI (la parte posterior a un carácter) todavía se considera un carácter reservado, pero normalmente no tiene un propósito reservado, a menos que un esquema de URI en particular indique lo contrario. No es necesario codificar el carácter en porcentaje cuando no tiene un propósito reservado.?/
Los URI que difieren únicamente en si un carácter reservado está codificado en porcentaje o aparece de forma literal normalmente se consideran no equivalentes (es decir, que 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 caracteres reservados por esquemas de URI individuales.
Los caracteres del conjunto no reservado nunca necesitan ser codificados en porcentaje.
Los URI que difieren únicamente en si un carácter no reservado está codificado en porcentaje o aparece literalmente son equivalentes por definición, pero los procesadores de URI, en la práctica, pueden no siempre reconocer esta equivalencia. Por ejemplo, los consumidores de URI no deberían tratar %41de manera diferente a Ao %7Ediferente a ~, pero algunos lo hacen. Para lograr la máxima interoperabilidad, se desaconseja a los productores de URI codificar en porcentaje caracteres no reservados.
Debido a que el carácter de porcentaje ( %) sirve para indicar octetos codificados en porcentaje, debe estar codificado en porcentaje para %25poder usarse como datos dentro de una URI.
La mayoría de los esquemas 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 de esquemas URI deberían proporcionar, aunque a menudo no lo hacen, una asignación explícita entre los caracteres URI y todos los posibles valores de datos representados por esos caracteres.
Desde la publicación de RFC 1738 en 1994, se ha especificado que los esquemas que prevén la representación de datos binarios en una URI deben dividir los datos en bytes de 8 bits y codificar porcentualmente cada byte de la misma manera que se indicó anteriormente. [1] El valor de byte 0x0F, por ejemplo, debe representarse mediante %0F, pero el valor de byte 0x41 puede representarse mediante A, o %41. Por lo general, 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 codificar en porcentajes los datos binarios se ha extrapolado a menudo, a veces de forma inapropiada o sin especificarse por completo, para aplicarlo a los datos basados en caracteres. En los primeros años de la World Wide Web , cuando se trataba de caracteres de datos del repertorio ASCII y se utilizaban sus bytes correspondientes en ASCII como base para determinar secuencias codificadas en porcentajes, esta práctica era relativamente inofensiva; simplemente se suponía que los caracteres y los bytes se asignaban 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 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 no compatibles con ASCII como base para la codificación en porcentajes, lo que generó ambigüedades y dificultades para interpretar los URI de manera confiable.
Por ejemplo, muchos esquemas y protocolos de URI basados en las RFC 1738 y 2396 presuponen 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 por caracteres no reservados o bytes codificados en 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 en porcentaje 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 su lugar, simplemente sugieren que los caracteres de datos se asignan directamente a caracteres URI, lo que deja en manos de las implementaciones la decisión de si codificar en porcentaje caracteres de datos que no están en los conjuntos reservados ni no reservados y cómo hacerlo.
A veces, los datos de caracteres arbitrarios se codifican en porcentaje y se utilizan en situaciones que no son URI, como en programas de ofuscación de contraseñas u otros protocolos de traducción específicos del sistema.
La sintaxis URI genérica recomienda que los nuevos esquemas URI que permiten la representación de datos de caracteres en un URI representen, en efecto, caracteres del conjunto no reservado sin traducción y conviertan todos los demás caracteres en bytes según UTF-8 y luego codifiquen en porcentaje esos valores. Esta sugerencia se introdujo en enero de 2005 con la publicación de RFC 3986. Los esquemas 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 una u otra, pero en la práctica, pocas, si es que hay alguna, 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 por ninguna RFC y ha sido rechazado por el W3C. La 13.ª edición de ECMA-262 aún incluye una función que utiliza esta sintaxis, que aplica codificación UTF-8 a una cadena y luego aplica un porcentaje de escape a los bytes resultantes. [2]%uxxxxescape
Cuando se envían datos que se han ingresado 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 manera 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 nueva línea 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-urlencoded, y 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 de la 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 Content-Type del mensaje.
Las siguientes especificaciones analizan y definen caracteres reservados, caracteres no reservados y codificación porcentual, de una forma u otra: