La codificación porcentual , también conocida como codificación de URL , es un método para codificar datos arbitrarios en un Identificador uniforme de recursos (URI) utilizando solo los caracteres limitados de 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 usa en la preparación de datos del /x-www-form-urlencoded
tipo de medio , como se usa a menudo en el envío de datos de formularios HTML en solicitudes HTTP .
Codificación porcentual en un URI
Tipos de caracteres URI
Los caracteres permitidos en un URI son o bien reservados o sin reservas (o un carácter de porcentaje como parte de un código porciento). Los caracteres reservados son aquellos que a veces 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. Mediante codificación porcentual, 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 gobiernan los URI y los esquemas de URI.
! | # | $ | & | ' | ( | ) | * | + | , | / | : | ; | = | ? | @ | [ | ] |
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z | |
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | - | _ | . | ~ |
Otros caracteres en un URI deben estar codificados en porcentaje.
Personajes reservados
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 . Los dígitos, precedidos por un signo de porcentaje ( %
) que se utiliza como carácter de escape , se utilizan en el URI en lugar del carácter reservado. (Para un carácter no ASCII, normalmente se convierte a su secuencia de bytes en UTF-8 , y luego cada valor de byte se representa como se indica 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 dado, /
necesita estar en un segmento de ruta, entonces los tres caracteres %2F
o %2f
deben usarse en el segmento en lugar de sin formato /
.
! | # | $ | % | & | ' | ( | ) | * | + | , | / | : | ; | = | ? | @ | [ | ] |
%21 | %23 | %24 | %25 | %26 | %27 | %28 | %29 | %2A | %2B | %2C | %2F | %3A | %3B | %3D | %3F | %40 | %5B | %5D |
Los caracteres reservados que no tienen un propósito reservado en un contexto particular también pueden estar codificados por porcentaje, pero no son semánticamente diferentes de los que no lo son.
En el componente de " 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 un propósito reservado, a menos que un esquema de URI en particular indique lo contrario. El carácter no necesita estar codificado en porcentaje cuando no tiene un propósito reservado.
Los URI que solo se diferencian por si un carácter reservado está codificado en porcentaje o aparece literalmente normalmente se consideran no equivalentes (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.
Personajes no reservados
Los caracteres del conjunto no reservado nunca necesitan codificación porcentual.
Los URI que solo se diferencian por 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, no siempre reconocen esta equivalencia. Por ejemplo, los consumidores de URI no deben tratar de manera %41
diferente A
o %7E
diferente a ~
, pero algunos lo hacen. Para una máxima interoperabilidad, se desaconseja a los productores de URI que codifiquen en porcentaje caracteres no reservados.
Carácter de porcentaje
Debido a que el carácter de porcentaje ( %
) sirve como indicador para octetos codificados en porcentaje, debe estar codificado en porcentaje %25
para que ese octeto se use como datos dentro de un URI.
Datos arbitrarios
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 de URI deberían, pero a menudo no lo hacen, proporcionar un mapeo explícito entre los caracteres de URI y todos los valores de datos posibles representados por esos caracteres.
Datos binarios
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 de byte 0x0F, por ejemplo, debe representarse por %0F
, pero el valor de byte 0x41 puede representarse por 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.
Datos de carácter
El procedimiento para la codificación porcentual de datos binarios a menudo se ha extrapolado, a veces de manera inapropiada o sin estar completamente especificado, 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 usaban sus bytes correspondientes en ASCII como base para determinar secuencias codificadas porcentuales, esta práctica era relativamente inofensiva; simplemente se asumió que los caracteres y 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 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 genera ambigüedades y dificultades para interpretar los URI de manera confiable.
Por ejemplo, muchos esquemas y protocolos de URI basados en 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 por caracteres no reservados o bytes codificados porcentualmente. Si el esquema no permite que el URI proporcione una pista sobre qué codificación se usó, 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, solo 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 ni en los conjuntos reservados ni en los no reservados.
newline | space | " | % | - | . | < | > | \ | ^ | _ | ` | { | | | } | ~ | £ | 円 |
%0A o %0D o %0D%0A | %20 | %22 | %25 | %2D | %2E | %3C | %3E | %5C | %5E | %5F | %60 | %7B | %7C | %7D | %7E | %C2%A3 | %E5%86%86 |
Los datos de caracteres arbitrarios a veces se codifican en porcentaje 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.
Estándar actual
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, en efecto, 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 codificar en porcentaje esos valores. Esta sugerencia se introdujo en enero de 2005 con la publicación de RFC 3986. Los esquemas de URI introducidos antes de esta fecha no se ven afectados.
Lo que no se aborda en la especificación actual es 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 de URI tener en cuenta esta posibilidad y requerir una u otra, pero en la práctica, pocos, si es que hay alguno, realmente lo hacen.
Implementaciones no estándar
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 ningún RFC y ha sido rechazado por el W3C. La octava edición de ECMA-262 todavía incluye una función que usa esta sintaxis, junto con funciones y , que aplican codificación UTF-8 a una cadena y luego escapan porcentualmente los bytes resultantes. [2]%uxxxx
escape
encodeURI
encodeURIComponent
El tipo application / x-www-form-urlencoded
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 forma predeterminada se basa en una versión anterior de las reglas generales de codificación de porcentaje de URI, [4] con una serie de modificaciones como la normalización de nueva línea y la sustitución de espacios con 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 los datos del formulario HTML se envían 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-urlencoded
se incluyen en el encabezado Content-Type del mensaje.
Ver también
- Identificador de recursos internacionalizado
- Punycode
- Codificación de binario a texto para una comparación de varios algoritmos de codificación
- Shellcode
Referencias
- ^ RFC 1738 §2.2; RFC 2396 §2.4; RFC 3986 §1.2.1, 2.1, 2.5
- ^ "Especificación del idioma ECMAScript 2017 (ECMA-262, 8ª edición, junio de 2017)" . Ecma International.
- ^ El soporte de agente de usuario para elenvío de formularios HTML basados en correo electrónico, utilizando una URL 'mailto'como la acción del formulario, se propuso en la sección 5.6 de RFC 1867, durante la era de HTML 3.2. Varios navegadores web lo implementaron invocando un programa de correo electrónico separado o utilizando sus propiascapacidades SMTP rudimentarias. Aunque a veces no es confiable, fue brevemente popular como una forma simple de transmitir datos de formularios sin involucrar un servidor web oscripts CGI .
- ^ Berners-Lee, T. (junio de 1994). "RFC 1630" . Herramientas IETF . IETF . Consultado el 29 de junio de 2016 .
enlaces externos
- Codificador de URL DevPal : herramientas de desarrollo en línea que admiten la codificación de URL.
Todas las siguientes especificaciones discuten y definen caracteres reservados, caracteres no reservados y codificación porcentual, de una forma u otra:
- RFC 3986 / STD 66 (más erratas ), la especificación de sintaxis de URI genérica actual.
- RFC 2396 (obsoleto, más erratas ) y RFC 2732 (más erratas ) juntos formaban la versión anterior de la especificación de sintaxis URI genérica.
- Codificación y decodificación de URL: en línea : un sitio web con varias opciones para convertir archivos o textos en formato codificado para URL.
- RFC 1738 (en su mayoría obsoleto) y RFC 1808 (obsoleto), que definen las URL .
- RFC 1630 (obsoleto), la primera especificación de sintaxis URI genérica.
- Directrices del W3C sobre nombres y direcciones: URI, URL, ...
- Explicación del W3C de UTF-8 en URI
- Tipos de contenido de formulario HTML del W3C