El porcentaje de codificación en el porcentaje de codificación en inglés , también conocido como codificación de URL , es un mecanismo para codificar información en un Identificador uniforme de recursos (URI) en determinadas circunstancias. Aunque se conoce como codificación de URL , se usa de manera más general dentro del URI principal, que incluye tanto URL como URN. Como tal, también se utiliza en la preparación de datos del tipo de medio (o tipo MIME) application/x-www-form-urlencoded, como suele ser el caso cuando se envían formularios de datos HTML en solicitudes HTTP .
Los caracteres permitidos en un URI son o reservados ( reservados ) se no reservados ( sin reservas ). También puede ser un carácter de porcentaje como %parte de una codificación de porcentaje. Los caracteres reservados son aquellos que a veces tienen un significado especial. Por ejemplo, el carácter de barra se usa para separar diferentes partes de la URL (o, más generalmente, de una URI). Los personajes sin reservas no tienen tanta trascendencia. Mediante la codificación porcentual, los caracteres reservados se representan mediante secuencias de caracteres. Los conjuntos de caracteres reservados y no reservados, así como las circunstancias en las que ciertos caracteres reservados adquieren un significado especial, han cambiado ligeramente con cada revisión de las especificaciones que rigen los URI y los patrones de URI.
| : | / | ? | # | [ | ] | @ | ! | $ | & | ' | ( | ) | * | + | , | ; | = |
| A | B | C | D | E | F | G | H | I | J | K | M | L | N | O | P | Q | R | S | T | U | V | W | X | Y | Z |
| a | b | c | d | e | f | g | h | i | j | k | m | l | 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.
Cuando un carácter en el conjunto reservado (un "carácter reservado") tiene un significado especial (que está "reservado para un propósito") en algún contexto, y un esquema de URI requiere el uso del carácter para otros propósitos, el carácter debe ser porcentaje codificado . Codificar un carácter reservado como porcentaje implica convertir el carácter al valor correspondiente de su byte 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 introducen en el URI en lugar de los caracteres reservados. (En el caso de un carácter no ASCII, generalmente se convierte a su secuencia de bytes en UTF-8 , y luego cada valor de byte se representa como se muestra a continuación).
El carácter reservado /, por ejemplo, si se utiliza en el componente "ruta" de un URI, tendrá el significado especial de delimitador entre los segmentos de la ruta. Si, de acuerdo con un esquema de URI, /debe estar dentro de un segmento de ruta, entonces los tres caracteres %2Fo %2fdeben usarse en el segmento en lugar de /uno sin formato.
| ! | # | $ | & | ' | ( | ) | * | + | , | / | : | ; | = | ? | @ | [ | ] |
| %21 | %23 | %24 | %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 se pueden codificar en porcentaje, pero no son semánticamente diferentes de los que no lo son.
En la " cadena de consulta de parte " ( cadena 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 URI particular del esquema indique lo contrario. Por lo tanto, no es necesario codificar el carácter en porcentaje cuando no tiene un propósito reservado.
Dos URI que se diferencian solo en que un carácter reservado está codificado en porcentaje en uno, mientras que aparece como está en el otro, normalmente no se consideran equivalentes (designando el mismo recurso), excepto s 'se puede establecer que el carácter reservado en cuestión no tiene ningún propósito reservado. Esta determinación depende de las reglas establecidas por cada esquema de URI para los caracteres reservados.
Los caracteres del conjunto no reservado nunca requieren codificación porcentual.
Los URI que difieren solo en si un carácter no reservado está codificado en porcentaje o aparece como está son equivalentes por definición, pero los intérpretes de URI, en la práctica, no siempre reconocen esta equivalencia. Por ejemplo, no deberían tratar la cadena de manera %41diferente Ao %7Ediferente ~, pero algunos lo hacen. Para una máxima interoperabilidad, no se recomienda que el porcentaje de productores de URI codifique caracteres no reservados .
Debido a que el carácter de porcentaje ( %) sirve como indicador para bytes codificados porcentuales, debe codificarse como %25si fuera a usarse como datos dentro de un URI.
La mayoría de los patrones de URI implican la representación de datos arbitrarios, como la dirección IP o una ruta en un sistema de archivos , como parte de un URI. Las especificaciones del esquema de URI deberían, pero a menudo no lo hacen, proporcionar una coincidencia explícita entre los caracteres del URI y todos los valores de datos posibles que están representados por esos caracteres.
Datos binariosDesde la publicación de RFC 1738 en 1994, se ha especificado que los modelos que proporcionan la representación de datos binarios en un URI deben dividir los datos en bytes de 8 bits y luego codificar porcentualmente cada byte de la misma manera que a continuación. . El valor de byte 0x0F, por ejemplo, debería estar representado por %0F, pero el valor de byte 0x41 puede estar representado por Ao %41. Por lo general, se prefiere el uso de caracteres alfanuméricos o no codificados, así como otros caracteres no reservados , ya que produce URL más cortas.
Datos de caracteresEl procedimiento para la codificación porcentual de datos binarios a menudo se ha extrapolado, a veces de manera inapropiada o no completamente especificado, para aplicarlo a datos basados en caracteres. Durante los primeros días de la World Wide Web , cuando se trataba de procesar caracteres de datos en el directorio ASCII y usar sus bytes ASCII correspondientes como base para determinar el porcentaje de secuencias codificadas, esta práctica era relativamente inofensiva; simplemente se asumió que los caracteres y bytes coincidían entre sí y eran intercambiables. Sin embargo, la necesidad de representar caracteres fuera del rango ASCII ha crecido rápidamente, y los modelos y protocolos de URI a menudo no han logrado proporcionar reglas estandarizadas para preparar datos de caracteres que se incluirán en un URI. Como resultado, las aplicaciones web comenzaron a utilizar varias codificaciones multibyte, dinámicas y de otro tipo que no eran 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 modelos y protocolos de URI basados en RFC 1738 y RFC 2396 asumen que los datos de caracteres se convertirán en bytes de acuerdo con ciertas codificaciones de caracteres antes de ser representados en un URI por caracteres no reservados o por bytes codificados en porcentaje. Si el patrón no permite que el URI proporcione una pista sobre la codificación utilizada, o si la codificación entra en conflicto con el uso de ASCII para codificar porcentualmente caracteres reservados y no reservados, entonces l 'URI no se puede interpretar de manera confiable. Algunos modelos fallan completamente en tomar en cuenta la codificación y, en cambio, simplemente sugieren que los datos de los caracteres corresponden directamente a los caracteres en el URI, dejándolo abierto para que las implementaciones decidan si codificar porcentualmente los datos en el URI y cómo hacerlo. ni en el conjunto reservado ni en el no reservado.
| retour à la ligne | espace | " | % | - | . | < | > | \ | ^ | _ | ` | { | | | } | ~ |
| %0A o %0D o %0D%0A | %20 | %22 | %25 | %2D | %2E | %3C | %3E | %5C | %5E | %5F | %60 | %7B | %7C | %7D | %7E |
A veces, los datos de caracteres arbitrarios se codifican en porcentaje y se utilizan en situaciones distintas de los URI, como programas de supresión de contraseñas u otros protocolos de traducción específicos del sistema .
La sintaxis para URI genérico recomienda que los nuevos esquemas de URI para la representación de los datos de caracteres en un URI representan, sin traducir los caracteres de todos los no reservados , y convertir todos los demás caracteres en bytes según la codificación UTF-8 , para luego codificar estos valores en porcentaje. Esta sugerencia se introdujo enenero 2005con la publicación de RFC 3986. Los patrones de URI introducidos antes de esta fecha no se ven afectados.
La especificación actual no se ocupa de qué hacer con los datos de caracteres codificados. Por ejemplo, en las computadoras, los datos de caracteres se manifiestan en una forma codificada, en algún nivel, por lo que también podrían tratarse como datos binarios o de caracteres cuando se traducen a caracteres URI. Podría decirse que depende de las especificaciones de la plantilla de URI tener en cuenta esta posibilidad y requerir una u otra, pero en la práctica muy pocos, si es que hay alguno, realmente lo hacen.
Existe una codificación no estándar para caracteres Unicode:, donde ---- es una unidad de código UTF-16 representada como cuatro dígitos hexadecimales. Este comportamiento no está especificado por un RFC y ha sido rechazado por el W3C. La octava edición del ECMA-262 , aún incluye una función (escape) usando esta sintaxis, con las funciones y , que se usan para aplicar la codificación UTF-8 a una cadena de caracteres y luego para escapar en porcentaje de los bytes que en resultado. %u----escapeencodeURIencodeURIComponent
Cuando se envían datos que se han ingresado en formularios HTML, los nombres y valores de los campos del formulario se codifican y luego 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 . La codificación utilizada por defecto se basa en una versión primitiva de las reglas de codificación porcentual de URI, con una serie de modificaciones como la estandarización del avance de línea y el reemplazo de espacios con en +lugar de %20. El tipo de medio (MIME) para los datos codificados de esta manera está application/x-www-form-urlencoded, y está definido actualmente (todavía muy obsoleto) 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 de un formulario HTML se envían en una solicitud HTTP GET, se incluyen en la cadena de consulta ( cadena de consulta ) del URI de la solicitud utilizando la misma sintaxis descrita anteriormente. Cuando se envía en una solicitud HTTP POST o por correo electrónico, los datos se colocan en el cuerpo del mensaje y la mención application/x-www-form-urlencodedse incluye en el encabezado Content-Type(tipo de contenido) del mensaje.
Todas las especificaciones a continuación definen y abordan la codificación reservada, no reservada y porcentual, de una forma u otra:
Ejemplo de codificador de URL en VBA (fr)