Vous avez à traiter le format codé en URL ? Alors ce site est parfait pour vous ! Utilisez notre outil en ligne super pratique pour encoder ou décoder vos données.

Décoder « puissent » à partir d'un format codé en URL

Pour les binaires encodés (comme les images, les documents, etc.), utilisez le formulaire de téléchargement de fichiers un peu plus bas sur cette page.

Décoder les fichiers à partir du format codé URL

Cliquez (ou appuyez) ici pour sélectionner un fichier
La taille maximale des fichiers est de 192MB. N'exécutez pas les fichiers décodés provenant de sources non fiables.

À 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
  • Jeu de caractères : Dans le cas de données textuelles, le schéma d'encodage ne contient pas le jeu de caractères, vous devez donc spécifier quel jeu de caractères a été utilisé pendant le processus d'encodage. Il s'agit généralement d'UTF-8, mais il peut y en avoir beaucoup d'autres ; si vous n'êtes pas sûr, essayez les options disponibles ou l'option de détection automatique. Cette information est utilisée pour convertir les données décodées dans le jeu de caractères de notre site Web afin que toutes les lettres et tous les symboles puissent être affichés correctement. Notez que cela n'a pas d'importance pour les fichiers puisqu'aucune conversion sécurisée pour le Web ne doit leur être appliquée.
  • Décoder chaque ligne séparément : Les données codées sont généralement constituées d'un texte continu, de sorte que même les caractères d'une nouvelle ligne sont convertis dans leur forme codée en pourcent. Avant le décodage, tous les espaces non encodés sont supprimés de l'entrée afin d'en préserver l'intégrité. Cette option est utile si vous avez l'intention de décoder plusieurs entrées de données indépendantes qui sont séparées par des sauts de ligne.
  • Mode direct : Lorsque vous activez cette option, les données saisies sont immédiatement décodées 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.
Passer à la version bureau
2012-2024 urldecoder.org
Politique de confidentialité Contact
Ce site web utilise des cookies. Nous utilisons les cookies pour personnaliser le contenu/les annonces et pour analyser notre trafic.