L'inteprétation correcte d'un document textuel exige que le codage de caractères soit connu. Les serveurs HTTP actuels, toutefois, n'ajoute généralement pas le paramètre charset approprié à l'en-tête Content-Type. Ce mauvais comportement est même encouragé par l'existence persistante de fureteurs qui déclarent ne pas reconnaître le type de contenu quand ils reçoivent un paramètre charset. Les implémenteurs d'agents-usager sont fortement encouragés à rendre leur logiciel tolérant envers ce paramètre, même s'il ne peuvent en tirer parti. L'étiquetage correct est très désirable, mais quelques mesures peuvent être prises pour compenser son absence :
Pour les cas où l'on arrive à un document à partir d'un hyperlien dans un document d'origine, un attribut CHARSET est ajouté à la liste d'attributs des éléments formant de tels liens (A et LINK), plus précisément en l'ajoutant à l'entité linkExtraAttributes. La valeur de CHARSET est un paramètre charset MIME, qu'un agent-usager pourra considérer comme un indice du codage de caractères utilisé dans le document auquel l'hyperlien réfère.
Il est possible d'intégrer dans tout document HTML une indication du codage de caractères, en ajoutant aussitôt que possible dans l'élément HEAD un élément META comme suit :
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-2022-JP">Cette méthode n'est pas sûre, mais fonctionnera si le codage est tel que les caractères ASCII ne sont pas ambigus au moins jusqu'à l'élément META. Notons qu'un serveur dispose de meilleurs moyens que ce peu fiable META pour connaître le codage de caractères de ses documents ; on trouvera quelques détails et une proposition dans [NICOL2].
En cas de conflit, on considèrera le paramètre charset
reçu de la
source d'un document comme prioritaire, suivi d'un éléme