À propos
Découvrez URL Decode and Encode, un outil en ligne simple qui fait exactement ce qu'il dit : il décode à partir d'un codage d'URL et encode dans celui-ci rapidement et facilement. Encodez vos données dans l'URL sans problème ou décodez-les dans un format lisible.
Le codage URL, également connu sous le nom d' « encodage-pourcent », est un mécanisme de codage des informations dans un identificateur de ressources uniformes (URI). Bien qu'il soit connu sous le nom de codage URL, il est en fait utilisé plus généralement dans le cadre de l'ensemble principal des identificateurs de ressources uniformes (URI), qui comprend à la fois les localisateurs uniformes de ressource (URL) et les noms uniformes de ressource (URN). En tant que tel, il est également utilisé dans la préparation des données du type de média « application/x-www-form-urlencoded », comme c'est souvent le cas lors de la soumission de données de formulaire HTML dans les demandes HTTP.
Options avancées
(*) Ces options ne peuvent pas être activées simultanément car le résultat obtenu ne serait pas valable pour la majorité des applications.Le codage URL, également connu sous le nom d' « encodage-pourcent », est un mécanisme de codage des informations dans un identificateur de ressources uniformes (URI). Bien qu'il soit connu sous le nom de codage URL, il est en fait utilisé plus généralement dans le cadre de l'ensemble principal des identificateurs de ressources uniformes (URI), qui comprend à la fois les localisateurs uniformes de ressource (URL) et les noms uniformes de ressource (URN). En tant que tel, il est également utilisé dans la préparation des données du type de média « application/x-www-form-urlencoded », comme c'est souvent le cas lors de la soumission de données de formulaire HTML dans les demandes HTTP.
Options avancées
- Jeu de caractères : Notre site Web utilise le jeu de caractères UTF-8, vos données d'entrée sont donc transmises dans ce format. Modifiez cette option si vous souhaitez convertir les données dans un autre jeu de caractères avant de les encoder. Notez que dans le cas de données textuelles, le schéma d'encodage ne contient pas le jeu de caractères, vous devrez donc peut-être spécifier le jeu approprié pendant le processus de décodage. En ce qui concerne les fichiers, l'option binaire est l'option par défaut, qui omettra toute conversion ; cette option est toujours requise sauf pour les textes bruts.
- Séparateur de nouvelle ligne : Les systèmes Unix et Windows utilisent des caractères de saut de ligne différents, donc avant l'encodage, l'une ou l'autre variante sera remplacée dans vos données par l'option sélectionnée. Pour la section des fichiers, ce n'est pas totalement pertinent puisque les fichiers contiennent déjà les séparateurs correspondants, mais vous pouvez définir lequel utiliser pour les fonctions « encodez chaque ligne séparément » et « divisez les lignes en segments ».
- Encodez chaque ligne séparément : Même les caractères d'une nouvelle ligne sont convertis en leur forme codée en pourcent. Utilisez cette option si vous souhaitez encoder plusieurs entrées de données indépendantes séparées par des sauts de ligne. (*)
- Divisez les lignes en segments : Les données encodées deviendront un texte continu sans aucun espace, cochez donc cette option si vous souhaitez les diviser en plusieurs lignes. La limite de caractères appliquée est définie dans la spécification MIME (RFC 2045), qui précise que les lignes encodées ne doivent pas dépasser 76 caractères. (*)
- Mode direct : Lorsque vous activez cette option, les données saisies sont encodées immédiatement avec les fonctions JavaScript intégrées de votre navigateur, sans envoyer d'informations à nos serveurs. Actuellement, ce mode ne prend en charge que le jeu de caractères UTF-8.
Sûreté et protection
Toutes les communications avec nos serveurs passent par des connexions sécurisées cryptées SSL (https). Nous supprimons de nos serveurs les fichiers téléchargés immédiatement après leur traitement et le fichier téléchargeable obtenu est supprimé juste après la première tentative de téléchargement ou après 15 minutes d'inactivité (la période la plus courte étant retenue). Nous ne conservons ni inspections en aucune façon le contenu des données soumises ou des fichiers téléchargés. Vous trouverez plus de détails dans la politique de confidentialité ci-dessous.
Entièrement gratuit
L'utilisation de notre outil est gratuite. Désormais, vous n'avez plus besoin de télécharger un logiciel pour des tâches aussi simples.
Détails du codage de l'URL
Types de caractères URI
Les caractères autorisés dans un URI sont soit réservés, soit non réservés (ou un caractère de pourcentage dans le cadre d'un encodage-pourcent). Les caractères réservés sont des caractères qui ont parfois une signification particulière. Par exemple, le slash est utilisé pour séparer différentes parties d'une URL (ou plus généralement d'une URI). Les caractères non réservés n'ont pas de signification particulière. Avec l'encodage-pourcent, les caractères réservés sont représentés par des séquences de caractères spéciales. Les ensembles de caractères réservés et non réservés, les circonstances dans lesquelles certains caractères réservés ont une signification spéciale ont légèrement changé à chaque nouvelle révision des spécifications qui régissent les URI et les schémas URI.
| RFC 3986 section 2.2 Caractères réservés (janvier 2005) | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
! |
* |
' |
( |
) |
; |
: |
@ |
& |
= |
+ |
$ |
, |
/ |
? |
# |
[ |
] |
| RFC 3986 section 2.3 Caractères non réservés (janvier 2005) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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 |
- |
_ |
. |
~ |
||||||||||||
Les autres caractères d'un URI doivent être codés en pourcent.
Encodage-pourcent des caractères réservés
Lorsqu'un caractère de l'ensemble réservé (un « caractère réservé ») a une signification spéciale (un « objectif réservé ») dans un contexte particulier et qu'un schéma URI indique qu'il est nécessaire d'utiliser ce caractère pour un autre objectif, le caractère doit être codé en pourcent. L'encodage-pourcent d'un caractère réservé consiste à convertir le caractère en sa valeur d'octet correspondante en ASCII, puis à représenter cette valeur sous la forme d'une paire de chiffres hexadécimaux. Ces chiffres, précédés du signe de pourcentage (« % »), sont ensuite utilisés dans l'URI à la place du caractère réservé. (Pour un caractère non ASCII, il 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-dessus.)
Le caractère réservé « / », par exemple, s'il est utilisé dans le composant « path » d'un URI, a la signification particulière d'être un délimiteur entre les segments de chemin. Si, selon un schéma URI donné, « / » doit figurer dans un segment de chemin, les trois caractères « %2F » (ou « %2f ») doivent être utilisés dans le segment à la place de « / ».
| Caractères réservés après l'encodage-pourcent | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
! |
# |
$ |
& |
' |
( |
) |
* |
+ |
, |
/ |
: |
; |
= |
? |
@ |
[ |
] |
%21 |
%23 |
%24 |
%26 |
%27 |
%28 |
%29 |
%2A |
%2B |
%2C |
%2F |
%3A |
%3B |
%3D |
%3F |
%40 |
%5B |
%5D |
Les caractères réservés qui n'ont pas d'utilité réservée dans un contexte particulier peuvent également être encodés en pourcent mais ne sont pas sémantiquement différents des autres caractères.
Dans la composante « requête » d'un URI (la partie qui suit le caractère « ? »), par exemple, « / » est toujours considéré comme un caractère réservé, mais il n'a normalement pas d'usage réservé (sauf si un schéma URI particulier en dispose autrement). Le caractère n'a pas besoin d'être codé en pourcentage lorsqu'il n'est pas réservé.
Les URI qui diffèrent uniquement par le fait qu'un caractère réservé est encodé en pourcent ou non sont normalement considérés comme non équivalents (désignant la même ressource), sauf s'il s'avère que les caractères réservés en question n'ont pas de fonction réservée. Cette détermination dépend des règles établies pour les caractères réservés par les différents schémas URI.
Encodage-pourcent des caractères non réservés
Les caractères de l'ensemble non réservé ne doivent jamais être encodés en 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, les consommateurs d'URI ne devraient pas traiter « %41 » différemment de « A » (« %41 » est le codage en pourcent de « A ») ou « %7E » différemment de « ~ », mais certains le font. Pour une interopérabilité maximale, il est donc déconseillé aux producteurs d'URI de coder en pourcent les caractères non réservés.
L'encodage-pourcent du caractere pour cent
Comme le caractère pourcent (« % ») sert d'indicateur pour les octets codés en pourcent, il doit être codé en pourcent comme « %25 » pour que cet octet soit utilisé comme donnée dans un URI.
L'encodage-pourcent de données arbitraires
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.
Données binaires
Depuis la publication de la RFC 1738, 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. 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 « A » ou « %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.
Données de caractères
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 et RFC 2396 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.
| Caractères communs après l'encodage-pourcent (basé sur ASCII ou UTF-8) | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| nouvelle ligne | espace | " |
% |
- |
. |
< |
> |
\ |
^ |
_ |
` |
{ |
| |
} |
~ |
%0A ou %0D ou %0D%0A |
%20 |
%22 |
%25 |
%2D |
%2E |
%3C |
%3E |
%5C |
%5E |
%5F |
%60 |
%7B |
%7C |
%7D |
%7E |
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.