Résumé

Ce document contient des directives pour l'utilisation du standard Unicode en conjonction avec des langages de balisage comme XML.

Statut de ce document (commun)

Ceci est un rapport technique publié conjointement par le Comité technique Unicode et le groupe de travail/groupe d'intérêt Internationalisation du W3C (accès réservé aux membres du W3C) dans le contexte de l'activité Internationalisation du W3C.

La version du standard Unicode de base pour ce document est la version 4.0. Pour des informations supplémentaires sur les diverses versions du standard Unicode, voir http://www.unicode.org/unicode/standard/versions/. Le standard Unicode et les technologies de balisage évoluent en permanence. Lorsque ce sera nécessaire, une nouvelle version de ce document pourra être publiée.

Statut de ce document (Consortium Unicode)

Statut de ce document (W3C)

Cette note a été approuvée par le groupe de travail/groupe d'intérêt Internationalisation du W3C, mais elle n'a pas été revue ni approuvée par les membres du W3C.

On peut trouver une liste des rapports techniques courants du W3C à http://www.w3.org/TR/.

Table des matières

1. Introduction
   1. La notation
2. Considérations générales
   1. La linéarité et la structure
   2. Le chevauchement sémantique des caractères de commande et du balisage
   3. Le balisage et le stylage
   4. La coïncidence du balisage et des fonctions
   5. La capacité d'extension du balisage
   6. La compatibilité des caractères avec le balisage
3. Les caractères incompatibles avec le balisage
   1. Le tableau des caractères incompatibles avec le balisage
   2. Les séparateurs de lignes et de paragraphes
   3. Les commandes d'incorporation bidi
   4. Les caractères de mise en forme déconseillés
   5. L'indicateur d'ordre des octets
   6. Les caractères d'annotation interlinéaire
   7. Le caractère de remplacement d'objet
   8. Les liaisons musicales
   9. Les caractères d'étiquette linguistique
4. Les caractères de formatage adaptés pour une utilisation avec un balisage
   1. Les signes sous-tendants
   2. La barre oblique de fraction
   3. Les sélecteurs de variante
   4. Les caractères de description idéographique
5. Les caractères à correspondances de compatibilité
   1. Vue d'ensemble
   2. La production d'un nouveau texte
   3. Les caractères des marques d'élément de liste
   4. Les fractions
   5. La disposition en carré ou à l'horizontale
   6. Les caractères en exposant ou en indice
   7. Les autres caractères marqués <compat>
6. Les non-caractères
7. Le versionnage
8. La conformité
9. Références
10. Remerciements
11. Historique des changements
12. Droits d'auteur

1. Introduction

Le standard Unicode [Unicode] définit le jeu de caractères universel. Son objet principal est de fournir un codage sans équivoque du contenu d'un texte brut, afin de couvrir en définitive toutes les langues du monde. Actuellement dans sa quatrième version majeure, le jeu Unicode contient un grand nombre de caractères qui recouvrent la plupart des écritures employées couramment dans le monde. Il contient également d'autres caractères pour l'interopérabilité avec les codages de caractères anciens ainsi que des caractères avec des fonctions de type commande inclus principalement afin de permettre l'interprétation sans ambiguïté d'un texte brut. Unicode précise l'utilisation de tous ces caractères.

Pour l'échange des documents et des données, l'Internet et le World Wide Web font de plus en plus appel au balisage du texte, ainsi HTML et XML. Dans bien des cas, le balisage présente les mêmes fonctionnalités, ou des caractéristiques similaires, que celles des caractères de formatage du standard Unicode pour du texte brut. Alors que la gestion de ces caractères et de leurs spécifications dans un texte brut peut obéir à des raisons valables, leur utilisation dans un texte balisé peut entrer en conflit avec les règles du langage de balisage. Les caractères de mise en forme sont décrits aux chapitres 2 et 3, et les caractères de compatibilité dans le chapitre 4.

Les problèmes soulevés par les équivalences canoniques et la normalisation [Normalization] ainsi que par l'interaction du codage de caractères et des méthodes d'échappement des caractères dans le balisage sont abordés dans le modèle de caractère pour le World Wide Web [Charmod].

Les problèmes liés à l'utilisation des caractères Unicode dans un texte balisé dépendent dans une certaine mesure des règles du langage de balisage en question et de l'ensemble des éléments qu'il contient. Dans un sens étroit, ce document ne se rapporte qu'au langage XML et, dans une certaine mesure, au langage HTML. Cependant, une grande partie des informations générales présentées ici devraient se révéler utiles dans un contexte plus vaste, y compris pour certains langages de mise en page.

Remarque : De nombreuses recommandations de ce rapport sont tributaires de la disponibilité d'un balisage particulier ou d'un style particulier. Quand c'est possible, il faut utiliser ou concevoir des DTD ou des schémas appropriés afin de rendre disponibles un tel balisage ou un tel style, ou encore prolonger de manière adéquate les DTD ou schémas utilisés. La version courante de ce document ne fait aucune recommandation particulière en ce qui concerne la conception des DTD ou des schémas, ou l'utilisation de DTD ou de schémas particuliers, mais les informations présentées ici peuvent être utiles aux concepteurs de DTD ou de schémas comme aux personnes choisissant les DTD ou schémas pour leurs applications. Les recommandations de ce rapport ne s'appliquent pas en ce qui concerne le code XML utilisé lors d'une transmission de données en aveugle ou dans des cas similaires.

1.1 La notation

Ce rapport utilise XML [XML] comme exemple de langage de balisage éminent et général. On emploie la notation d'espace de nommage XML [Namespace] pour indiquer qu'un certain élément est issu d'un langage de balisage spécifique. Par exemple, le préfixe xhtml: indique que l'élément appartient à [XHTML]. Cela signifie que les exemples contenant le préfixe d'espace de nommage xhtml: sont censés inclure la déclaration d'espace de nommage xmlns:xhtml="..."

Les caractères sont présentés en utilisant la notation employée dans le standard Unicode, c'est-à-dire une partie optionnelle U+ suivie par leur nombre hexadécimal, avec au moins quatres chiffres, tels que "U+1234" ou "U+10FFFD". Dans XML ou HTML, on pourrait les exprimer par "&#x1234;" ou "&#x10FFFD;".

2. Considérations générales

On doit tenir compte des différents aspects de l'interaction entre le codage de caractères et le balisage :

• La linéarité du texte comparée à la structure hiérarchique du balisage ;
• Le chevauchement sémantique des caractères de commande et du balisage ;
• Le balisage comparé au style ;
• La coïncidence du balisage sémantique et des fonctions ;
• La capacité d'extension du balisage.

2.1 La linéarité et la structure

Le codage d'un texte en une suite de caractères, sans autres informations, conduit à une séquence linéaire, appelée communément texte brut. Un caractère suit un autre caractère, sans structure particulière. Par contre, un balisage définit une structure hiérarchique pour le texte ou les données. Dans le cas de XML et de la plupart des autres langages de balisage similaires, le balisage définit une structure en arbre. Bien qu'on linéarise cette structure en arbre pour la transmettre sous la forme d'un document XML, sitôt l'analyse du document effectuée, on peut accéder à l'arbre directement.

Les opérations faciles à réaliser sur les arbres sont souvent difficiles à réaliser sur les séquences linéaires, et vice versa. En séparant judicieusement les fonctionnalités de codage de caractères de celles du balisage, l'architecture gagne en simplicité, en puissance et en pérennité.

En particulier, les opérations sur les structures hiérarchiques peuvent aisément assurer que les informations restent dans un contexte. Les attributs assignés à des parties d'un document accompagnent celles-ci. L'assignation d'un attribut à une partie d'un document limite la portée de l'attribut à cette partie du document. Effectuer les mêmes opération sur des suites de caractères linéaires, à l'aide de caractères de commande afin de définir les attributs et de limiter leur portée, demande beaucoup plus d'effort et c'est une source d'erreurs. Trouver le début ou la fin d'un tronçon de texte affecté par un même attribut nécessite de balayer le texte vers l'avant et l'arrière à la recherche du délimiteur ou du caractère de commande incorporés. Le déplacement ou l'édition du texte aboutissent souvent au défaut de l'appariement des codes de contrôle, avec pour effet que l'attribut pourrait soudainement s'appliquer à un texte auquel il n'est pas destiné.

2.2 Le chevauchement sémantique des caractères de commande et du balisage

En l'absence de balisage, le texte brut peut requérir des caractères de commande. C'est habituellement le cas quand il faut délimiter un texte brut ou lui adjoindre les informations apportées par des attributs pour le rendre lisible, c'est-à-dire, afin de pouvoir transmettre le même contenu entre l'émetteur et le destinataire. Nombre de ces caractères de commande ont des équivalents directs dans des langages de balisage particuliers, car le balisage permet de traiter efficacement ces questions. Lorsque des caractères et les balises correspondantes apparaissent dans un même texte, la question de leur priorité [respective] se pose. C'est pourquoi, il est important d'identifier et de résoudre ces ambiguïtés lors de la première application du balisage.

2.3 Le balisage et le stylage

Outre le codage de base des caractères et le balisage du texte, un troisième composant se rajoute aux caractéristiques du texte, à savoir le stylage. Le balisage concerne la structure logique du texte ou des données, afin d'indiquer, par exemple, les sections, les sous-sections et les titres d'un document, ou d'indiquer les divers champs de l'enregistrement d'une adresse. Les attributs de mise en forme servent à présenter les informations de diverses façons, par exemple, avec différentes polices, différents styles de police (italique, en gras), différentes couleurs, etc. Certains codes de caractère ne codent pas un caractère générique, mais un caractère mis en forme. Lorsqu'on utilise ces caractères, l'information de style est figée, en d'autres termes, il n'est plus possible de modifier l'apparence du texte en lui appliquant une information de style. Cependant, il existe de nombreux exemples dans lesquels une ancienne variante stylistique a acquis avec le temps un sens différent qui est correctement codé comme texte brut. Parfois, ce qui n'est qu'une variante dans certains contextes acquiert un sens distinct dans d'autres. Dans ces cas-là, modifier l'apparence du texte par un attribut de mise en forme en altèrerait alors irrémédiablement le sens.

2.4 La coïncidence du balisage et des fonctions

Traiter les diverses fonctionnalités au niveau du balisage présente, la plupart du temps, l'avantage supplémentaire que les parties de texte qui nécessitent un certain attribut (ou style) particulier sont celles qui sont en fait balisées : un paragraphe peut être en anglais, une citation incorporer un passage bidirectionnel, un mot-clé [être] en italique, un numéro de liste entouré d'un cercle, etc. C'est ce qui rend l'association des attributs au balisage très efficace.

Cependant, là où on a besoin d'une fonctionnalité locale ou ponctuelle, le balisage ne se montre pas très efficace, et son avantage principal, la définition aisée d'une portée, se révèle inutile. Au contraire, l'intrusion d'une balise au milieu d'un mot peut rendre les opérations de recherche et de tri plus difficiles. Dans ces cas, l'expression des informations par des codes de caractères ne représente pas seulement une option, mais souvent le meilleur choix, dont on doit tenir compte dans la conception des langages de balisage.

2.5 La capacité d'extension du balisage

Le codage de caractères attribue à chaque caractère un entier (son numéro). Cette méthode est extrêmement efficace mais elle présente certaines limites. Inversement, le balisage est bien plus extensible. En utilisant des technologies comme les espaces de nommage XML [Namespace], on peut utiliser plusieurs vocabulaires.

2.6 La compatibilité des caractères avec le balisage

La compatibilité d'un caractère particulier avec le balisage dépend de son statut dans le standard Unicode, de la nature de son rôle dans le texte et de la disponibilité d'un balisage équivalent. Nombre de caractères de formatage nécessaires aux textes bruts évolués ne conviennent pas aux contextes balisés. La section 3 en donne une liste descriptive détaillée. Cependant, certains caractères de formatage peuvent s'utiliser avec un balisage. La section 4 fournit une liste de ces caractères de formatage qui conviennent pour une utilisation avec un balisage et donne quelques explications sur leur emploi. Outre les caractères de formatage, le standard Unicode prévoit également des caractères de compatibilité, dont certains peuvent être remplacés par un balisage adéquat. Ces caractères sont abordés à la section 5.

3 Les caractères incompatibles avec le balisage

Il y a des caractères qui ne conviennent pas au contexte de balisage de XML/HTML et dont on décourage l'usage, parce que l'une ou plusieurs des conditions suivantes sont vérifiées :

• Ils sont déconseillés par le standard Unicode ;
• Ils ne peuvent être mis en œuvre sans données supplémentaires ;
• Ils sont difficiles à gérer parce qu'ils ont un état ;
• Ils sont mieux gérés par le balisage ;
• Ils sont indésirables en raison d'un conflit avec un balisage équivalent.

La section 3.1 fournit une liste de ces caractères. Les sections 3.2 à 3.9 donnent plus de détails sur les caractères découragés concernant les points suivants :

• Une brève description sémantique ;
• Les raisons de l'inclusion dans Unicode ;
• Les problèmes spécifiques soulevés par une utilisation avec un balisage ;
• Les autres domaines dans lesquels des problèmes peuvent survenir (par exemple, le texte brut) ;
• Le type de balisage à utiliser à la place ;
• Les actions à mener en cas de détection dans un contexte particulier.

3.1 Le tableau des caractères incompatibles avec le balisage

Le tableau suivant contient les caractères qui sont considérés actuellement comme inadaptés pour une utilisation avec le balisage dans XML ou HTML. (Voir toutefois la remarque dans la section Introduction). Ceux-ci peuvent aussi se montrer inadaptés pour d'autres langages de balisage ou de mise en page. Afin de déterminer un possible conflit, ce rapport utilise le balisage disponible dans HTML.

Tableau 3.1 : Les caractères incompatibles avec le balisage

À l'exception des séparateurs de lignes et de paragraphes, ou de l'indicateur d'ordre des octets, les navigateurs et agents utilisateurs similaires peuvent ignorer la présence de caractères découragés dans HTML ou XML. Il revient aux outils d'édition d'assurer une conversion exacte entre ces caractères et le balisage équivalent s'il existe.

3.2 Les séparateurs de lignes et de paragraphes, U+2028, U+2029

Brève description : Les séparateurs de lignes et de paragraphes offrent un moyen univoque pour indiquer les sauts de ligne obligatoires et les délimiteurs de paragraphe dans un texte brut.

Raisons de l'inclusion : Ces caractères ont été introduits dans le standard Unicode afin de surmonter l'utilisation ambigüe et largement divergente des codes de commande réservés à cet effet. Voir le rapport technique n° 13 Les instructions pour les sauts de ligne Unicode [UAX13].

Problèmes en contexte balisé : Inclure ces caractères dans le texte balisé est inopérant quand ils font double emploi avec les balises qui délimitent les paragraphes et les lignes.

Problèmes dans d'autres contextes : Ces caractères séparateurs peuvent aussi être source de problèmes lorsqu'utilisés dans du texte brut. Ceci tient à l'utilisation dans les textes anciens de caractères de commande pour ces fins, caractères qui sont convertis directement en Unicode, forçant effectivement leur interprétation par tous les destinataires. C'est pourquoi peu de mises en œuvre Unicode prennent en charge les séparateurs U+2028 et U+2029.

Balisage de remplacement : Dans HTML, utiliser <xhtml:br /> à la place du caractère U+2028 et englober les paragragraphes à l'aide de <xhtml:p> et </xhtml:p> au lieu de les séparer par des caractères U+2029.

Mesures à prendre si présence détectée : Dans le contexte d'un navigateur, traiter comme un blanc. Dans un contexte d'édition, remplacer le caractère par le balisage correspondant.

3.3 Les commandes d'incorporation bidi (LRE, RLE, LRO, RLO, PDF), U+202A...U+202E

Brève description : Les commandes d'incorporation bidi permettent de complémenter l'algorithme bidirectionnel Unicode utilisé avec des textes bruts.

Raisons de l'inclusion : L'algorithme bidirectionnel Unicode résoud de manière univoque la direction d'affichage d'un texte bidirectionnel. Pour ce faire, il affecte à tous les caractères des catégories directionnelles et en résoud celles-ci dans le contexte. Dans de rares circonstances, cette méthode implicite ne produira pas de résultats satisfaisants et les commandes d'incorporation sont donc nécessaires afin d'assurer que l'émetteur et le destinataire s'accordent sur le sens d'affichage d'un texte donné. Voir le rapport technique Unicode n° 9 L'algorithme bidirectionnel [UAX 9].

Problèmes en contexte balisé : Ces caractères doublent le balisage disponible, ce qui convient mieux à la manipulation de la nature avec état de leur effet.

Problèmes dans d'autres contextes : Les commandes d'incorporation introduisent un état dans le texte brut, lequel état doit être conservé à l'édition ou à l'affichage du texte. Les traitements qui modifient le texte et ignorent cet état peuvent involontairement affecter la restitution de larges parties du texte, par exemple, en retirant un PDF (DÉPILEMENT DE FORMATAGE DIRECTIONNEL).

Balisage de remplacement : Le tableau suivant donne le balisage de remplacement :

Unicode	Balisage équivalent	Commentaires
RLO	<xhtml:bdo dir = "rtl">
LRO	<xhtml:bdo dir = "ltr">
PDF	</xhtml:bdo>	Quand il est employé pour terminer les caractères RLO ou LRO, sinon il est ignoré
RLE	dir = "rtl"	Attribut sur un élément de type bloc ou en-ligne
LRE	dir = "ltr"	Attribut sur un élément de type bloc ou en-ligne

Pour des précisions sur le balisage bidi, veuillez consulter la section 8.2 de la spécification HTML [HMTL 4.0-8.2]. Le texte de la spécification fait la recommandation suivante :

L'utilisation du balisage de directionnalité HTML avec des caractères Unicode. Les auteurs et les développeurs de logiciels d'édition doivent garder à l'esprit que des conflits peuvent survenir si on utilise l'attribut dir sur des éléments en-ligne (y compris l'élément BDO) en même temps que les caractères de mise en forme [UNICODE] correspondants. On utilisera de préférence l'une ou l'autre méthode de manière exclusive. Le balisage assure une meilleure intégrité structurelle des documents et élimine certaines difficultés lorsqu'on prépare un texte HTML bidirectionnel avec un simple éditeur de texte, mais certains logiciels peuvent être plus aptes à utiliser les caractères [UNICODE]. Si les deux méthodes sont utilisées, on exercera le plus grand soin à imbriquer correctement le balisage et l'enchâssement ou l'inactivation directionnels, sinon les conséquences sur la restitution seront indéfinies.

Le présent document, qui va au-delà de la spécification HTML, recommande l'utilisation du balisage seulement.

Mesures à prendre si présence détectée : Dans le contexte d'un navigateur, l'ignorer. Dans un contexte d'édition, remplacer les caractères par le balisage adéquat.

3.4 Les caractères de mise en forme déconseillés, U+206A...U+206F

Brève description : Ces caractères sont déconseillés. Ils étaient destinés à l'origine à permettre l'activation explicite d'un échange symétrique, d'un formage contextuel et à rendre des caractères numéraux selon les conventions locales.

Raisons de l'inclusion : Ces caractères, introduits dès les avants-projets de la norme ISO 10646, ont [simplement] été conservés.

Problèmes en contexte balisé : Le modèle de traitement de ces caractères n'est pas géré dans le balisage.

Problèmes dans d'autres contextes : Le standard Unicode exige que l'échange symétrique, le formage contextuel et les formes numérales locales soient permises par défaut et il ne permet plus leur inhibition par l'utilisation de ces codes de caractère. L'effet le plus probable de leur présence dans un texte prendra la forme d'un caractère parasite.

Conversion pour une utilisation dans le balisage : Appliquer la conversion adéquate afin d'amener le flux de données en phase avec le modèle de texte Unicode pour le texte bidirectionnel et les écritures cursives.

Mesures à prendre si présence détectée : Dans le contexte d'un navigateur comme partie d'un texte balisé, ces caractères peuvent être ignorés. Dans un contexte d'édition, ils peuvent être retirés, accompagné éventuellement d'un avis à l'utilisateur. Autrement, on peut fournir une conversion adéquate à partir du modèle textuel préexistant. Cela se limitera très probablement aux applications bien informées interfaçant directement avec l'implémentation léguée particulière qui a inspiré ces caractères.

3.5 L'indicateur d'ordre des octets, ZWNBSP, U+FEFF

Brève description : Le caractère U+FEFF a deux fonctions. Il porte le nom officiel d'ESPACE INSÉCABLE SANS CHASSE (ZWNBSP), et il peut faire office de GLUON DE MOT, mais son rôle principal en tant qu'indicateur d'ordre des octets (BOM) est de préciser dans la signature d'un fichier si celui-ci est dans une forme de stockage particulière d'Unicode et a un ordre des octets particulier. L'utilisation du caractère U+FEFF comme gluon de mot dans de nouvelles données est déconseillée selon [Unicode3.2] en faveur du caractère U+2060 GLUON DE MOT. L'utilisation comme indicateur d'ordre des octets reste inchangée.

Raisons de l'inclusion : Inclus à l'origine dans Unicode dans le seul but d'indiquer l'ordre des octets à utiliser dans les signatures des fichiers, le caractère a pris le sens d'espace insécable à chasse nulle lors de la fusion de la norme ISO/CEI 10646 et du standard Unicode. Lorsqu'il est employé comme indicateur d'ordre des octets, le caractère est placé au début du fichier. Si un destinataire le voit comme point de code U+FEFF, alors l'ordre des octets entre l'émetteur et le récepteur correspond. Si le destinataire le voit comme U+FFFE (un point de code de non-caractère), alors l'émetteur aura utilisé un ordre des octets opposé à celui du destinataire, et celui devra inverser l'ordre des octets ou bien refuser de lire le fichier. Lorsqu'il est employé comme espace insécable sans chasse, le caractère est destiné à empêcher les coupures entre les caractères adjacents. Cette fonction est maintenant fournie par le caractère U+2060 GLUON DE MOT (ZWJ), ce qui supprime la nécessité d'insérer le caractère U+FEFF au milieu d'un fichier. Pour des précisions, voir le chapitre 15 du standard [Unicode].

Problèmes en contexte balisé : L'utilisation du caractère U+FEFF comme espace insécable sans chasse ne permet pas de distinguer ce cas de celui où un indicateur d'ordre des octets aurait été oublié au milieu d'un fichier en raison d'une mauvaise découpe, par exemple après un copier-coller.

Problèmes dans d'autres contextes : L'utilisation de l'indicateur d'ordre des octets comme espace insécable sans chasse est également problématique dans un texte brut et c'est la raison pour laquelle on le déconseille et on lui préfère le caractère U+2060 GLUON DE MOT. L'utilisation du caractère U+FEFF dans les signatures des fichiers afin d'indiquer l'ordre des octets est la seule qui est recommandée pour ce caractère.

Balisage de remplacement : Aucun.

Mesures à prendre si présence détectée : Dans le contexte d'un navigateur comme partie d'un texte balisé, traiter le caractère en fonction de son emplacement. Au début d'une entité externe, le traiter comme indicateur d'ordre des octets (c'est-à-dire, comme partie du codage de caractères, non comme partie du flux de caractères analysé, voir par exemple la section 4.3.3 de la spécification [XML 1.0]). Sinon, supposer qu'il s'agit de données anciennes qui l'utilisent comme espace insécable sans chasse. Lors de la réception d'un texte brut dans un environnement d'édition, le logiciel d'édition peut opérer une ou plusieurs des actions suivantes : remplacer le caractère ESPACE INSÉCABLE SANS CHASSE (ZWNBSP) qui se trouve au milieu d'un fichier par un caractère GLUON DE MOT (ZWJ), ou bien le signaler à l'utilisateur.

3.6 Les caractères d'annotation interlinéaire, U+FFF9...U+FFFB

Brève description : Les caractères d'annotation interlinéaire servent à délimiter des annotations interlinéaires dans certaines circonstances. Ils sont destinés à fournir des ancres et des délimiteurs de texte pour une annotation interlinéaire au cours du traitement et ne sont pas destinés aux échanges.

Raisons de l'inclusion : Unicode a inclus les caractères d'annotation interlinéaire dans le seul but de réserver des points de code pour des traitements internes très fréquent. Les caractères d'annotation interlinéaire sont utilisés pour délimiter des annotations interlinéaires dans les contextes où on ne dispose pas d'autres délimiteurs et où il existe des moyens non textuels pour le transport d'informations de mise en forme. Nombre d'applications de traitement de texte stockent le texte et le balisage associé (ou, dans certains cas, des informations de style) d'un document dans des structures séparées. Le texte proprement dit est stocké dans une seule structure linéaire ; les autres informations sont stockées à part, avec des pointeurs vers les positions concernées dans le texte. On appelle celles-ci les informations hors-texte. L'implémentation d'ensemble veille à ce que ces deux structures restent synchronisées. Si le texte contient des annotations interlinéaires, la présence de délimiteurs dans le texte même est très utile aux implémentations, bien que les délimiteurs ne soient pas utilisés par ailleurs pour un balisage de style. Avec cette méthode, et mis à part le cas du caractère de remplacement d'objet, toutes les informations textuelles peuvent rester dans le flux de texte normal, et les éventuelles informations de mise en forme supplémentaires sont stockées à part. En outre, l'ancre d'annotation interlinéaire fait office de repère pour les informations de mise en forme de l'annotation entière, de la même manière qu'une marque de paragraphe peut être le repère où attacher les informations de mise en forme du paragraphe.

Problèmes en contexte balisé : Inclure des caractères d'annotation interlinéaire est inopérant parce que les informations de mise en forme supplémentaires (comment positionner l'annotation, etc.) ne sont pas disponibles.

Problèmes dans d'autres contextes : Les caractères d'annotation interlinéaire sont également problématiques quand ils sont utilisés dans un texte brut, et ils ne sont pas destinés à cet usage. En particulier, sur les systèmes d'affichage anciens qui ignorent ou remplacent simplement les caractères d'annotation interlinéaire, la signification du texte peut s'en trouver changée.

Balisage de remplacement : Le balisage à utiliser à la place des caractères d'annotation interlinéaire dépend de la mise en forme et de la nature de l'annotation interlinéaire en question. Pour l'annotation ruby, veuillez consulter la spécification [Ruby].

Mesures à prendre si présence détectée : Dans le contexte d'un navigateur comme partie d'un texte balisé, ces caractères peuvent être ignorés. Dans un contexte d'édition avec un texte brut, les logiciels d'édition peuvent entreprendre une ou plusieurs des actions suivantes : retirer le caractère U+FFF9 ANCRE D'ANNOTATION INTERLINÉAIRE en même temps que tous les caractères entre le caractère U+FFFA SÉPARATEUR D'ANNOTATION INTERLINÉAIRE et le caractère U+FFFB TERMINATEUR D'ANNOTATION INTERLINÉAIRE suivant ; ignorer le caractère U+FFF9 et transformer les caractères U+FFFA et U+FFFB en caractères [ et ] respectivement ; alerter l'utilisateur ou les convertir provisoirement en un balisage ruby adéquat pour une nouvelle édition et mise en forme par l'utilisateur.

3.7 Le caractère de remplacement d'objet, U+FFFC

Brève description : Le caractère de remplacement d'objet permet de représenter la place d'un objet (par exemple, une image) inclus dans le texte.

Raisons de l'inclusion : Unicode a inclus le caractère de remplacement d'objet dans le seul but de réserver un point de code pour un traitement interne très fréquent. Nombre d'applications de traitement de texte rangent le texte et le balisage associé (ou, dans certains cas, les informations de style) d'un document dans des structures séparées. Le texte proprement dit est gardé dans une seule structure linéaire ; les autres informations sont gardées séparément avec des pointeurs vers les positions appropriées dans le texte. L'implémentation d'ensemble veille à ce que les deux structures restent synchronisées. Si le texte contient des objets, comme des images, la présence d'une sentinelle dans le texte même est extrêmement utile aux implémentations ; les éventuelles informations de mise en forme supplémentaires sont stockées à part.

Problèmes en contexte balisé : L'inclusion d'un caractère de remplacement d'objet dans un texte balisé ne fonctionne pas parce que les informations supplémentaires (quel objet inclure, etc.) ne sont pas disponibles.

Problèmes dans d'autres contextes : Le caractère de remplacement d'objet est également problématique dans un texte brut parce qu'il n'existe aucun moyen dans un texte brut de fournir des informations réelles sur un objet ou une référence à celui-ci.

Balisage de remplacement : Le balisage à utiliser à la place du caractère de remplacement d'objet est fonction de l'objet en question et du contexte de balisage dans lequel celui-ci est utilisé. Des cas typiques en sont <xhtml:img src='...' />, <xhtml:object ...> ou <xhtml:applet ...>. Ces structures permettent la fourniture de toutes les autres informations nécessaires pour identifier et utiliser l'objet en question.

Mesures à prendre si présence détectée : Les navigateurs peuvent ignorer ce caractère. Dans un contexte d'édition, si l'objet réel est accessible, les logiciels d'édition peuvent soit remplacer le caractère par le balisage qui convient à cet objet, soit sinon le retirer, idéalement en produisant une alerte.

3.8 Les liaisons musicales, U+1D173...U+1D17A

Brève description : Une série de caractères qui permettent de grouper ou lier les notes musicales.

Raisons de l'inclusion : Ces caractères désignent le début et la fin de structures musicales communes. Une présentation musicale complète demande d'autres informations, par exemple la hauteur de ton, qui ne peuvent être codées avec Unicode. Cependant, beaucoup de symboles musicaux peuvent être représentés isolément (et sans assigner de hauteur) comme partie du texte d'une discussion musicale. L'utilisation des caractères Unicode dans un texte brut est principalement destinée à ce dernier usage. On peut utiliser les opérateurs de liaison pour gérer les restitutions limitées des poutres (ou rames)[ndt. beams], des coulés [ndt. slurs], des phrasés, etc. dans ce contexte. Par contre, dans le contexte des langages de balisage, la partition musicale exige un langage spécialisé (analogue au langage MathML) dont on s'attendrait à ce qu'il contienne un balisage pour ces structures.

Problèmes en contexte balisé : Ces caractères doublent les informations qui peuvent en principe être exprimées dans le balisage.

Problèmes dans d'autres contextes : Leur [affectation dans une] zone [de caractères] particulière permet de les éliminer facilement, mais les applications qui ne s'attendent pas à les rencontrer les traiteront comme des caractères parasites.

Balisage de remplacement : Remplacer par du balisage équivalent si disponible.

Mesures à prendre si présence détectée : Les navigateurs peuvent ignorer ces caractères. Dans un contexte d'édition, les logiciels d'édition peuvent les retirer ou les remplacer par un balisage équivalent.

3.9 Les caractères d'étiquette linguistique, U+E0000...U+E007F

Brève description : Une série de caractères qui permettent d'exprimer des indicatifs linguistiques, s'inspirant des normes existantes concernant les étiquettes linguistiques qui utilisent les règles du chapitre 15 du standard [Unicode].

Raisons de l'inclusion : Ces caractères permettent l'étiquetage linguistique dans le texte dans les situations où on ne dispose pas d'un balisage complet, tout en permettant leur élimination facile par les applications qui ne les prennent pas en charge. Ceux-ci ont été uniquement inclus au profit de ceux des protocoles Internet, tel que ACAP, qui requièrent un mécanisme standard pour le marquage d'une langue dans les chaînes codées en UTF-8, et, en même temps, pour éviter l'emploi d'autres systèmes d'étiquetage qui reposent sur des détails particuliers de la forme de codage utilisée.

Problèmes en contexte balisé : Ces caractères doublent les expressions qui peuvent être exprimées dans le balisage.

Problèmes dans d'autres contextes : Leur [affectation dans une] zone [de caractères] particulière permet de les éliminer facilement, mais les applications qui ne s'attendent pas à les rencontrer les traiteront comme des caractères parasites.

Balisage de remplacement : Remplacer par le balisage d'un langage équivalent. Les langages XML et XHTML ont l'attribut xml:lang. Le langage HTML a l'attribut lang. Ces attributs observent des règles de portée différentes de celles des caractères d'étiquette ; c'est pourquoi ce remplacement ne se résumera généralement pas à une simple substitution univoque.

Mesures à prendre si présence détectée : Les navigateurs peuvent ignorer ces caractères. Dans un contexte d'édition, les logiciels d'édition peuvent les retirer ou les remplacer par un balisage équivalent.

4 Les caractères de formatage adaptés pour une utilisation avec un balisage

Le tableau suivant contient des caractères de formatage qui ne présentent pas les problèmes abordés au début de ce passage. Malgré leurs relations ou similarités apparentes avec les caractères du tableau 3.1, on considère qu'ils peuvent être utilisés avec du balisage. Il n'est pas acceptable que les agents utilisateurs ignorent les caractères du tableau 4.1. Pour une description de ces caractères, voir le standard [Unicode].

Tableau 4.1 : Quelques caractères qui affectent le format du texte mais qui conviennent pour une utilisation avec un balisage

Les sous-sections suivantes traitent de certains des caractères de la liste précédente, notamment ceux qui ont un effet au-delà de leurs voisins immédiats. Veuillez consulter le standard [Unicode] pour des précisions complètes.

4.1 Les signes sous-tendants

Les signes sous-tendants sont nécessaires à la représentation d'une caractéristique commune aux écritures arabe et syriaque, dans lesquelles on peut placer un signe sous une série de caractères, par exemple, sous une suite de chiffres afin d'indiquer une année. Le caractère MÉTOBÈLE SYRIAQUE HÉRACLÉEN se place au-dessus d'une suite de caractères, ce qui en fait techniquement un signe sus-tendant, et le caractère FIN DE AYAH ARABE est une marque englobante. Dans le flux de caractères, le signe sous-tendant précède les caractères affectés. La portée de ces signes sous-tendants est implicite, elle se termine habituellement au premier caractère non alphanumérique.

À la différence des signes sous-tendants, la portée des marques englobantes combinatoires, telle celle du caractère DIACRITIQUE CERCLE ENGLOBANT, est limitée au groupe de graphèmes par défaut précédent. Pour des précisions sur les groupes de graphèmes, voir [UAX 29] Les frontières de texte.

Pour l'instant, il n'existe pas de balise qui permette de représenter les fonctions de portée/regroupement et de rendu définies par ces caractères, on ne peut donc pas les substituer. Il n'est pas clair à ce stade dans quelle mesure le balisage intermédiaire affecte la portée de ces marques.

4.2 La barre de fraction

La barre de fraction s'utilise entre des suites de chiffres décimaux afin de former des fractions. Il n'est pas précisé si la fraction résultante a une ligne de fraction horizontale ou bien en diagonale. La solution de repli consiste à laisser les chiffres tels quels et à afficher une barre normale. Pour séparer un chiffre d'une fraction qui le suit, comme dans 1 ¾, on recommande le caractère U+2009 ESPACE FINE.

Pour un réglage plus fin des fractions, on conseille d'utiliser le langage [MathML] quand c'est approprié.

4.3 Les sélecteurs de variante

Un sélecteur de variante est destiné à produire une forme variante particulière (ou une gamme de formes variantes) lorsque celui-ci est appliqué à un caractère de base. Pour que le sélecteur de variante prenne effet, il doit suivre immédiatement son caractère de base. Seules les combinaisons préétablies de caractères de base sélectionnés et de sélecteurs de variante particuliers produisent un effet défini. Toutes les autres combinaisons sont défectueuses et elles doivent être ignorées. La liste des combinaisons normalisées est documentée dans la base de données des caractères Unicode, voir [Variants]. En plus des 256 sélecteurs de variante génériques, il existe trois sélecteurs de variation libre mongols. Ceux-ci fonctionnent à tous égards comme les sélecteurs de variante, sauf qu'ils ne s'appliquent qu'à des caractères de base mongols. Le mongol étant une écriture contextuelle comme l'arabe, les variations se limitent à des contextes de formage particuliers.

4.4 Les caractères de description idéographique

Les caractères de description idéographique d'Unicode permettent de décrire la composition d'idéogrammes à partir de morceaux, chacun de ces morceaux est un caractère Unicode ou un [autre] morceau composé [à l'aide des caractères de description idéographique]. D'ordinaire, le résultat consiste en une description de caractère lisible par l'homme. Ceci peut s'avérer utile quand le caractère en question n'est pas disponible dans une police. Toutefois, quelques fabricants s'intéressent à la conversion automatique de chaque suite descriptive en un seul idéogramme.

5. Les caractères à correspondances de compatibilité

Le standard Unicode prévoit des correspondances de compatibilité pour un certain nombre de caractères. Une correspondance de compatibilité précise une relation entre deux caractères, mais la nature exacte de cette relation varie. Dans certains cas, la relation signifie s'inspire de, dans d'autres cas, elle indique une propriété. Lorsqu'un texte brut est balisé, il peut s'avérer opportun/judicieux de remplacer certains de ces caractères par leurs équivalents en terme de compatibilité et le balisage qui convient. Il est important de comprendre la nature des différences entre les caractères et leurs équivalents en terme de compatibilité et le contexte dans lequel ces distinctions importent. Il n'est jamais recommandé d'appliquer des correspondances de compatibilité sans discernement. Cette section explique quand et comment utiliser les correspondances de compatibilité lors de l'importation d'un texte non XML (non balisé). Cette section est organisée selon l'étiquette de compatibilité qui caractérise chaque correspondance de compatibilité.

5.1 Vue d'ensemble

Le tableau suivant fournit un aperçu des divers caractères de compatibilité, rangés par étiquette de compatibilité. La première colonne (Valeur d'étiquette) reprend la valeur de l'étiquette de compatibilité provenant de la base de données des caractères Unicode [UnicodeData]. Bien que ces étiquettes utilisent les caractères < et >, ceux-ci n'apparaissent pas comme tels dans le balisage et on ne devrait pas les confondre avec des balises XML. La colonne Intervalles de codes indique une correspondance plus poussée par points de code. La colonne Action résume l'action recommandée lors d'un premier balisage appliqué à un texte non XML. Chaque entrée indique si les caractères peuvent être remplacés par les caractères équivalents de compatibilité selon la la forme de normalisation KC décrite dans le document [UAX 15], s'ils peuvent être remplacés par un balisage équivalent si disponible ou s'ils devraient être stockés. Dans certains cas, des informations de style [CSS2] sont nécessaires à la place (ou en plus) du balisage. La colonne Description et utilisation fournit des informations supplémentaires. Les sections 5.3 jusqu'à 5.6 apportent des précisions concernant certains de ces ensembles de caractères de compatibilité, y compris les actions recommandées détaillées.

Tableau 5.1 : Les caractères à correspondances de compatibilité

Remarque : Certains symboles utilisés en composition verticale existent sous la forme d'un caractère simple dans les systèmes préexistants, mais ils peuvent aussi être composés à la volée par des moteurs d'affichage plus évolués. Consulter le document [CSS3Text] pour les propriétés de style proposées : la propriété text-combine permet de grouper des caractères kana et de les disposer en carré au sein d'une cellule de rendu (kumimoji), alors que la propriété writing-mode permet de disposer des caractères horizontalement dans des colonnes composées verticalement (tate-chu-yoko).

5.2 La production d'un nouveau texte

Les formes de présentation et les caractères, pour lesquels il existe une représentation adéquate comme texte balisé, ne devraient jamais être introduits dans de nouvelles données. Cependant, beaucoup de caractères avec l'étiquette <police> conviennent pour de nouvelles données, tant que ceux-ci sont utilisés conformément à leur fonction, c'est-à-dire comme symboles où chaque forme a un sens différent bien défini. D'une part, on ne doit pas les utiliser pour créer l'apparence d'un texte stylé. D'autre part, on ne devrait pas utiliser le balisage de style pour indiquer une différence essentielle de sens, par exemple en mathématiques.

Par exemple, pour écrire hello, on devrait utiliser <i>hello</i> et non la suite de caractères Unicode U+210E CONSTANTE DE PLANCK, U+212F MINUSCULE E DE RONDE, U+2113 MINUSCULE L DE RONDE, U+2113 MINUSCULE L DE RONDE, U+2134 MINUSCULE O DE RONDE. Inversement, pour indiquer la constante de Planck, on devrait utiliser le caractère U+210E CONSTANTE DE PLANCK et non <i>h</i>.

5.3 Les caractères des marques d'élément de liste

Brève description : Les caractères avec une étiquette <cerclée>, ou les caractères avec une étiquette <compat> dont la décomposition de compatibilité correspond à une chaîne entre parenthèses.

Raisons de l'inclusion : Ces caractères s'utilisent le plus souvent dans des listes d'éléments énumérés, mais ceux dont la forme est <cerclée> apparaissent souvent comme caractères de casseau ou comme renvois de pied de page dans les tableaux. Les mêmes caractères s'utilisent dans un texte normal pour faire référence à un élément précis d'une liste numérotée.

Problèmes en contexte balisé : Ces caractères n'entraînent pas d'effets indésirables avec le balisage.

Problèmes dans d'autres contextes : Aucun

Balisage de remplacement : (style d'élément de liste) Lors de la génération d'un texte balisé, ces caractères interviennent seulement de manière interne à l'agent utilisateur quand les styles d'élément de liste sont restitués. Lors du balisage des données d'un texte brut, on pourra les convertir en styles d'élément de liste appropriés, s'il est possible de déduire ce style correctement. Toutefois, il s'avère souvent nécessaire d'utiliser les marques d'élément de liste, qu'il s'agisse d'un nombre ou d'une lettre, dans le corps du texte.

Il est permis de conserver une forme de compatibilité (n) ou (n.) en un seul caractère ou de la remplacer par un style de marque d'élément de liste. La conversion en style de marque d'élément de liste permet de prolonger facilement l'ensemble par des numéros/nombres arbitraires. Ceci tranche avec les caractères cerclés, pour lesquels la production correcte de numéros cerclés arbitraires est encore rare, et la conversion en style de marque d'élément de liste ne permet donc pas d'accroître facilement l'ensemble des numéros cerclés déjà disponibles.

Mesures à prendre si présence détectée : Aucune action nécessaire de la part des navigateurs. Dans un contexte d'édition, la substitution d'un style de marque d'élément de liste peut être appropriée. Cependant, ces mêmes caractères sont très souvent employés comme symboles de type casseau dans les tableaux, ou peuvent apparaître dans un texte général quand on renvoie à un élément de liste. C'est pourquoi l'utilisateur doit pouvoir choisir de remplacer ou non le caractère.

5.4 Les fractions

Brève description : Les fractions en un seul caractère tels que ½ et ¼.

Raisons de l'inclusion : Des sous-ensembles de ceux-ci apparaissent dans pratiquement tous les jeux de caractères préexistants.

Problèmes en contexte balisé : Le répertoire se limite à quelques fractions communes. Le problème de la double représentation se pose quand ces caractères sont utilisés dans des contextes de production de fractions plus puissants, comme le langage MathML [MathML].

Problèmes dans d'autres contextes : Mis à part les problèmes de normalisation, ces caractères ne présentent aucun effet indésirable dans un texte brut. Quand la barre de fraction est prise en charge, on peut les exprimer en leur substituant leurs correspondances de compatibilité.

Balisage de remplacement : MathML.

Mesures à prendre si présence détectée : Aucune action nécessaire de la part des navigateurs ou des logiciels d'édition, sauf lors de la conversion d'un texte brut vers MathML.

5.5 La disposition en carré ou à l'horizontale

Brève description : Symboles composés de chiffres et d'une barre oblique, typiquement de groupes de lettres kana ou latines, qui sont conçus pour être affichés dans une seule cellule de rendu dans l'affichage vertical d'un texte.

Raisons de l'inclusion : De nombreux jeux de caractères les contiennent sous forme de caractères précomposés, car, pour les mises en œuvre simples, c'est la seule façon de respecter l'usage courant qui consiste à afficher les unités de mesure et d'autres abréviations dans une seule cellule de caractère pour une composition verticale du texte.

Problèmes en contexte balisé : Le balisage proposé, y compris le style CSS, devrait pouvoir exprimer un ensemble illimité de ces abréviations, parant à la nécessité de les cataloguer dans le codage de caractères standard et les rendant plus directement accessibles à un traitement textuel, par exemple, pour effectuer une recherche.

Problèmes dans d'autres contextes : Le répertoire de ces caractères préexistants est limité ; en pratique, on utilise beaucoup plus de combinaisons que celles présentes dans les jeux de caractères. Les symboles précomposés ne permettent pas aux moteurs de recherche d'analyser leur contenu. Il faut également les recoder pour les restituer horizontalement.

Balisage de remplacement : La propriété de style text-combine dans la version de travail du module texte de CSS3 [CSS3Text].

Mesures à prendre si présence détectée : Aucune action nécessaire. (Sujet à des changements en attendant l'issue des propositions courantes).

5.6 Les caractères en exposant ou en indice

Brève description : Principalement des chiffres en exposant et en indice, mais aussi des signes, des parenthèses et quelques lettres.

Raisons de l'inclusion : Les caractères en exposant et en indice peuvent apparaître dans nombre de jeux de caractères préexistants, y compris le jeu Latin-1. Leur utilisation dans un texte entièrement brut est courante pour les bases de données, par exemple, l'inclusion d'unités de mesures pour des descriptions partielles (à savoir cm²), ou de formules (habituellement simplifiées) telles qu'elles se présentent dans les titres des publications scientifiques. Les lettres et chiffres en exposant et en indice ne sont pas rares dans certaines formes de transcriptions phonétiques et phonémiques. En particulier, on utilise souvent des petits chiffres en exposant pour indiquer la hauteur de ton.

Problèmes en contexte balisé : L'utilisation de ces caractères dans le texte balisé offre une représentation alternative par rapport au texte balisé et entraîne des traitements différents par les moteurs de recherche. Cependant, lorsque les écritures en exposant et en indice doivent refléter des distinctions sémantiques, il est plus commode de travailler avec ces significations codées dans le texte plutôt que dans le balisage, par exemple, pour une transcription phonétique ou bien phonémique. Lors de l'export vers un texte brut, ils peuvent être changés par inadvertance en un texte de style normal. Pour les lettres suscrites ou souscrites d'une transcripion phonétique, la signification en serait altérée. En revanche, certains agents utilisateurs ne peuvent afficher certains caractères en exposant ou en indice que dans un texte balisé.

Problèmes dans d'autres contextes : Aucun

Balisage de remplacement :<xhtml:sup> et <xhtml:sub>, ou <mathml:msup> et <mathml:msub>

Mesures à prendre si présence détectée : Aucune action nécessaire.

5.7 Les autres caractères marqués <compat>

Brève description : L'étiquette <compat> a été donnée à un ensemble de caractères de compatibilité dont la classification plus avant n'était pas établie au moment de la création du standard. Les composants majoritaires en sont les caractères de marque d'élément de liste.

Raisons de l'inclusion : Ces caractères apparaissent dans nombre de jeux de caractères préexistants.

Problèmes en contexte balisé : Aucun. Habituellement, il n'existe pas de balisage équivalent.

Problèmes dans d'autres contextes : Aucun

Balisage de remplacement : Aucun.

Mesures à prendre si présence détectée : Aucune action nécessaire.

6 Les non-caractères

Le standard Unicode définit 66  non-caractères. Il s'agit des deux dernières positions de chacun des 17 plans, autrement dit, de tous les caractères dont les points de code se terminent par ...FFFE ou ...FFFF, ainsi que des 32 points de code allant de U+FDD0 à U+FDEF. Les applications sont libres d'utiliser n'importe lequel de ces points de code de façon interne mais elles ne doivent jamais les échanger. En effet, on peut assimiler les non-caractères à des points de code à usage privé.

7. Le versionnage

Ce rapport sera mis à jour par le Comité technique Unicode en coopération avec le groupe de travail Internationalisation du W3C quand il faudra modifier les tableaux de caractères de ce document à la suite de l'ajout de caractères au standard Unicode, d'une remise en question de l'opportunité d'utiliser un caractère avec du balisage ou après avoir considéré de nouvelles informations ou recommandations.

Chaque rapport comporte un numéro de révision, qu'on peut utiliser pour citer une version particulière du rapport. Les versions plus anciennes du rapport resteront disponibles. Chaque version de ce rapport spécifie la version sous-jacente du standard Unicode.

Pour des précisions sur le standard Unicode et ses versions, voir :

• Les versions du standard Unicode [UnicodeVersions]
• Le document À propos de la base de données de caractères Unicode [UCD]
• La base de données de caractères Unicode [UnicodeData]

8. La conformité

Dans le cadre du standard Unicode, le matériel de ce rapport technique est informatif. Pourtant, d'autres documents, notamment les spécifications des langages de balisage, peuvent requérir de se conformer à ce document et le considérer comme normatif. Conformément au chapitre 7, il se peut qu'il faille mettre à jour les renvois à ce document à la suite de modifications qui lui seraient apportées.

9. Références

[Charmod]

Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Asmus Freytag, Tex Texin, rédacteurs, Un modèle de caractère pour le World Wide Web, version de travail du W3C du 30-avril-2002, <http://www.w3.org/TR/charmod>.

[CharReq]

Martin J. Dürst, Les conditions requises pour les définitons de l'identité des chaînes et de l'indexation des caractères pour le WWW, version de travail du W3C du 10-juillet-1998, <http://www.w3.org/TR/WD-charreq>.

[CSS2]

Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, rédacteurs, Les feuilles de style en cascade niveau 2 (spécification CSS2), recommandation du W3C du 12-mai-1998, <http://www.w3.org/TR/REC-CSS2/>.

[CSS3Text]

Michel Suignard, Chris Lilley, rédacteurs, Module CSS3 : le texte, recommandation candidate du W3C du 14-mai-2003, <http://www.w3.org/TR/css3-text/>.

[Feedback]

La signalisation des erreurs et la demande d'informations en ligne
<http://www.unicode.org/reporting.html>

[HTML 4.0]

Dave Raggett, Arnaud Le Hors, Ian Jacobs, rédacteurs, La spécification HTML 4.01, recommandation du W3C du 18-décembre-1997 (révisée le 24-décembre-1999), <http://www.w3.org/TR/REC-html40/>.

[HTML 4.0 - 8.2]

Chapitre 8.2 de la spécification [HTML4.0] La spécification de la direction du texte et des tables : l'attribut dir <http://www..w3.org/TR/html40/struct/dirlang.html#h-8.2>

[MathML]

David Carlisle, Patrick Ion, Robert Miner, Nico Poppelier, rédacteurs, Le langage de balisage mathématique (MathML) version 2.0, recommandation du W3C du 21-février-2001

<http://www.w3.org/TR/MathML2/>

[Namespace]

Tim Bray, Dave Hollander, Andrew Layman, Les espaces de nommage dans XML, recommandation du W3C du 14-janvier-1999, <http://www.w3.org/TR/REC-xml-names/>.

[Ruby]

Marcin Sawicki, Michel Suignard, Masayasu Ishikawa, Martin Dürst, Tex Texin, rédacteurs, L'annotation ruby, recommandation du W3C du 31-mai-2001, <http://www.w3.org/TR/ruby/>.

[Unicode]

Le standard Unicode, la version 3.0, The Unicode Standard, Version 3.0, (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5) ou en ligne à <http://www.unicode.org/standard/versions/Unicode3.0.html>.

[Unicode32]

Annexe au standard Unicode n° 28 Unicode 3.2, Le consortium Unicode, 2002.

[Unicode40]

Le standard Unicode, la version 4.0, The Unicode Standard, Version 4.0, (Reading, Massachusetts: Addison-Wesley Developers Press, 2003, ISBN 0-321-18578-1) ou en ligne à <http://www.unicode..org/versions/Unicode4.0.0/>.

[UCD]

À propos de la base de données de caractères Unicode, <http://www.unicode.org/ucd/>.

[UnicodeData]

La base de données de caractères Unicode, <http://www.unicode.org/Public/UNIDATA/UCD.html>.

[UnicodeVersions]

Les versions du standard Unicode, <http://www.unicode.org/unicode/standard/versions/>.

[UAX 9]

Mark Davis, Annexe au standard Unicode n° 9 : L'algorithme bidirectionnel, <http://www.unicode.org/reports/tr9/>.

[UAX 13]

Mark Davis, Annexe au standard Unicode n° 13 : Les instructions pour les sauts de ligne Unicode, <http://www.unicode.org/reports/tr13/>. À partir de Unicode 4.0.0 [Unicode40], ces instructions font désormais partie du livre.

[UAX 15]

Mark Davis, Martin Dürst, Annexe au standard Unicode n° 15 : Les formes de normalisation Unicode, <http://www.unicode.org/reports/tr15/>.

[UAX 29]

Mark Davis, Annexe au standard Unicode n° 29 : Les frontières de texte, http://www.unicode.org/unicode/reports/tr29/

[Variants]

Les variantes normalisées, <http://www.unicode.org/Public/UNIDATA/StandardizedVariants.html>.

[XHTML]

Steven Pemberton, et al., XHTML 1.0 : Le langage de balisage hypertexte extensible — Une reformulation de HTML 4 dans XML 1.0, recommandation du W3C, <http://www.w3.org/TR/xhtml1/>.

[XML 1.0]

Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, rédacteurs, Le langage de balisage extensible (XML) (2eme édition), recommandation du W3C du 6-octobre-2000, <http://www.w3.org/TR/REC-xml>.

10. Remerciements

Mark Davis (mark.davis@us.ibm.com) et Hideki Hiura (hideki.hiura@eng.sun.com) ont contribué aux premières versions.

11. Historique des changements (les plus récents d'abord)

Changements depuis http://www.unicode.org/reports/tr20/tr20-6.html : Ajouté les entrées des nouveaux caractères dans Unicode 4.0. Divisé et prolongé la discussion sur les caractères de format qui conviennent au balisage. Ce qui a abouti à une nouvelle section 2.6, au déplacement de la section 3.2 en 4, ainsi qu'à un renumérotage et aux nouvelles sections 4.1, 4.2, 4.3, 4.4. Ajouté une explication sur les non-caractères dans une nouvelle section 6. Réactualisé les références de Unicode 3.1 et 3.2 vers Unicode 4.0. Amélioré la disposition, une description de ce qui est maintenant le tableau 5.1. Changé l'action recommandée dans la section 5.6 à aucune. Réactualisé la section de statut Unicode. Changé http://www.unicode.org/unicode/reports/ pour http://www.unicode.org/reports tout du long afin de refléter le style préféré pour cet URL (les URL plus anciens sont toujours valides). Réactualisé les références aux publications du W3C. (AF/MJD)

Changements depuis http://www.unicode.org/reports/tr20/tr20-5.html : Réactualisé la référence de Unicode 3.0 vers 3.1 et 3.2 là où nécessaire. Ajouté les sections 3.6 et 3.9. Corrections de vocabulaire mineures dans les sections 2.3, 3.1, 3.2, 3.6, 3.10, 4.3, 4.5 et 5. (AF/MJD)

Changements depuis http://www.unicode.org/reports/tr20/tr20-4.html : Ajouté une remarque dans l'introduction sur la limitation de la portée. Réorganisé la section 3 et clarifié la langue. Renommé certaines sections et certains tableaux. Réactualisé le document afin de le préparer à la publication comme rapport technique Unicode et note du W3C (AF/MJD). Changements rédactionnels mineurs au texte, ajouté la section 4.7, corrigé quelques dates et coquilles. (AF)

Changements depuis http://www.unicode.org/reports/tr20/tr20-3.html : Changements rédactionnels mineurs dans l'introduction, corrigé quelques références, liens et dates, et quelques coquilles. (AF/MJD)

Changements depuis http://www.unicode.org/reports/tr20/tr20-2.html : Ajouté les sections 2.1-2.6 (MJD), les sections 3.1-3.5 et 3.8, ainsi que les sections 4.4-4.6 et 8 (AF). Édité le texte pour une publication comme rapport technique Unicode préliminaire. (AF)

Changements depuis http://www.unicode.org/reports/tr20/tr20-1.html : Achevé les références, relié la table des matières. Divers changements de vocabulaire. Ajouté la feuille de style des versions de travail, le logo, l'avis de copyright et le statut du document du W3C. Rationnalisé la sections sur les auteurs. (MJD) Ajouté du matériel concernant les caractères de compatibilité. (AF)

Changements depuis la première version préliminaire : Corrigé l'en-tête, le numérotage, le titre. Établi des références vers la version finale des fichiers de données en fonction des conventions de nommage. Changements de vocabulaire mineurs. Ajouté le texte proposé sur les caractères d'annotation afin de correspondre avec l'exemple sur FFFC. Posté pour révision en interne par le Comité technique Unicode et le W3C. (AF)

12. Droits d'auteur

Copyright © 1999-2003 Unicode^®, Inc. et W3C^® (MIT, ERCIM, Keio), tous droits réservés.

Ce document est publié conformément à la licence d'utilisation des documents du W3C ou la licence Unicode. Les documents mis à disposition par le W3C sont accompagnés de politiques supplémentaires en matière de garanties et de responsabilité, et de marque de commerce. La licence Unicode précise des conditions ayant trait à la garantie/responsabilité et à la marque de commerce dont :

Le consortium Unicode ne garantit en aucune façon, expresse ou implicite, et n'assume aucune responsabilité en ce qui concerne des erreurs ou omissions. Aucune responsabilité n'est endossée pour les dommages accidentels et consécutifs en rapport avec ou survenant en conséquence de l'utilisation des informations ou des programmes contenus dans ou accompagnant ce rapport technique.

Unicode et le logo Unicode sont des marques de fabrique de Unicode, Inc., qui sont déposées auprès de certaines juridictions.