Les caractères accentués reviennent faux après écriture
Un enregistrement texte déclare l'encodage qu'il emploie, et un outil qui en écrit un pendant qu'un autre en suppose un différent produit des accents abîmés à la lecture. Les caractères sont intacts sur le tag ; ce qui cloche, c'est l'accord sur la façon de les interpréter.
L'enregistrement déclare son encodage
Un enregistrement texte porte plus que les caractères. Il porte aussi une indication de la façon dont ces caractères sont encodés, et un code de langue.
Un lecteur emploie cette indication pour retransformer des octets en lettres. Quand la déclaration et la réalité concordent, les accents reviennent exactement comme ils ont été écrits.
Quand elles divergent, les octets sont intacts et l'interprétation est fausse, et c'est pourquoi le résultat est abîmé plutôt qu'absent.
Les caractères hors de la plage latine sans accent coûtent aussi plus d'un octet chacun, si bien qu'un texte accentué prend plus de place que son nombre de caractères ne le laisse croire.
Où cela dérape
Un outil d'écriture qui déclare un encodage et en écrit un autre. Le tag se contredit alors lui-même et tous les lecteurs se trompent.
Un outil de lecture qui ignore la déclaration et suppose un encodage par défaut. Le tag est correct et c'est un lecteur particulier qui l'affiche mal.
Un contenu collé depuis une source dans un autre encodage, qui peut arriver déjà abîmé à l'outil d'écriture. Le tag stocke alors fidèlement des caractères qui étaient faux avant d'y arriver.
Lisez le tag avec un second outil pour distinguer ces cas. Si deux lecteurs divergent, le tag va bien et un lecteur se trompe. Si les deux affichent la même erreur, le tag porte ce qui a été écrit.
Les adresses sont un cas à part
Une adresse web n'est pas du texte libre. Les caractères hors du jeu autorisé doivent être encodés en pourcentage, et une adresse contenant des caractères accentués bruts peut ne pas fonctionner même stockée parfaitement.
Certains outils les encodent pour vous et d'autres non, et c'est pourquoi une adresse à chemin accentué peut se comporter différemment selon ce qui l'a écrite.
Les noms de domaine internationalisés ont leur propre conversion, faite par le navigateur plutôt que par le tag.
Le tag stocke fidèlement les caractères dans tous ces cas. Ce qui varie, c'est de savoir si ce qui a été stocké était une adresse valide.
L'éviter entièrement
Employez des caractères sans accent dans tout ce qui est écrit directement sur un tag quand le sens y survit. Ce n'est pas élégant et cela supprime toute une classe d'échecs.
Gardez le texte accentué sur une page plutôt que sur un tag, et écrivez une adresse courte à la place. Une page web maîtrise son propre encodage et s'affiche correctement partout.
Testez avec le texte réel sur un téléphone qui n'est pas celui avec lequel vous avez écrit, un outil d'écriture qui relit sa propre production pouvant masquer un désaccord.
Et vérifiez la longueur après toute modification d'un contenu accentué, ces caractères coûtant plus d'un octet et un message qui tenait pouvant cesser de tenir.
Questions fréquentes
Le tag stocke-t-il les mauvais caractères ?
D'ordinaire non. Les octets sont intacts et l'interprétation est fausse, et c'est pourquoi le résultat est abîmé plutôt que vide.
Les accents prennent-ils plus de place ?
Oui. Les caractères hors de la plage latine sans accent coûtent plus d'un octet chacun, donc un texte accentué est plus gros que son nombre de caractères.
Pourquoi deux applications l'affichent-elles différemment ?
Parce que l'une honore l'encodage déclaré et l'autre suppose un encodage par défaut. Ce désaccord est le défaut.
Puis-je mettre des accents dans une URL sur un tag ?
Ils doivent être encodés en pourcentage pour être valides, et tous les outils ne le font pas pour vous. Un chemin sans accent évite la question.