Quand une interface affiche &, " ou des caractères cassés, on pense souvent qu’il manque un decode. Cette correction peut masquer le symptôme et aggraver le problème. Les bugs d’encoding indiquent généralement que plusieurs couches ne savent pas si une valeur est du texte sémantique, du source HTML ou une sortie déjà échappée. La qualité des données commence par cette distinction.
Définissez la valeur canonique stockée
Pour noms, descriptions et messages, la base devrait stocker du texte Unicode, pas du HTML encodé. La valeur “A & B” comme contenu reste une esperluette. Le template HTML l’échappera; JSON appliquera ses règles; un e-mail texte l’affichera directement.
Stocker des entités HTML dans un champ ordinaire attache la donnée à un canal de présentation et complique recherche, export et édition.
Le HTML riche est un type différent
Si l’application stocke du HTML formaté, le champ doit être nommé et traité comme HTML assaini. Il ne doit pas être confondu avec du texte simple ni rendu raw sans politique. Les types, schémas et conventions de nommage réduisent les devinettes.
Un champ body_html ou un objet de contenu riche est plus clair qu’un content générique dont personne ne connaît la nature.
Décoder seulement lorsque le contrat le dit
Entity decoding est correct lorsqu’une source déclare envoyer des références HTML. L’appliquer à n’importe quel texte peut transformer une séquence visible en caractères significatifs pour le markup. Le décodage répété est particulièrement dangereux.
Une API devrait préciser plain text ou HTML assaini. Le client ne devrait pas deviner à partir de la présence de < ou d’une esperluette.
Le double encoding montre un owner manquant
Si le backend échappe puis le template échappe encore, les entités apparaissent à l’écran. La correction consiste souvent à retirer l’échappement prématuré et à laisser la frontière de sortie faire son travail.
Auto-escaping fonctionne mieux avec des valeurs non échappées. Le raw output reste l’exception pour du HTML de confiance et assaini.
Charset et entités sont des problèmes séparés
Un texte comme café indique généralement des bytes lus avec le mauvais charset, pas un problème d’entités. Les entités représentent des caractères dans HTML; UTF-8 décrit les bytes de ces caractères.
Connexions de base, fichiers, en-têtes HTTP et serializers doivent partager la même politique UTF-8. Les remplacements globaux sans analyse des bytes peuvent détruire des données correctes.
Les migrations legacy demandent classification
Une ancienne colonne peut mélanger texte simple, entités et valeurs doublement encodées. Un decode global casse les entrées où l’utilisateur a volontairement écrit une séquence ressemblant à une entité. Il faut échantillonner, classer, sauvegarder et tester rollback.
Après nettoyage, les write paths doivent être corrigés. Sinon la même dette revient par le prochain import.
Exports et webhooks ont leur propre contrat
Un CSV ou webhook peut devenir la source d’un autre système. S’il contient du HTML encodé sans le dire, le consommateur peut stocker les entités comme contenu ou décoder dangereusement. Chaque sortie doit dire plain text, HTML assaini ou présentation rendue.
Si les deux formes sont nécessaires, exposez deux champs. Un string surchargé force chaque client à deviner.
La réparation de données exige la provenance
Un import ancien peut avoir envoyé du texte simple, un autre du HTML encodé, un troisième des valeurs déjà doublement encodées. Connaître la source et la période permet de corriger par groupes au lieu d’appliquer un decode global risqué.
Après correction, il faut bloquer le write path défectueux. Sinon les nouvelles données recréent le même mélange quelques jours plus tard.
Les éditeurs doivent préserver l’intention utilisateur
Un éditeur de texte simple ne devrait pas convertir automatiquement les séquences ressemblant à des entités. Un éditeur HTML peut normaliser, mais doit afficher le rendu assaini final. L’historique doit distinguer une vraie édition d’une transformation technique.
Les migrations de contenu devraient produire des rapports d’échantillons avant écriture définitive. Voir les valeurs avant et après permet de détecter les cas où un decode aurait changé le sens, pas seulement l’apparence.
Les tests de round trip révèlent la vérité
Faites passer des valeurs représentatives par input, stockage, API, éditeur, export et rendu final. Incluez esperluettes, guillemets, texte non latin, séquences ressemblant à des entités et HTML autorisé. Vérifiez ce que l’utilisateur voit et ce qui reste stocké.
Ajoutez la recherche et l’analytics au même parcours. Une valeur peut être correcte visuellement, mais encore inutilisable pour l’indexation ou les intégrations.
La qualité exige une responsabilité continue
Une migration ponctuelle ne suffit pas si personne ne surveille les nouveaux write paths. Des métriques sur entités visibles, erreurs d’encodage et imports rejetés permettent de détecter le retour du problème. Le propriétaire du schéma doit aussi valider les nouvelles intégrations.
Cette discipline garde le stockage canonique propre au lieu de déplacer sans fin les corrections vers les templates.
Encoding et decoding sont des opérations de frontière, pas des outils généraux de nettoyage. Des contrats clairs entre texte, HTML, URL et données sérialisées éliminent la plupart des artefacts visibles et réduisent les risques d’injection.