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ément META comme
ci-dessus dans le document et finalement de l'éventuel attribut CHARSET
d'un hyperlien menant à ce document.
Quand du texte HTML est transmis directement en UCS-2 ou UCS-4, la question de l'ordre des octets se pose : est-ce que l'octet de poids fort de chaque caractère arrive en premier ou en dernier ? Par souci de netteté, il est recommandé de transmettre les octets UCS-2 ou UCS-4 en ordre décroissant de poids, ce qui correspond à l'ordre établi sur Internet pour les quantités à 2 ou 4 octets, à l'exigence de l'ISO 10646 et à la recommandation Unicode pour la transmission en série et au RFC 1641. Pour optimiser les chances d'interprétation correcte, il est de plus recommandé que les documents en UCS-2 ou UCS-4 débutent toujours par un caractère ESPACE INSÉCABLE À CHASSE NULLE (FEFF ou 0000FEFF hex.) qui, lorsqu'inversé, devient FFFE ou FFFE0000, un caractère garanti inutilisé. Ainsi, un agent-usager qui reçoit FFFE au début d'un texte saura que les octets doivent être inversés pour le reste.
En plus d'UCS-2 et UCS-4, on peut transmettre des données du JUC selon un format de transformation UCS. UTF-7 [RFC1642] et UTF-8 [UTF-8] ont des propriétés favorables (pas de problème d'ordre des octets, différentes saveurs de compatibilité ASCII) qui les rendent dignes d'intérêt, surtout pour la transmission de texte multilingue. Un autre codage, MNEM [RFC1345], a aussi des propriétés intéressantes et est capable de transmettre tout le JUC. Le format de transformation UTF-1 de l'ISO 10646:1993 (enregistré par l'IANA sous le nom ISO-10646-UTF-1), a été retiré de l'ISO 10646 par l'amendement 4, et ne devrait plus être utilisé.