Codificación de URL

La codificación de URL ( codificación de URL , también conocida como codificación de porcentaje ) es un mecanismo que se utiliza para codificar información en una URL en determinadas condiciones . Para la codificación solo se utilizan ciertos caracteres del juego de caracteres ASCII .

Sin esta codificación, parte de la información no se podría representar en una URL. Por ejemplo, el navegador suele interpretar un espacio como el final de la URL; los caracteres siguientes se ignorarían o generarían un error. Con la codificación de URL, se puede pasar un espacio a través de la cadena de caracteres %20. RFC 3986 define un estándar sobre cómo un URI (y por lo tanto también una URL) debe estructurarse sintácticamente y bajo qué condiciones se usa la codificación de URL.

La codificación URL con el símbolo de porcentaje también se utiliza para caracteres que no están incluidos en el juego de caracteres ASCII . Sin embargo, hasta ahora solo ha habido una recomendación en RFC 3986; aún falta un estándar vinculante.

Caracteres reservados y no reservados

Las URL pueden constar de las siguientes partes: 

https://maxmuster:[email protected]:8080/index.html?p1=A&p2=B#ressource
\___/   \_______/ \____/ \_____________/ \__/\_________/ \_______/ \_______/
  |         |       |           |         |       |          |         |
Schema      |    Kennwort      Host      Port    Pfad      Query    Fragment
         Benutzer

Ciertos caracteres dentro de esta expresión identifican y separan los segmentos individuales de la URL y permiten que la expresión se descomponga y procese. En el caso de acceso HTTP , por ejemplo:

Otros caracteres tienen significados específicos en la ruta del documento . Los siguientes caracteres están reservados:

  • : / ? # [ ] @ ! $ & ' ( ) * + , ; =

Los siguientes caracteres no están reservados, por lo que no tienen un significado predefinido en una URL:

  • Letras: A–Z, a–z
  • Dígitos: 0–9
  • - . _ ~

Representación porcentual

Una URL consta de los caracteres reservados y no reservados con nombre. No puede contener ningún otro carácter. En principio, sin embargo, es necesario poder representar cualquier secuencia de bytes en las URL , es decir, todos los valores entre 0 y 255. Además, debe haber una forma de poder escribir caracteres reservados en una URL de tal manera que pierdan su significado especial (ver también secuencia de escape ).

La representación porcentual de personajes tiene en cuenta ambos requisitos. Se basa en un proceso de codificación que asigna una combinación de caracteres de tres dígitos a cada código de carácter, comenzando con el signo de porcentaje, seguido de la representación hexadecimal de dos dígitos del código de carácter.

Un carácter reservado debe escribirse en forma de porcentaje codificado en una URL si tiene un significado especial en el lugar donde se encuentra, pero no debe tenerlo en el contexto actual. Los caracteres no reservados pueden, pero no deben, estar codificados en porcentaje. Con otros caracteres (incluidos los datos binarios), generalmente no hay otra opción que mostrarlos en una URL en forma de porcentaje codificado (excepción: carácter reservado +'' en lugar de un espacio en la cadena de consulta).

Ejemplo:

Según ASCII, #el código de carácter hexadecimal 23 se asigna al carácter ''. Por tanto, la expresión %23'' representa la forma codificada en porcentaje del carácter #''.

La interpretación de:

http://www.example.net/index.html?session=A54C6FE2#info

es claro. Se sessiondefinió un parámetro de URL denominado al que se A54C6FE2asigna el valor y se infoespecificó el ancla del documento nombrado . En #el contexto actual, el carácter "" tiene el significado especial de que va seguido del nombre de un ancla de documento. Si pierde este significado, i. H. Si sessionel valor se A54C6FE2#infoasigna al parámetro de URL , el carácter #"" debe estar codificado en porcentaje en la URL:

http://www.example.net/index.html?session=A54C6FE2%23info

En la práctica, este mecanismo no siempre se aplica de forma coherente. Sin embargo, hay casos en los que es necesario utilizarlo, por ejemplo, cuando se llama a un ancla a través de un servicio de desreferidor .

Caracteres ASCII relevantes en porcentajes

␣ ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] { | }
%20 %21 %22 %23 %24 %25 %26 %27 %28 %29 %2A %2B %2C %2D %2E %2F %3A %3B %3C %3D %3E %3F %40 %5B %5C %5D %7B %7C %7D

Caracteres no ASCII

Los bytes también se %codifican con un "" precedente para los caracteres que no están contenidos en el juego de caracteres ASCII . Sin embargo, la secuencia de bits que representa un carácter depende de la codificación de caracteres que se utilice. Si bien el RFC 3986 recomienda que se use UTF-8 para la codificación, ya que este formato Unicode se puede usar para todos los caracteres internacionales, que UTF-8 al hacer la codificación estándar de facto para URI, pero aún no existe un estándar explícito . Para poder codificar la URL, debe saber o adivinar qué codificación de caracteres se usó para el archivo a llamar o qué codificación está usando la computadora de destino. Por esta razón, todavía tiene sentido usar solo caracteres del repositorio ASCII.

En la codificación UTF-8 recomendada, por ejemplo, la letra “ö” (con el valor de carácter decimal Unicode 246) se %C3%B6mostraría como. Todos los valores de caracteres por encima de 127 están representados por UTF-8 como combinaciones de dos o más bytes y, en consecuencia, se incluyen en la codificación porcentual. Los caracteres del alfabeto latino (ampliado con signos diacríticos ) se representan todos con dos bytes. Los caracteres CJK , por ejemplo, requieren más bytes .

A veces, ISO 8859-1 (Latin-1) todavía se usa para la representación y su valor de carácter decimal idéntico 246 se inserta directamente en la URL con la ayuda de la codificación porcentual. La diéresis "ö" se %F6muestra como un valor .

Sin embargo, ambos tipos de representación transmiten diferentes secuencias de bits al servidor. Aunque ambos están codificados correctamente según su tipo, solo uno de ellos entrega el archivo deseado y el otro generalmente solo un mensaje de error. Con algunos servidores, como los de Wikipedia, se intenta determinar la codificación para que luego se pueda reenviar el archivo correcto. Si una codificación no funciona, pruebe una de las otras variantes probables.

Singularidad de la decodificación de caracteres

Los caracteres ASCII codificados individualmente (por ejemplo, %23para #) se codifican de forma idéntica en ASCII , UTF-8 y la mayoría de las otras codificaciones comunes, como ISO 8859-15.

La codificación es incierta para los números del 128 al 255: o es una secuencia de código UTF-8 (o su comienzo) o una codificación para un conjunto de caracteres limitado de 256 caracteres como ISO 8859-15. Debido a que solo se permiten ciertos códigos consecutivos en UTF-8, las codificaciones limitadas y UTF-8 se pueden diferenciar con cierta probabilidad: %C3%B6según UTF-8, el carácter "ö" será bastante seguro (y no la cadena de caracteres según ISO 8859 -15 ö).

Codificación de formulario

El tipo MIMEapplication/x-www-form-urlencoded se puede utilizar para identificar datos codificados en URL. Al enviar información de formulario web mediante el método POST , este tipo de MIME se especifica como el tipo de contenido . Por razones históricas, la codificación no coincide exactamente con la codificación en las URL; en particular, un espacio no se codifica con %20"", sino con un único +"".

enlaces web

  • RFC 3986 - Identificador uniforme de recursos (URI): sintaxis genérica
  • RFC 3987 - Los identificadores de recursos internacionalizados (IRI) ofrecen una alternativa claramente distinguible a la representación de URI con caracteres Unicode y utilizan una variante extendida de la codificación de URL
  • Herramienta de codificación de URL

Evidencia individual

  1. ↑ Especificación HTML 4.01: 17.13.4 Tipos de contenido de formulario 24 de diciembre de 1999.