Unicode et HTML

Les pages Web créées à l'aide du langage HTML (HyperText Markup Language ) peuvent contenir du texte multilingue représenté avec le jeu de caractères universel Unicode. La relation entre Unicode et HTML repose sur la relation entre le « jeu de caractères du document », qui définit l'ensemble des caractères pouvant être présents dans un document HTML et leur attribue des numéros, et le « codage de caractères externe », ou « charset », utilisé pour coder un document donné sous la forme d'une séquence d'octets.

Dans la RFC 1866, la norme HTML 2.0 initiale, le jeu de caractères du document a été défini comme ISO-8859-1 (la norme HTML ultérieure utilise par défaut le codage Windows-1252 ). Il a été étendu à ISO 10646 (qui est fondamentalement équivalent à Unicode) par la RFC 2070. Il ne varie pas entre les documents de différentes langues ou créés sur différentes plates-formes. Le codage de caractères externe est choisi par l'auteur du document (ou le logiciel qu'il utilise pour créer le document) et détermine la manière dont les octets utilisés pour stocker et/ou transmettre le document correspondent aux caractères du jeu de caractères du document. Les caractères non présents dans le codage de caractères externe choisi peuvent être représentés par des références d'entités de caractères.

La relation entre Unicode et HTML est un sujet délicat pour de nombreux professionnels de l'informatique, auteurs de documents et utilisateurs Web . La représentation précise du texte dans les pages Web à partir de différentes langues naturelles et systèmes d'écriture est compliquée par les détails du codage des caractères , de la syntaxe du langage de balisage , des polices et des différents niveaux de prise en charge par les navigateurs Web .

Les pages Web sont généralement des documents HTML ou XHTML . Les deux types de documents sont constitués, à un niveau fondamental, de caractères , qui sont des graphèmes et des unités de type graphème, indépendamment de la manière dont ils se manifestent dans les systèmes de stockage et les réseaux informatiques .

Un document HTML est une séquence de caractères Unicode. Plus précisément, les documents HTML 4.0 doivent être constitués de caractères du jeu de caractères du document HTML : un répertoire de caractères dans lequel à chaque caractère est attribué un point de code entier non négatif unique . Cet ensemble est défini dans la DTD HTML 4.0 , qui établit également la syntaxe (séquences de caractères autorisées) qui peut produire un document HTML valide. Le jeu de caractères du document HTML pour HTML 4.0 se compose de la plupart, mais pas de tous, des caractères définis conjointement par Unicode et ISO/IEC 10646 : le jeu de caractères universel (UCS).

Comme les documents HTML, un document XHTML est une séquence de caractères Unicode. Cependant, un document XHTML est un document XML qui, bien que ne disposant pas d'une couche d' abstraction explicite de « caractères de document » , s'appuie néanmoins sur une définition similaire des caractères autorisés qui couvre la plupart, mais pas la totalité, des définitions de caractères Unicode/UCS. Les ensembles utilisés par HTML et XHTML/XML sont légèrement différents, mais ces différences ont peu d'effet sur l'auteur moyen du document.

Que le document soit au format HTML ou XHTML, lorsqu'il est stocké sur un système de fichiers ou transmis sur un réseau, les caractères du document sont codés sous forme d'une séquence d' octets ( octets ) selon un codage de caractères particulier. Ce codage peut être soit un format de transformation Unicode , comme UTF-8 , qui peut encoder directement n'importe quel caractère Unicode, soit un codage hérité, comme Windows-1252 , qui ne le peut pas. Cependant, même en utilisant des codages qui ne prennent pas en charge tous les caractères Unicode, le document codé peut utiliser des références de caractères numériques . Par exemple, (☺) est utilisé pour indiquer un caractère de visage souriant dans le jeu de caractères Unicode. ☺

Pour prendre en charge tous les caractères Unicode sans recourir à des références de caractères numériques, une page Web doit disposer d'un codage couvrant l'ensemble de l'Unicode. Le plus populaire est UTF-8 , où les caractères ASCII , tels que les lettres anglaises, les chiffres et certains autres caractères courants, sont conservés inchangés par rapport à l'ASCII. Cela rend le code HTML (tel que <br> et </div>) inchangé par rapport à l'ASCII. Les caractères en dehors de la plage ASCII sont stockés sur 2 à 4 octets. Il est également possible d'utiliser UTF-16 , où la plupart des caractères sont stockés sur deux octets avec un endianness variable , qui est pris en charge par les navigateurs modernes mais moins couramment utilisé.

Afin de contourner les limitations des codages hérités, HTML est conçu de telle sorte qu'il est possible de représenter des caractères de l'ensemble d'Unicode dans un document HTML en utilisant une référence de caractère numérique : une séquence de caractères qui épelle explicitement le point de code Unicode du caractère représenté. Une référence de caractère prend la forme N , où N est soit un nombre décimal pour le point de code Unicode, soit un nombre hexadécimal , auquel cas il doit être préfixé par . Les caractères qui composent la référence de caractère numérique sont universellement représentables dans tous les codages approuvés pour une utilisation sur Internet. &#;x

La prise en charge de l'hexadécimal dans ce contexte est plus récente, donc les navigateurs plus anciens peuvent avoir des problèmes pour afficher les caractères référencés par des nombres hexadécimaux – mais ils auront probablement un problème pour afficher les caractères Unicode au-dessus du point de code 255 de toute façon. Pour assurer une meilleure compatibilité avec les navigateurs plus anciens, il est toujours courant de convertir le point de code hexadécimal en une valeur décimale (par exemple 合au lieu de 合).

En HTML 4, il existe un ensemble standard de 252 entités de caractères nommées pour les caractères - certains courants, d'autres obscurs - qui ne se trouvent pas dans certains codages de caractères ou qui sont sensibles au balisage dans certains contextes (par exemple les chevrons et les guillemets). Bien que tout caractère Unicode puisse être référencé par son point de code numérique, certains auteurs de documents HTML préfèrent utiliser ces entités nommées à la place, lorsque cela est possible, car elles sont moins cryptiques et mieux prises en charge par les premiers navigateurs.

Les entités de caractères peuvent être incluses dans un document HTML via l'utilisation de références d'entité , qui prennent la forme EntityName , où EntityName est le nom de l'entité. Par exemple, , tout comme ou , représente U+ 2014 : le caractère tiret cadratin « — » même si l'encodage de caractères utilisé ne contient pas ce caractère. &;———

Pour la liste complète, voir : Liste des références d'entités de caractères XML et HTML .

Pour traiter correctement le code HTML, un navigateur Web doit déterminer quels caractères Unicode sont représentés par la forme codée d'un document HTML. Pour ce faire, le navigateur Web doit savoir quel codage a été utilisé.

Lorsqu'un document est transmis via un message MIME ou un transport qui utilise des types de contenu MIME tels qu'une réponse HTTP , le message peut signaler l'encodage via un en-tête Content-Type, tel que Content-Type: text/html; charset=UTF-8. D'autres moyens externes de déclaration d'encodage sont autorisés mais rarement utilisés. Si le document utilise un encodage Unicode , les informations d'encodage peuvent également être présentes sous la forme d'une marque d'ordre d'octet (BOM). Enfin, l'encodage peut être déclaré via la syntaxe HTML. Pour la text/htmlsérialisation, tant que la page est encodée dans une extension d' ASCII (comme UTF-8 , et donc, pas si la page utilise UTF-16 ), un metaélément, comme <meta http-equiv="content-type" content="text/html; charset=UTF-8">ou (commençant par HTML5 ) <meta charset="UTF-8">peut être utilisé. Pour les pages HTML sérialisées en XML, les options de déclaration consistent soit à s'appuyer sur l'encodage par défaut (qui pour les documents XML est UTF-8), soit à utiliser une déclaration d'encodage XML. L'attribut meta ne joue aucun rôle dans le HTML servi en XML.

Un codage par défaut s'applique lorsqu'il n'existe aucune déclaration de codage externe ou interne et qu'il n'existe aucune marque d'ordre des octets. Alors que le codage par défaut des pages HTML servies en XML doit être UTF-8, le codage par défaut d'une page Web standard (c'est-à-dire pour les pages HTML sérialisées en text/html) varie en fonction de la localisation du navigateur. Pour un système configuré principalement pour les langues d'Europe occidentale, il s'agira généralement de Windows-1252 . Pour les paramètres régionaux de l'alphabet cyrillique, la valeur par défaut est généralement Windows-1251 . Pour un navigateur situé dans un endroit où les codages de caractères multi-octets hérités sont répandus, une certaine forme de détection automatique est susceptible d'être appliquée.

En raison de l'héritage des représentations de texte 8 bits dans les langages de programmation et les systèmes d'exploitation et du désir d'éviter de surcharger les utilisateurs avec la nécessité de comprendre les nuances de l'encodage, de nombreux éditeurs de texte utilisés par les auteurs HTML ne peuvent ou ne veulent pas offrir un choix d'encodages lors de l'enregistrement des fichiers sur le disque et ne permettent souvent même pas la saisie de caractères au-delà d'une plage très limitée. Par conséquent, de nombreux auteurs HTML ne sont pas conscients des problèmes d'encodage et peuvent ne pas avoir la moindre idée de l'encodage utilisé dans leurs documents. Les malentendus, comme la croyance selon laquelle la déclaration d'encodage affecte un changement dans l'encodage réel (alors qu'il s'agit en fait simplement d'une étiquette qui pourrait être inexacte), sont également une raison de cette attitude de l'éditeur. Un autre facteur contribuant dans le même sens est l'arrivée de l'UTF-8 - qui diminue considérablement le besoin d'autres encodages, et donc les éditeurs modernes ont tendance à utiliser par défaut, comme le recommande la spécification HTML5, l'UTF-8.

Pour les deux sérialisations HTML (contenu de type « text/html » et contenu de type « application/xhtml+xml »), le marqueur d'ordre des octets (BOM) est un moyen efficace de transmettre des informations d'encodage dans un document HTML. Pour UTF-8, le BOM est facultatif, alors qu'il est indispensable pour les encodages UTF-16 et UTF-32. (Remarque : UTF-16 et UTF-32 sans le BOM sont officiellement connus sous des noms différents, ce sont des encodages différents et nécessitent donc une forme de déclaration d'encodage – voir UTF-16BE , UTF-16LE , UTF-32LE et UTF-32BE .) L'utilisation du caractère BOM (U+FEFF) signifie que l'encodage se déclare automatiquement à toute application de traitement. Les applications de traitement doivent simplement rechercher un 0x0000FEFF, 0xFEFF ou 0xEFBBBF initial dans le flux d'octets pour identifier le document comme étant encodé en UTF-32, UTF-16 ou UTF-8 respectivement. Aucun mécanisme de métadonnées supplémentaire n'est requis pour ces codages puisque la marque d'ordre des octets inclut toutes les informations nécessaires au traitement des applications. Dans la plupart des cas, le caractère de marque d'ordre des octets est géré par les applications d'édition séparément des autres caractères, de sorte qu'il y a peu de risque qu'un auteur supprime ou modifie de toute autre manière la marque d'ordre des octets pour indiquer un codage incorrect (comme cela peut se produire lorsque le codage est déclaré en écriture anglaise/latine). Si le document ne possède pas de marque d'ordre des octets, le fait que le premier caractère imprimable non vide dans un document HTML soit censé être "<" (U+003C) peut être utilisé pour déterminer un codage UTF-8/UTF-16/UTF-32.

De nombreux documents HTML sont fournis avec des informations de codage inexactes, voire aucune information de codage du tout. Afin de déterminer le codage dans de tels cas, de nombreux navigateurs permettent à l'utilisateur de sélectionner manuellement un nom de codage dans une liste. Ils peuvent également utiliser un algorithme de détection automatique de codage qui fonctionne de concert avec ou, dans le cas du BOM et dans le cas du HTML servi en XML , contre le remplacement manuel.

Pour les documents HTML sérialisés text/html, la substitution manuelle peut s'appliquer à tous les documents, ou seulement à ceux pour lesquels le codage ne peut pas être déterminé en examinant les déclarations et/ou les modèles d'octets. Le fait que la substitution manuelle soit présente et largement utilisée empêche l'adoption de déclarations de codage précises sur le Web ; par conséquent, le problème est susceptible de persister. Mais notez qu'Internet Explorer, Chrome et Safari – à la fois pour XML et text/htmlles sérialisations – ne permettent pas de remplacer le codage chaque fois que la page inclut le BOM.

Pour les documents HTML sérialisés avec l'étiquette XML préférée – application/xhtml+xml, le remplacement manuel du codage n'est pas autorisé. Le remplacement du codage d'un tel document XML signifierait que le document cesserait d'être XML, car il s'agit d'une erreur fatale pour les documents XML d'avoir une déclaration de codage avec des erreurs détectables. Actuellement, les navigateurs Gecko tels que Firefox respectent cette règle, tandis que la plupart des autres navigateurs courants qui prennent en charge HTML en tant que XML, tels que les navigateurs Webkit (Chrome/Safari) permettent de remplacer manuellement le codage des documents XHTML.

De nombreux navigateurs ne sont capables d'afficher qu'un petit sous-ensemble du répertoire Unicode complet. Voici comment votre navigateur affiche différents points de code Unicode :

Certains navigateurs Web, tels que Mozilla Firefox , Opera , Safari et Internet Explorer (à partir de la version 7), sont capables d'afficher des pages Web multilingues en choisissant intelligemment une police pour afficher chaque caractère individuel de la page. Ils afficheront correctement n'importe quel mélange de blocs Unicode , à condition que les polices appropriées soient présentes dans le système d'exploitation .

Les navigateurs plus anciens, tels que Netscape Navigator 4.77 et Internet Explorer 6 , ne peuvent afficher que le texte pris en charge par la police actuelle associée au codage de caractères de la page et peuvent interpréter à tort les références de caractères numériques comme étant des références à des valeurs de code dans le codage de caractères actuel, plutôt que des références à des points de code Unicode. Lorsque vous utilisez un tel navigateur, il est peu probable que votre ordinateur dispose de toutes ces polices ou que le navigateur puisse utiliser toutes les polices disponibles sur la même page. Par conséquent, le navigateur n'affichera pas correctement le texte des exemples ci-dessus, bien qu'il puisse en afficher un sous-ensemble. Cependant, comme ils sont codés conformément à la norme, ils s'afficheront correctement sur tout système conforme et disposant des caractères disponibles. De plus, les caractères auxquels on donne des noms pour une utilisation dans les références d'entités nommées sont susceptibles d'être plus couramment disponibles que d'autres.

Pour afficher des caractères en dehors du plan multilingue de base , comme la lettre gothique faihu, qui est une variante de la lettre runique fehu dans le tableau ci-dessus, certains systèmes (comme Windows 2000) nécessitent des ajustements manuels de leurs paramètres.

Selon les données internes de l'index Web de Google , en décembre 2007, le codage Unicode UTF-8 est devenu le codage le plus fréquemment utilisé sur les pages Web, dépassant à la fois l'ASCII (États-Unis) et le 8859-1 / 1252 (Europe occidentale).