Encodeur HTML
Protégez votre texte en convertissant les caractères spéciaux en entités HTML.
Les cinq caractères qui changent tout
Le HTML reconnaît cinq caractères comme des symboles structurels : < et > (balises), & (début d’entité), et les guillemets simples et droits (attributs). Si votre contenu doit afficher ces caractères littéralement — par exemple, une leçon sur la syntaxe HTML ou un script jQuery — vous devez les transformer en codes HTML inoffensifs. C’est l’encodage.
Les cinq caractères et leurs codes
| Caractère | Code d’entité | Utilité |
|---|---|---|
| < | < | Afficher un crochet ouvrant sans créer une balise |
| > | > | Afficher un crochet fermant sans fermer la balise |
| & | & | Afficher une esperluette sans commencer une entité |
| " | " | Utiliser un guillemet dans un attribut |
| ’ | ' | Utiliser une apostrophe sans confusion |
Quand vous avez besoin d’encoder
Vous documentez du code HTML ou JavaScript sur votre site, et vous voulez afficher un exemple de balise sans que le navigateur la traite comme du markup. Vous insérez du contenu utilisateur dans une page HTML et vous voulez bloquer les injections XSS (une attaque où quelqu’un tente d’injecter du JavaScript malveillant). Vous générez du HTML à partir d’une base de données et vous devez échapper les entrées non approuvées. Un CMS qui stocke du HTML littéral.
Ce qui se produit si vous ne codez pas
- Un < non échappé peut créer une balise parasite et casser votre HTML
- Un & non échappé peut créer une entité accidentelle, affichant le mauvais caractère
- Un guillemet non échappé peut fermer un attribut de manière inattendue
- Du JavaScript injecté peut s’exécuter (risque de sécurité)
- Le texte s’affiche incorrectement ou casse le rendu de la page
Encodage et sécurité, ce que vous devez savoir
L’encodage HTML n’est pas à lui seul une stratégie de sécurité complète. Il protège contre les erreurs d’interprétation du navigateur, mais un utilisateur malveillant ingénieux peut trouver d’autres vecteurs d’attaque — à travers les attributs, les URLs, ou les event handlers. Cependant, c’est un élément fondamental. Toute données non approuvée doit être encodée avant d’être insérée dans du HTML. C’est la première défense, et elle fonctionne. Des frameworks modernes comme React ou Vue encodent automatiquement par défaut, ce qui est une bonne pratique qui s’est généralisée.
Questions sur l’encodage HTML
L’encodage rend-il mon texte moins lisible en HTML ?
Non, visuellement c’est identique. L’utilisateur voit les caractères normaux. Le code source contient les entités, mais le navigateur les convertit automatiquement.
Dois-je encoder tout le texte ?
Non, seulement les caractères spéciaux au HTML. Le texte normal (lettres, chiffres, espaces) ne change pas.
L’encodage ralentit-il la page ?
Imperceptiblement. Le navigateur décode les entités très vite. L’impact sur la performance est nul.
Puis-je mélanger du HTML encodé et du HTML normal sur la même page ?
Oui, sans problème. Vous encodez seulement ce qui doit l’être, vous laissez le reste comme du HTML normal.
Y a-t-il des cas où l’encodage est dangereux ?
Non, l’encodage en lui-même est une protection, jamais une menace. C’est une bonne pratique de sécurité.