Encodage-pourcent

Les caractères autorisés dans un URI sont soit réservés (reserved) soit non réservés (unreserved). Ce peut aussi être un caractère de pourcentage % dans le cadre d'un encodage-pourcent. Les caractères réservés sont ceux qui ont parfois une signification particulière. Par exemple, le caractère de barre oblique est utilisé pour séparer les différentes parties de l'URL (ou, plus généralement, d'un URI). Les caractères non réservés n'ont pas une telle signification. Par le biais de l’encodage-pourcent, les caractères réservés sont représentés à l'aide de séquences de caractères. Les ensembles de caractères réservés et non réservés, de même que les circonstances dans lesquelles certains caractères réservés adoptent une signification spéciale, ont légèrement changé avec chaque révision des spécifications qui régissent les URI et les modèles d'URI.

D'autres caractères dans un URI doivent être encodés en pourcent.

Quand un caractère de l'ensemble réservé (un « caractère réservé ») a une signification spéciale (qu'il est « réservé dans un but ») dans un certain contexte, et qu'un schéma d'URI nécessite d'utiliser le caractère pour certains autres buts, le caractère doit être encodé en pourcent. Encoder en pourcent un caractère réservé implique de convertir le caractère à la valeur correspondante de son octet en ASCII, puis de représenter alors cette valeur sous la forme d'une paire de chiffres hexadécimaux. Les chiffres, précédés par un signe de pourcentage (%) qui est utilisé comme un caractère d'échappement, sont ensuite introduits dans l'URI à la place des caractères réservés. (Dans le cas d'un caractère non ASCII, celui-ci est généralement converti en sa séquence d'octets en UTF-8, puis chaque valeur d'octet est représentée comme ci-dessous.)

Le caractère réservé, /, par exemple, s'il est utilisé dans la composante « chemin » d'un URI, aura le sens particulier de délimiteur entre les segments du chemin. Si, selon un schéma d'URI, / doit se trouver à l'intérieur d'un segment de chemin, alors les trois caractères %2F ou %2f devront être utilisés dans le segment au lieu d'un / brut.

Les caractères réservés qui n'ont pas de but réservé dans un contexte particulier peuvent également être encodés en pourcent, mais ne sont pas sémantiquement différents de ceux qui ne le sont pas.

Dans la partie « chaîne de requête » (query string) d'un URI (la partie après un caractère ?), par exemple, / est encore considéré comme un caractère réservé, mais il n'a normalement pas de but réservé, sauf si un schéma particulier d'URI déclare le contraire. Le caractère n'a donc pas besoin d'être encodé en pourcent lorsqu'il n'a pas de but réservé.

Deux URI qui diffèrent uniquement par le fait qu'un caractère réservé est encodé en pourcent dans l'un, alors qu'il apparaît tel quel dans l'autre, ne sont normalement pas considérés comme équivalents (désignant la même ressource), sauf s'il peut être établi que le caractère réservé en question n'a pas de but réservé. Cette détermination dépend des règles établies par chaque schéma d'URI pour les caractères réservés.

Les caractères de l'ensemble non réservé ne nécessitent jamais d’encodage-pourcent.

Les URI qui ne diffèrent que par le fait qu'un caractère non réservé est encodé en pourcent ou qu'il apparaît tel quel sont équivalents par définition, mais les interpréteurs d'URI, dans la pratique, peuvent ne pas toujours reconnaître cette équivalence. Par exemple, ils ne devraient pas traiter la chaîne %41 différemment du A ou %7E différemment de ~, mais certains le font. Pour un maximum d'interopérabilité, il est déconseillé aux producteurs d'URI d'encoder en pourcent les caractères non réservés.

Parce que le caractère de pourcentage (%) sert d'indicateur pour les octets encodés en pourcent, il doit être lui-même encodé sous la forme %25 s'il doit être utilisé comme donnée au sein d'un URI.

La plupart des modèles d'URI impliquent la représentation de données arbitraires, telles que l'adresse IP ou un chemin dans un système de fichiers, en tant que composantes d'un URI. Les spécifications du schéma d'URI devraient, mais ne le font souvent pas, fournir une correspondance explicite entre les caractères de l'URI et toutes les valeurs de données possibles étant représentées par ces caractères.

Depuis la publication de la RFC 1738[3], en 1994, il a été spécifié que les modèles qui prévoient la représentation de données binaires dans un URI doivent diviser les données en octets de 8 bits puis encoder en pourcent chaque octet de la même manière que ci-dessus[4]. La valeur d'octet 0x0F, par exemple, devrait être représenté par %0F, mais la valeur d'octet 0x41 peut être représentée par Aou %41. L'utilisation de caractères non encodés ou alphanumériques, ainsi que d'autres caractères non réservés, est généralement préférée car elle produit des URL plus courtes.

La procédure pour encoder en pourcent des données binaires a souvent été extrapolée, parfois de manière inappropriée ou sans être pleinement spécifiée, afin d'être appliquée aux données basées sur les caractères. Durant les débuts du World Wide Web, lorsqu'il s'agissait de traiter les caractères de données du répertoire ASCII et d'utiliser leurs octets correspondants en ASCII en tant que base pour déterminer les séquences encodées en pourcent, cette pratique était relativement inoffensive; il était simplement supposé que les caractères et les octets se correspondaient mutuellement et étaient interchangeables. Le besoin de représenter les caractères en dehors de la plage ASCII a toutefois grandi rapidement et les modèles d'URI ainsi que les protocoles ont souvent échoué à fournir des règles standardisées pour la préparation des données de caractères devant être inclus dans un URI. En conséquence, les applications Web ont commencé à faire usage de différents encodages multi-octets, dynamiques, et d'autres qui n'étaient pas compatibles avec ASCII, en tant que base pour l’encodage-pourcent, ce qui conduisit à des ambiguïtés et de la difficulté pour interpréter les URI de manière fiable.

Par exemple, de nombreux modèles d'URI et des protocoles basés sur les RFC 1738[3] et RFC 2396[5] présument que les données de caractères seront converties en octets selon certains codages de caractères avant d'être représentés dans un URI par des caractères non réservés ou par des octets encodés en pourcent. Si le modèle ne permet pas à l'URI de fournir un indice quant à l'encodage utilisé, ou si l'encodage entre en conflit avec l'utilisation de l'ASCII pour encoder en pourcent des caractères réservés et non réservés, alors l'URI ne peut pas être interprété de manière fiable. Certains modèles échouent complètement à tenir compte de l'encodage et suggèrent simplement à la place que les données de caractères correspondent directement aux caractères de l'URI, ce qui laisse le champ libre aux implémentations pour décider si et comment encoder en pourcent les données des caractères qui ne sont ni dans l'ensemble des réservés ni dans celui des non réservés.

Des données de caractères arbitraires sont parfois encodées en pourcent et utilisées dans des situations distinctes des URI, comme c'est le cas des programmes d'offuscation de mot de passe, ou d'autres protocoles de traduction spécifiques au système.

La syntaxe d'URI générique recommande que les nouveaux modèles d'URI pour la représentation des données de caractère dans un URI représentent, sans les traduire, les caractères de l'ensemble non réservé, et convertissent tous les autres caractères en octets selon le codage UTF-8, pour encoder ensuite ces valeurs en pourcent. Cette suggestion a été introduite en janvier 2005 avec la publication de la RFC 3986[2]. Les modèles d'URI introduits avant cette date ne sont pas concernés.

La spécification actuelle ne traite pas de ce qu'il faut faire avec les données de caractères encodés. Par exemple, dans les ordinateurs, les données de caractère se manifestent sous une forme codée, à un certain niveau, et pourraient donc aussi bien être traitées comme des données binaires ou de caractères lorsqu'elles sont traduites en caractères d'URI. C'est sans doute aux spécifications de modèles d'URI de tenir compte de cette possibilité et de requérir l'un ou l'autre, mais dans la pratique, très peu, si tant est qu'il y en ait, le font réellement.

Il existe un encodage non standard pour les caractères Unicode : %u----, dans lequel ---- est une unité de code UTF-16 représentée comme quatre chiffres hexadécimaux. Ce comportement n'est pas spécifié par une RFC et a été rejeté par le W3C. La huitième édition de l'ECMA-262, comporte encore une fonction escape (échappement) utilisant cette syntaxe, avec les fonctions encodeURI et encodeURIComponent, qui servent à appliquer l'encodage UTF-8 à une chaîne de caractères puis à échapper en pourcent les octets qui en résultent[6].