Lisez-moi S.V.P. 

W3C

Un modèle de caractères pour le Web 1.0 : Les principes de base

Recommandation du W3C du 15 février 2005

Cette version :
http://www.w3.org/TR/2005/REC-charmod-20050215/
Dernière version :
http://www.w3.org/TR/charmod
Version précédente:
http://www.w3.org/TR/2004/PR-charmod-20041122/
Rédacteurs :
Martin J. Dürst, W3C <duerst@w3.org>
François Yergeau (expert invité)
Richard Ishida, W3C <ishida@w3.org>
Misha Wolf (jusqu'à décembre 2002), Reuters Ltd. <misha.wolf@reuters.com>
Tex Texin (expert invité), XenCraft <tex@XenCraft.com>

Veuillez consulter la liste des errata vf? de ce document, laquelle peut inclure des corrections normatives.

Cf. également d'éventuelles traductions.


Résumé

Cette spécification architecturale offre aux auteurs de spécifications, aux développeurs de logiciels et aux créateurs de contenus une référence commune, permettant ainsi l'interopérabilité dans la manipulation de textes sur le Web. ; elle s'appuie sur le jeu universel de caractères défini conjointement par le défini conjointement par le standard Unicode et la norme ISO/CEI 10646. Le document traite de l'utilisation des termes caractère, codage et chaîne de caractères, du modèle de traitement de référence, du choix et de l'identification des codages de caractères, des mécanismes de masquage et de l'indexation des chaînes.

Pour les questions concernant la normalisation et l'identité des chaînes de caractères, consulter le document d'accompagnement Un modèle de caractères pour le Web 1.0 : La normalisation [CharNorm]. Pour les identificateurs de ressource, cf. le document d'accompagnement Un modèle de caractères pour le Web 1.0 : Les identificateurs de ressource [CharIRI].

Statut du document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications courantes du W3C et la dernière version de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Ce document constitue la spécification intitulée Un modèle de caractères pour le Web 1.0 : Les principes de base, une recommandation du W3C vf. Elle a été passée en revue par les membres du W3C et des tiers intéressés et approuvée par le Directeur. C'est un document stable qui peut être utilisé comme matériel de référence ou cité comme référence normative par un autre document. Le rôle du W3C en produisant cette recommandation consiste à attirer l'attention sur la spécification et à en promouvoir un large déploiement. Elle contribue au fonctionnement et à l'interopérabilité du Web.

Ce document a été développé sous l'égide de l'Activité Internationalisation du W3C par le Groupe de travail Internationalisation (I18N WG) (accès réservé aux membres), avec l'aide du Groupe d'intérêts Internationalisation.

Veuillez adressez vos commentaires concernant ce document à la liste de diffusion www-i18n-comments@w3.org (archive publique). Les résultats du dernier appel à commentaires sont disponibles en version publique et en version réservée aux membres. Il existe aussi un rapport de mise en œuvre. Les changements apportés au document depuis la version de recommandation proposée sont détaillés dans l'annexe E Les changements survenus depuis la recommandation proposée.

Ce document a été produit sous couvert de la politique de brevetabilité courante du 24 janvier 2002 modifiée par la procédure de transition de la politique de brevetabilité du W3C. Le groupe de travail maintient une liste publique des divulgations de brevet concernant ce document ; cette page comprend également des instructions pour divulguer un brevet. Quiconque aurait connaissance de l'existence d'un brevet susceptible de contenir une (ou plusieurs) revendication essentielle concernant cette spécification devrait divulguer cette information conformément au chapitre 6 de la politique de brevetabilité du W3C.

Table des matières

Annexes


1 Introduction

1.1 Les objectifs et le champ d'application

Le modèle de caractères pour le Web est destiné à faciliter l'utilisation du Web pour tout le monde, sans égard à la langue, à l'écriture, au système d'écriture et aux conventions culturelles, et conformément au principe d'accès universel du W3C. Pour atteindre cet objectif, une condition préalable minimale est de pouvoir transmettre et traiter les caractères utilisés dans le monde entier d'une façon bien définie et bien comprise.

Le public principal visé par cette spécification est celui des développeurs de spécifications du W3C. La spécification peut être citée, en tout ou en partie, par les autres spécifications du W3C. Elle définit des critères de conformité tant pour les spécifications du W3C que pour celles d'autres organismes.

Les autres publics concernés comprennent les développeurs de logiciels, les créateurs de contenus et les auteurs de spécifications étrangers au W3C. Les développeurs de logiciels et les créateurs de contenus mettent en œuvre et utilisent les spécifications du W3C. Cette spécification définis quelques critères de conformité pour les mises en œuvre (les logiciels) et les contenus qui les utilisent. Elle aide également les développeurs de logiciels et les auteurs de contenus à comprendre les dispositions concernant les caractères prises dans les spécifications du W3C.

Le modèle de caractères décrit ici fournit à ces auteurs de spécifications, développeurs de logiciels et créateurs de contenus une référence commune permettant l'interopérabilité et la compatibilité dans la manipulation de textes sur le Web. Ces trois groupes professionnels peuvent œuvrer de concert à bâtir un Internet plus international.

Les sujets abordés dans cette partie du document du modèle de caractères pour le Web comprennent l'utilisation des termes caractère, codage et chaîne, un modèle de traitement de référence, le choix et l'identification des codages de caractères, les mécanismes de masquage des caractères et l'indexation des chaînes.

Les autres parties du modèle de caractères examinent la normalisation et l'identité des chaînes ([CharNorm]), et les conventions des identificateurs de ressource internationalisés (IRI) ([CharIRI]).

Les sujets qui n'ont pas encore été traités ou à peine effleurés comprennent les correspondances floues et l'étiquetage des langues. Certains de ces sujets pourront être étudiés dans une version future de la spécification.

Au cœur du modèle se trouve le Jeu universel de caractères (JUC) défini conjointement par le standard Unicode [Unicode] et la norme ISO/CEI 10646 [ISO/CEI 10646]. Dans ce document, on emploiera le terme Unicode comme un synonyme pour désigner le JUC. Le modèle permettra aux utilisateurs du monde entier d'échanger, de lire et d'interroger les documents Web créés dans toutes les écritures du monde.

1.2 Historique

Cette section expose l'arrière-plan historique des sujets traités dans cette spécification.

La communauté du Web a reconnu la nécessité d'un modèle de caractères pour le Web dès le document Internationalisation du langage de balisage hypertexte [RFC 2070]. La première étape de son installation fut l'adoption d'Unicode comme jeu de caractères de document pour le langage HTML.

Les motivations qui ont présidé au choix d'Unicode ont été les suivantes :

  • C'est le seul répertoire de caractères universel disponible ;

  • Il permet de faire référence aux caractères sans égard au codage du texte ;

  • Il est régulièrement mis à jour ou complété ;

  • Il est largement accepté et mis en œuvre par l'industrie.

Le W3C a adopté Unicode comme jeu de caractères de document pour HTML pour la spécification [HTML 4.0]. La même voie a été empruntée pour des spécifications telles que XML 1.0 [XML 1.0] et CSS2 [CSS2]. Les spécifications et applications du W3C utilisent maintenant Unicode comme jeu de caractères de référence commun.

À l'époque où un transfert de données sur le Web restait essentiellement unidirectionnel (de serveur à navigateur) et où l'objectif principal était de restituer des documents, l'utilisation d'Unicode, sans autre précision, suffisait. Néanmoins, le Web a évolué :

  • Les transferts de données se sont accrus, en tous sens, entre les serveurs, les serveurs mandataires et les clients ;

  • Les caractères hors du répertoire US-ASCII [ISO/CEI 646][MIME-charset] sont utilisés dans des circonstances plus variées ;

  • Les transferts de données se sont accrus entre des éléments de protocole/format différents (tels que les noms d'élément/attribut, les composants d'adresse URI et le contenu textuel) ;

  • On définit toujours plus d'interfaces de programmation d'applications (API), et pas seulement des protocoles et des formats.

En bref, on peut assimiler le Web à une seule très grande application (cf. [Nicol]), au lieu d'une collection de petites applications indépendantes.

Alors que ces développements confirment le bien-fondé du choix d'Unicode pour constituer la base d'un modèle de caractères pour le Web, ils induisent également la nécessité d'autres spécifications pour son application au Web. Les aspects d'Unicode qui nécessitent d'autres spécifications pour le Web comprennent :

  • Le choix des formes de codage Unicode (UTF-8, UTF-16, UTF-32) ;

  • Le comptage des caractères, la mesure de la longueur d'une chaîne en présence de codages de caractères de longueur variable et de caractères combinatoires ;

  • Les codages de caractères redondants (par exemple, ceux précomposés comparés à ceux décomposés) ;

  • L'utilisation de caractères de commande pour divers usages (par exemple, le contrôle de la bidirectionnalité, l'échange symétrique, etc.).

On remarquera que ces aspects existent également dans divers codages et que, souvent, Unicode en a hérité, d'une manière ou d'une autre, par leur intermédiaire.

La suite de la spécification présente les autres conditions nécessaires garantissant un modèle de caractères interopérable pour le Web, qui prennent en compte les travaux antérieurs du W3C, de l'ISO et de l'IETF.

La lecture des premiers chapitres du standard Unicode [Unicode] constitue une introduction très utile. Les politiques adoptées par l'IETF concernant l'utilisation des jeux de caractères sur Internet sont exposées dans le document [RFC 2277].

1.3 La terminologie et la notation

Les points de code Unicode se présentent sous la forme U+hhhh, où hhhh représente une suite d'au moins quatre et d'au plus six chiffres hexadécimaux.

Pour les exemples, on a utilisé du texte propre à être copié-collé par le lecteur. Les caractères employés ne s'afficheront pas comme prévu si vous ne disposez pas de la fonte appropriée mais on a pris soin d'annoter ces exemples pour qu'ils restent compréhensibles malgré tout. Dans certains cas, l'affichage du résultat d'un exemple est important, et on a donc employé des images ; en cliquant sur celles-ci, un lien mènera au texte de ces exemples dans l'annexe C Le texte des exemples.

2 La conformité

Ce chapitre présente les conditions que les spécifications, les mises en œuvre et les contenus Web doivent remplir pour prétendre à une conformité avec la présente spécification.

Les mots-clés DOI(VEN)T, NE DOI(VEN)T PAS, OBLIGATOIRE, DEVRA (DEVRONT), NE DEVRA (DEVRONT) PAS, DEVRAI(EN)T, NE DEVRAI(EN)T PAS, RECOMMANDÉ, PEU(VEN)T et OPTIONNEL dans ce document devront être interprétés comme prescrit par le document RFC 2119 [RFC 2119].

REMARQUE : Le document RFC 2119 est clair sur le fait que les conditions employant le terme DEVRAI(EN)T ne sont pas facultatives et doivent être respectées à moins de raisons particulières contraires : Ce terme, ou bien l'adjectif RECOMMANDÉ, signifie qu'il peut exister des raisons valides dans certaines circonstances pour ignorer un élément particulier, mais on doit comprendre et soupeser soigneusement toutes les implications avant de choisir une orientation différente.

Cette spécification définit des critères de conformité pour les spécifications, les mises en œuvre et le contenu Web. Pour assister le lecteur, tous les critères de conformité sont précédés par les caractères [X], où X représente l'une des lettres suivantes : S pour les spécifications, I pour les mises en œuvre et C pour le contenu Web. Ces marques indiquent la pertinence des critères de conformité et permettent au lecteur de localiser rapidement les critères pertinents en parcourant le document.

Une spécification est conforme à ce document si :

  1. Elle ne viole aucun critère de conformité précédé d'un [S] ;

  2. Elle documente la raison d'une éventuelle déviation par rapport aux critères dont l'impératif est DEVRAI(EN)T, NE DEVRAI(EN)T PAS ou RECOMMANDÉ ;

  3. Le cas échéant, cette spécification impose aux mises en œuvre qui lui sont conformes de l'être vis-à-vis de ce document ;

  4. Le cas échéant, cette spécification impose à un contenu qui lui est conforme de l'être vis-à-vis de ce document.

Une mise en œuvre (un logiciel) est conforme à ce document si elle ne viole aucun critère de conformité précédé d'un [I].

Un contenu est conforme à ce document s'il ne viole aucun critère de conformité précédé d'un [C].

REMARQUE : Les conditions imposées aux spécifications peuvent indirectement induire des obligations sur des mises en œuvre ou du contenu revendiquant la conformité à ces spécifications. De même, les conditions imposées à un contenu peuvent affecter les mises en œuvre prévues pour produire ce contenu, et ainsi de suite.

Lorsque la présente spécification impose des conditions de traitement, il faut le comprendre comme une façon de définir le comportement extérieur désiré. Les mises en œuvre peuvent employer d'autres moyens pour atteindre les mêmes résultats, tant que le comportement observable n'en est pas affecté.

3 Les perceptions des caractères

3.1 Introduction

L'article dans le glossaire du standard Unicode [Unicode 4.0] annonce :

Caractère. (1) Le plus petit composant du langage écrit qui a une valeur sémantique ; se rapporte à la signification et/ou à la forme abstraite...

On emploie le terme caractère dans beaucoup de contextes, dans des sens différents. Les cultures humaines ont des systèmes d'écriture radicalement différents, conduisant à des concepts de caractère qui le sont tout autant. Une telle variation dans l'expérience de l'utilisateur peut, et c'est souvent le cas, conduire à des méprises. Cette variation est parfois perçue comme la conséquence d'une technologie imparfaite. Au contraire, elle découle de la grande flexibilité et de la créativité de l'esprit humain, et de la longue tradition de l'écriture en tant que composant essentiel de l'héritage culturel humain. L'approche alphabétique suivie par les écritures latine, cyrillique et grecque n'en est qu'une parmi de nombreuses possibilités.

EXEMPLE : Un caractère dans les écritures japonaises hiragana et katakana correspond à une syllabe (en général, une combinaison d'une consonne et d'une voyelle).

EXEMPLE : L'écriture coréenne hangûl combine des symboles des sons individuels de la langue en blocs carrés représentant chacun une syllabe. En fonction de l'utilisateur et de l'application, soit les symboles individuels, soit les grappes syllabiques seront considérés comme des caractères.

EXEMPLE : Dans les écritures indiennes, chaque lettre consonne comporte une voyelle inhérente qui est éliminée ou remplacée en utilisant des moyens semi-réguliers ou irréguliers pour combiner les consonnes et les voyelles en grappes. En fonction de l'utilisateur et de l'application, soit les consonnes et voyelles individuelles, soit la consonne ou les grappes consonne-voyelle pourront être perçues comme des caractères.

EXEMPLE : En arabe et en hébreu, les voyelles ne sont normalement pas du tout transcrites. Lorsqu'elles sont écrites, on les indique par des marques combinatoires placées au-dessus ou au-dessous des consonnes.

Les développeurs de spécifications et ceux de logiciels fondés sur ces spécifications sont vraisemblablement plus familiers des usages du terme caractère dont ils ont l'expérience, plutôt que de la grande diversité des usages dans un contexte international. En outre, dans un contexte informatique, les caractères sont souvent confondus avec des concepts apparentés, ce qui aboutit à des spécifications et logiciels incomplets ou inadaptés.

Cette section examine certains de ces contextes, significations et confusions.

3.2 Les unités de restitution sonore

Dans certaines écritures, les caractères ont une relation étroite avec les phonèmes (un phonème est un son minimalement distinct dans le contexte d'une langue parlée particulière). Même lorsque les caractères correspondent (à peu près) aux phonèmes, cette relation peut être complexe et il existe rarement une correspondance un-pour-un entre un caractère et un phonème.

EXEMPLE : Dans la phrase française : Une réponse élusive. le même caractère s sert à représenter les deux phonèmes /s/ et /z/.

EXEMPLE : En français, le phonème /k/ dans le mot casaque est identique au phonème /k/ du mot kayak.

EXEMPLE : Dans beaucoup d'écritures, un seul caractère peut représenter une séquence de phonèmes, comme pour les caractères syllabiques du hiragana japonais.

EXEMPLE : Dans beaucoup de systèmes d'écriture, une séquence de caractères peut représenter un seul phonème, par exemple, en français ch, gn et on dans le mot chignon.

C001  [S]  [I]  [C]  Les spécifications, les mises en œuvre et les contenus NE DOIVENT PAS imposer ni dépendre d'une correspondance biunivoque (d'un-à-un) entre les caractères et les sons d'une langue.

3.3 Les unités de restitution visuelle

La restitution visuelle introduit la notion de glyphe. La norme ISO/CEI 9541-1 [ISO/CEI 9541-1] définit le glyphe comme un symbole graphique abstrait reconnaissable qui est indépendant d'un dessin particulier. Il n'y a pas de correspondance d'un-à-un entre les caractères et les glyphes :

  • Un seul caractère peut être représentés par plusieurs glyphes (chaque glyphe fait alors partie de la représentation de ce caractère). Ceux-ci peuvent être séparés physiquement les uns des autres ;

  • Un seul glyphe peut représenter une suite de caractères (c'est le cas, entre autres, des ligatures) ;

  • Un caractère peut être restitué par des glyphes très différents selon le contexte ;

  • Un seul glyphe peut représenter différents caractères (par exemple, la lettre latine A, la lettre grecque A majuscule et la lettre cyrillique A majuscule).

Un jeu de glyphes constitue une fonte ou police. On peut assimiler les glyphes aux unités élémentaires de l'organisation de la restitution visuelle du texte, tout comme les caractères aux unités élémentaires de l'organisation du texte codé.

C002  [S]  [I]  [C]  Les spécifications, les mises en œuvre et les contenus NE DOIVENT PAS imposer ni dépendre d'une correspondance biunivoque entre les caractères et les unités du texte affiché.

Cf. l'annexe B Exemples de caractères, de frappes de touche et de glyphes pour des exemples de la complexité des correspondances de caractère à glyphe.

3.3.1 La restitution visuelle et l'ordre logique

Certaines écritures, notamment l'arabe et l'hébreu, s'écrivent de droite à gauche. Un texte comprenant des caractères issus de ces écritures peut aller dans les deux sens et on le qualifie alors de texte bidirectionnel. Le standard Unicode [Unicode] impose que les caractères soient stockés et échangés selon un ordre logique, c'est-à-dire, correspondant grossièrement à l'ordre dans lequel le texte est saisi au clavier ou parlé (pour une définition plus détaillée, cf. [Unicode 4.0], section 2.2). L'ordonnancement logique est important pour assurer l'interopérabilité des données, et il favorise également l'accessibilité, la recherche et l'interclassement.

C003  [S]  [I]  [C]  Les protocoles, les formats de données et les interfaces de programmation (API) DOIVENT stocker, échanger ou traiter les données textuelles en ordre logique.

En présence d'un texte bidirectionnel, deux modes de sélection sont possibles. Le premier est le mode de sélection logique, lequel sélectionne tous les caractères situés logiquement entre les limites du geste de souris de l'utilisateur. Ici l'utilisateur effectue une sélection depuis le point situé entre la première et la deuxième lettre du deuxième mot jusqu'au milieu du nombre. La sélection logique ressemble à ceci :

Affichage visuel Le même exemple, montrant comment le texte apparaîtrait en surbrillance à l'écran, en deux étendues de caractères séparées
Ordre logique Un exemple montrant l'ordre logique des caractères dans
une chaîne contenant deux mots arabes suivis par une année en nombre. En mode de sélection logique, l'étendue de caractères sélectionnée
en commençant au milieu du deuxième mot et en finissant au milieu de l'année en nombre apparaît en surbrillance. La surbrillance
recouvre un seul bloc de caractères attenants.
Une sélection logique correspondant à des étendues visuelles non attenantes

Le fait qu'une seule sélection logique continue corresponde à une sélection discontinue à l'écran est une conséquence de la bidirectionnalité. Cette discontinuité incite certains utilisateurs à préférer un mode de sélection visuelle, lequel sélectionne tous les caractères situés visuellement entre les limites du geste de souris de l'utilisateur. Pour le même geste de souris, on obtient maintenant :

Affichage visuel Le même exemple montrant comment le texte apparaîtrait en surbrillance
à l'écran, en un seul bloc de caractères attenants.
Ordre logique Un exemple montrant l'ordre logique des caractères d'une chaîne contenant
deux mots arabes suivis par une année en nombre. En mode de sélection visuelle, l'étendue des caractères sélectionnés en commençant au
milieu du deuxième mot et en finissant au milieu du nombre apparaît en surbrillance. La surbrillance recouvre deux blocs de caractères
non attenants.
Une sélection visuelle correspondant à des étendues logiques non attenantes

En mode de sélection visuelle, comme illustré par l'exemple précédent, une seule étendue de sélection visuelle peut correspondre à deux (ou plus) étendues logiques, dont les protocoles, les interfaces de programmation (API) et les mises en œuvre devront peut être s'accommoder. Les autres aspects liés à l'interface d'utilisateur pour un texte bidirectionnel comprennent le mouvement de la marque d'insertion, le comportement des touches retour et effacement, et ainsi de suite.

Actuellement, la plupart des mises en œuvre offre une sélection logique mais peu une sélection visuelle.

C075 [I] Quel que soit le mode de sélection, logique ou visuel, utilisé par une implémentation, les caractères sélectionnés DOIVENT être gardés en ordre logique pour le stockage.

C004  [S]  Les spécifications de protocoles et d'interfaces de programmation (API) qui font intervenir une sélection d'étendues DEVRAIENT permettre les sélections logiques non attenantes, au moins assez pour permettre la mise en œuvre d'une sélection visuelle à l'écran couvrant ces protocoles et interfaces.

3.4 Les unités de saisie

Lors d'une saisie au clavier, les touches et les caractères saisis ne correspondent pas toujours un-à-un. Un clavier ne peut contenir qu'un nombre limité de touches ; certains claviers généreront plusieurs caractères à partir d'une seule touche ; parfois (cas des touches muettes), une touche ne générera pas de caractère mais agira sur le résultat des touches consécutives. Beaucoup de systèmes d'écriture comprennent tellement de caractères qu'ils ne tiendront pas tous sur un clavier, et on doit donc compter sur des méthodes de saisie plus complexes, qui transforment des successions de touches en séquences de caractères. D'autres langues peuvent nécessiter la saisie d'autres caractères avec des touches modificatrices particulières. Cf. l'annexe B Exemples de caractères, de frappes de touche et de glyphes pour des exemples de saisies compliquées.

C005  [S]  [I]  Les spécifications et les mises en œuvre NE DOIVENT PAS imposer ni compter sur le fait qu'une seule touche donnera un seul caractère ni qu'un seul caractère sera entré par une seule touche (même avec des modificateurs) ni que les claviers seront identiques dans le monde entier.

3.5 Les unités d'interclassement

La comparaison des chaînes telle qu'elle intervient dans un tri ou dans une recherche est fondée sur des unités qui, en général, n'ont pas de relation un-à-un avec les caractères codés. Cette comparaison de chaînes peut agréger une séquence de caractères en une seule unité d'interclassement ayant une position propre dans l'ordre de tri, elle peut séparer un caractère en plusieurs unités d'interclassement et elle peut distinguer les divers aspects d'un caractère (la casse, la présence de diacritiques, etc.) pour tri séparé (tri à plusieurs niveaux).

En outre, un prétraitement est parfois nécessaire et, dans certaines langues (tels que le japonais et l'arabe), l'ordre de tri peut dépendre de facteurs d'ordre supérieur tels que la phonétique et les racines des mots. Les méthodes d'interclassement peuvent également varier selon l'application.

EXEMPLE : Pour un tri traditionnel en espagnol, les séquences de caractères ch et ll sont traitées comme des unités d'interclassement atomiques. Bien que le tri espagnol, et dans une certaine mesure l'usage quotidien, assimile la séquence ch à une seule unité, les codages numériques actuels, ainsi que les claviers, la traitent comme deux caractères (l'utilisateur tape c puis h).

EXEMPLE : Dans certaines langues, la lettre æ est triée comme deux unités d'interclassement consécutives : a et e.

EXEMPLE : Le tri d'un texte dans une écriture bicamérale (c'est-à-dire une écriture avec des minuscules et des majuscules) ignore généralement les différences de casse lors d'une première passe ; la casse intervient pour départager les semblables au cours d'une passe suivante.

EXEMPLE : Le traitement des lettres accentuées dans un tri dépend de l'écriture ou de la langue en question. La lettre ö est traitée comme un o modifié en français mais comme une lettre entièrement indépendante de o en suédois (elle apparaît après la lettre z). En allemand, certaines applications traitent la lettre ö comme si c'était la séquence oe.

EXEMPLE : En thaïlandais, la séquence ไก (U+0E44 U+0E01) doit être triée comme si elle était écrite กไ (U+0E01 U+0E44). Ce réordonnancement est normalement exécuté au cours d'une étape de prétraitement initiale.

EXEMPLE : Les dictionnaires allemands rangent typiquement les lettres ä, ö et ü avec les lettres a, o et u, respectivement. Au contraire, les annuaires téléphoniques allemands trient typiquement les lettres ä, ö et ü comme si elles s'épelaient ae, oe et ue. Dans ce cas, l'application affectera l'algorithme d'interclassement employé.

C006  [S]  [I]  Les programmes de tri ou de recherche pour les utilisateurs DEVRAIENT s'exécuter en tenant compte des unités d'interclassement et des règles de classement appropriées pour la langue ou l'application concernées.

C007  [S]  [I]  Lorsque la recherche ou le tri sont dynamiques, en particulier dans un environnement multilingue, la langue concernée DEVRAIT être celle de l'utilisateur courant, et elle pourra donc différer d'un utilisateur à l'autre.

C066  [S]  [I]  Les programmes permettant à l'utilisateur de trier ou de rechercher un texte DEVRAIENT aussi lui permettre de sélectionner des règles pour les unités d'interclassement et pour le tri.

C008  [S]  [I]  Les spécifications et les mises en œuvre d'algorithmes de tri et de recherche DEVRAIENT accepter du texte contenant n'importe quels caractères Unicode.

Remarquez que ce critère impose au minimum que l'algorithme d'interclassement ne s'effondre pas si le texte contient des caractères Unicode non couverts par ses règles. Il n'impose pas forcément la mise en œuvre complète d'algorithmes complexes pour toutes les écritures. Un bon moyen de satisfaire cette condition consiste à appliquer un algorithme d'interclassement par défaut couvrant tous les caractères Unicode.

La norme ISO/CEI 14651 [ISO/CEI 14651] et le rapport technique Unicode n° 10 (cf. l'algorithme d'interclassement Unicode [UTR #10]), décrivent un modèle d'interclassement qui accepte la plupart des langues et qui donne un ordre d'interclassement par défaut. Ce sont des références essentielles concernant l'interclassement qui contiennent des conseils de mise en œuvre. On peut se servir de l'ordre d'interclassement par défaut, combiné à des règles adaptées aux paramètres liés à un lieu et à une langue particuliers, pour assurer des classements et comparaisons de chaînes prévisibles, quels que soient les caractères inclus.

3.6 Les unités de stockage

Le stockage et la communication des données informatiques s'appuient sur des unités de stockage physique et d'échange d'information, tels que les bits et les octets (des unités de 8 bits). Les spécifications et les mises en œuvre font souvent l'erreur de confondre caractères et unités de stockage physique. L'association entre les caractères et ces unités est, en réalité assez complexe et fera l'objet de la section 4.1 Le codage des caractères.

C009  [S]  [I]  Les spécifications, les mises en œuvre et les contenus NE DOIVENT PAS imposer ni dépendre d'une correspondance biunivoque entre les caractères et les unités de stockage physique.

3.7 Récapitulation

Le terme caractère qui s'emploie différemment dans des contextes divers conduit souvent à des confusions quand il est utilisé hors de ces contextes. Dans le cadre de la représentation numérique d'un texte, on peut définir un caractère comme une petite unité de texte logique. Le texte se définit alors comme une séquence de caractères. Bien que, dans beaucoup de cas, cette définition informelle suffise à établir ou à saisir une compréhension commune, elle est aussi suffisamment ouverte pour créer des malentendus dès lors qu'on entre dans les détails. Afin d'écrire, pour les utilisateurs finaux, des spécifications, des mises en œuvre de protocoles ou des logiciels effectifs, il est très important de comprendre que ces malentendus sont susceptibles de se produire.

Ce chapitre, 3 Les perceptions des caractères, a traité de termes d'unités qui ne recouvrent pas nécessairement le terme caractère, tels que phonème, glyphe et unité d'interclassement. Le chapitre suivant, 4.1 Le codage des caractères, liste les termes qu'il faudrait employer, au lieu de caractère, pour définir précisément les unités de codage (point de code, unité de stockage et octet).

C010  [S]  Quand les spécifications emploient le terme caractère, elles DOIVENT en définir le sens.

C067  [S]  Les spécifications DEVRAIENT employer des termes spécifiques, le cas échéant, au lieu du terme général caractère.

4 Le codage numérique des caractères

4.1 Le codage des caractères

Sur le Web, tout comme dans n'importe quel environnement informatique, les caractères doivent être codés pour être d'une quelconque utilité. Pour réaliser le codage du texte, une grande variété de codages de caractères ont été conçus. On peut les définir grossièrement comme des associations entre les séquences de caractères manipulées par les utilisateurs et les séquences de bits manipulées par les ordinateurs.

Face à la complexité du codage du texte et à la diversité des mécanismes de codage de caractères inventés tout au long de l'ère informatique, une description plus formelle du processus de codage se révèle utile. On peut décrire le processus de définition d'un codage de texte comme suit (cf. le rapport technique unicode n° 17 : Le modèle de codage des caractères [UTR #17] pour une description plus détaillée) :

  1. On identifie un ensemble de caractères à coder. Les caractères sont choisis de manière pragmatique pour exprimer du texte et afin de permettre des processus textuels divers dans une ou plusieurs langues cibles. Ils peuvent ne pas correspondre exactement à ce que les utilisateurs perçoivent comme des lettres ou d'autres caractères. L'ensemble des caractères est appelé un répertoire.

  2. Chaque caractère du répertoire est alors associé à un entier non négatif (nombre abstrait mathématique) : le point de code (appelé aussi numéro de caractère ou position de code). L'application du répertoire vers l'ensemble de ces entiers non négatifs qui en résulte s'appelle un jeu de caractères codés (JCC).

  3. Pour l'utiliser dans les ordinateurs, on identifie un type de donnée primitif convenable (tels qu'un octet, un seizet (16 bits) ou autre) et on se sert d'une forme stockée de caractères FSC, laquelle code les entiers abstraits d'un jeu de caractères codés (JCC) en séquences d'unités de stockage du type de donnée primitif. La forme naturelle des caractères peut être extrêmement simple (par exemple, celle qui code les entiers du jeu de caractères codés dans la représentation naturelle des entiers du type de donnée choisi de la plateforme informatique) ou bien arbitrairement complexe (un nombre variable d'unités de stockage, où la valeur de chaque unité est une fonction complexe de l'entier codé).

  4. Pour permettre une transmission ou un stockage au moyen de dispositifs par octets, un mécanisme de sérialisation de caractères (MSC), ou schéma de codage de caractères , est ensuite nécessaire. Un mécanisme de sérialisation est une application des unités de stockage d'une forme stockée des caractères (FSC) vers des séquences d'octets bien définies, en tenant compte de l'indication indispensable de l'ordre des octets pour les types de données primitifs à octets multiples et en incluant, dans certains cas, des schémas de commutation entre les unités de stockage de multiples mécanismes de sérialisation (par exemple, la norme ISO 2022). Un mécanisme de sérialisation, avec les jeux de caractères codés qu'il utilise, est appelé un codage de caractères, que l'on reconnaît par un identificateur unique, tel qu'un identificateur de type charset IANA. À partir d'une séquence d'octets représentant un texte et d'un codage de caractères reconnu par un identificateur charset, on peut en principe récupérer la séquence de caractères formant le texte sans ambiguïté.

REMARQUE : Cf. la section 4.4.2 L'identification du codage de caractères pour une explication du terme charset plus d'autres détails sur les codages de caractères.

REMARQUE : Le terme codage de caractères est quelque peu ambigu, dans la mesure où on l'emploie tantôt pour décrire le processus réel de coder les caractères, tantôt pour indiquer une façon particulière d'effectuer ce processus (comme dans l'expression : ce fichier est dans un codage de caractères X). Le contexte permet habituellement de distinguer entre ces usages dès lors que l'on a conscience de l'ambiguïté.

REMARQUE : Pour une séquence de caractères, un codage de caractères donné ne produira pas toujours la même séquence d'octets. En particulier, pour les codages fondés sur la norme ISO 2022 notamment, on pourra éventuellement disposer d'options au cours du processus de codage.

Dans les cas très simples, le processus de codage entier peut se ramener à une seule étape, une simple application d'un-à-un des caractères aux octets ; c'est le cas, par exemple, des codages US-ASCII [ISO/CEI 646] et ISO-8859-1.

On dit que le texte est dans une forme de codage Unicode s'il est codé en UTF-8, UTF-16 ou UTF-32.

4.2 Le transcodage

Le transcodage est le processus consistant à convertir un texte depuis un codage de caractères vers un autre. Les transcodeurs n'opèrent qu'au niveau du codage de caractères, sans analyser le texte ; en conséquence, ils ne s'occupent pas des mécanismes de masquage de caractère tels que les appels de caractères numériques (cf. 4.6 Les mécanismes de masquage) et n'ajustent pas les étiquettes de codage de caractères incorporées (par exemple, dans une déclaration XML ou dans un élément HTML meta).

REMARQUE : Un transcodage peut faire intervenir des transformations d'un-à-un, d'un-à-plusieurs ou de plusieurs-à-plusieurs. En outre, l'ordre de stockage des caractères varie entre les codages : certains, comme les formes de codage Unicode, prescrivent un ordre logique, tandis que d'autres utilisent un ordre visuel ; parmi les codages avec des diacritiques séparés, certains prescrivent leur placement avant le caractère de base, et d'autres après. À cause de ces différences dans le séquençage des caractères, le transcodage peut induire un réordonnancement : XYZ peut correspondre à yxz.

EXEMPLE : Ce premier exemple montre le transcodage du mot russe Русский, signifiant russe (la langue), depuis le codage Unicode UTF-16 vers le codage ISO 8859-5 :

UTF-16 ISO 8859-5
Unité de
stockage
Nom du caractère (abrégé) Unité de
stockage
Nom du caractère (abrégé)
0420 MAJUSCULE CYRILLIQUE ERRE C0 MAJUSCULE CYRILLIQUE ERRE
0443 MINUSCULE CYRILLIQUE OU E3 MINUSCULE CYRILLIQUE OU
0441 MINUSCULE CYRILLIQUE ESSE E1 MINUSCULE CYRILLIQUE ESSE
0441 MINUSCULE CYRILLIQUE ESSE E1 MINUSCULE CYRILLIQUE ESSE
043A MINUSCULE CYRILLIQUE KA DA MINUSCULE CYRILLIQUE KA
0438 MINUSCULE CYRILLIQUE I D8 MINUSCULE CYRILLIQUE I
0439 MINUSCULE CYRILLIQUE I BREF D9 MINUSCULE CYRILLIQUE I BREF

EXEMPLE : Ce deuxième exemple illustre un cas plus complexe dans lequel le mot arabe السلام, signifiant paix, est transcodé depuis le codage IBM CP864, ordonné visuellement et contextualisé, vers le codage UTF-16 d'Unicode :

IBM CP864 UTF-16
Unité de
stockage
Nom du caractère (abrégé) Unité de
stockage
Nom du caractère (abrégé)
EF MÎM ARABE FINAL 0627 ALIF ARABE
9E LAM-ALIF ARABE MÉDIAN 0644 LAM ARABE
D3 SÎN ARABE MÉDIAN 0633 SÎN ARABE
E4 LAM ARABE MÉDIAN 0644 LAM ARABE
C7 ALIF ARABE INITIAL 0627 ALIF ARABE
0645 MÎM ARABE

Notez que l'ordre des caractères a été inversé, que le caractère LAM-ALIF dans CP864 a été converti en une séquence LAM ALIF dans UTF-16 et que les variantes contextuelles (initiale, médiane ou finale) dans le codage source ont été converties en caractères génériques dans le codage cible.

4.3 Le modèle de traitement de référence

Beaucoup de protocoles et de formats de données Internet, et tout particulièrement les formats Web essentiels (HTML, CSS et XML), sont fondés sur du texte. Dans ces formats, tout est texte mais les spécifications concernées imposent une structure au texte, en attribuant une signification à certaines structures de façon à obtenir une certaine fonctionnalité en plus de celle offerte par le texte brut (le texte hors de la sphère d'un langage de balisage ou de programmation). Les langages HTML et XML sont des langages de balisage qui définissent des documents entièrement composés de texte mais avec des conventions permettant la distinction de ce texte en balisage et en données textuelles. D'après la spécification XML 1.0 [XML 1.0], section 2.4 vf :

Le texte se compose de données textuelles et de balisage. [...] Tout le texte qui n'est pas du balisage constitue les données textuelles du document.

Pour les besoins de cette section, l'aspect à retenir est que tout est texte, c'est-à-dire, une séquence de caractères.

Un objet de données textuelles est un message de protocole textuel entier ou un document textuel entier, ou une partie de celui-ci traitée séparément pour des besoins de stockage externe ou de récupération. Comme exemples, les entités analysables externes en XML et les corps des entités textuelles MIME [MIME-entity].

C013  [S]  [C]  Les objets de données textuelles définis par les spécifications de protocole ou de format DOIVENT être dans un seul codage de caractères.

Remarquez que ça ne veut pas dire qu'on ne puisse pas se servir des schémas de commutation d'un jeu de caractères tel que ISO 2022, puisque ces schémas effectuent une commutation de jeu de caractères au sein d'un seul codage de caractères.

Depuis les premiers jours, le Web a connu le développement d'un modèle de traitement de référence, d'abord décrit pour le langage HTML dans le document RFC 2070 [RFC 2070]. Ce modèle a été adapté ensuite par les langages XML et CSS. Il s'applique à n'importe quel format de donnée, ou protocole, fondé sur du texte comme décrit précédemment. L'essence du modèle de traitement de référence est l'utilisation d'Unicode comme référence commune. Toutefois, l'adoption du modèle de traitement de référence par une spécification n'impose pas à ses mises en œuvre d'utiliser effectivement Unicode. La seule obligation est qu'elles doivent se comporter comme si le traitement avait lieu selon la description du modèle. En outre, bien que ce document emploie l'intitulé modèle de traitement de référence et en décrive les propriétés en termes de traitement, le modèle s'applique également aux spécifications qui ne définissent pas explicitement de modèle de traitement.

C014[S] Toutes les spécifications qui font intervenir un traitement du texte DOIVENT le définir conformément au modèle de traitement de référence, à savoir :

  1. Les spécifications DOIVENT définir le texte en termes de caractères Unicode, et non pas en termes d'octets ni de glyphes.

  2. Pour leurs objets de données textuelles, les spécifications PEUVENT autoriser l'usage de tout codage de caractères transcodables dans une forme de codage Unicode.

  3. Les spécifications PEUVENT choisir d'interdire ou de déconseiller certains codages de caractères, et d'en rendre d'autres obligatoires. Indépendamment du codage de caractères effectif, le comportement défini DOIT être le même que si le traitement avait été le suivant :

    • Le codage de caractères de tout object de données textuelles que reçoit l'application mettant en œuvre la spécification DOIT être déterminé et l'objet de données DOIT être interprété comme une séquence de caractères Unicode ; ceci DOIT être équivalent au transcodage de l'objet de données en une certaine forme de codage Unicode (en ajustant, le cas échéant, toute étiquette de codage de caractères) et en le recevant dans la forme de codage Unicode en question ;

    • Tout le traitement DOIT avoir lieu sur cette séquence de caractères Unicode ;

    • Si l'application produit du texte, la séquence de caractères Unicode DOIT être codée selon un codage de caractères choisi parmi ceux autorisés par la spécification.

  4. Si une spécification est telle que plusieurs objets de données textuelles soient concernés (comme un document XML appelant des entités analysables externes), elle PEUT permettre que ces objets de données aient des codages de caractères différents. Quel que soit le cas, le modèle de traitement de référence DOIT s'appliquer à tous les objets de données textuelles.

REMARQUE : Toutes les spécifications définissant des applications de la spécification XML 1.0 [XML 1.0] héritent automatiquement de ce modèle de traitement de référence. Le langage XML est entièrement défini en termes de caractères Unicode et impose les codages de caractères UTF-8 et UTF-16, en admettant toutefois n'importe quel autre codage de caractères pour les entités analysables.

REMARQUE : Lorsque les spécifications choisissent d'autoriser des codages de caractères autres que les formes de codage Unicode, les développeurs devraient savoir que la correspondance entre les caractères de ces codages et les caractères Unicode peut en fait dépendre du logiciel utilisé pour le transcodage. Cf. le profil XML japonais [XML Japanese Profile] pour des exemples de telles incohérences.

C070 [S]  Les spécifications NE DEVRAIENT PAS exclure arbitrairement les points de code de l'étendue entière des points de code Unicode compris dans l'intervalle U+0000 à U+10FFFF inclus.

C077 [S]  Les spécifications NE DOIVENT PAS autoriser les points de code au-delà de U+10FFFF.

Unicode contient quelques points de code destinés à usage interne (tels que les non-caractères) ou à des fonctions spéciales (tels que les points de code de substitution).

C079 [S] Les spécifications NE DEVRAIENT PAS autoriser l'utilisation des points de code réservés à un usage interne par Unicode.

C078 [S]  Les spécifications NE DOIVENT PAS autoriser l'utilisation des points de code de substitution.

Exclure des points de code sans raison valable contredit l'objectif d'accessibilité universelle du W3C. Cette mise à l'écart est susceptible d'empêcher l'emploi de certaines écritures pouvant être importantes pour une ou plusieurs communautés d'utilisateurs. Par exemple, sans raisons impératives de le faire, les décisions d'exclure les points de code supérieurs au Plan de base multilingue ou de restreindre les points de code aux répertoires US-ASCII ou Latin-1 ne sont pas recevables. Veuillez noter également que le standard Unicode impose aux logiciels de ne pas corrompre les points de code.

On trouvera d'autres exemples de raisons légitimes et non arbitraires d'exclure des caractères dans le document Unicode dans XML et les autres langages de balisage [UXML], où on déconseille l'utilisation de certains caractères dans les cas suivants :

  • Ils sont déconseillés dans le standard Unicode ;

  • Ils ne peuvent être gérés sans données supplémentaires ;

  • Ils sont mieux pris en compte par le balisage ;

  • Ils sont en conflit avec un balisage équivalent.

4.4 Le choix et l'identification des codages de caractères

Puisqu'on ne peut pas interpréter ni traiter un texte codé si on ignore son codage, il est d'importance vitale de connaître ce codage de caractères (cf. 4.1 Le codage de caractères), à tout instant et partout où on échange, stocke ou traite du texte. Dans ce qui suit, nous employons le terme codage de caractères dans le sens soit de forme stockée de caractères (FSC), soit de mécanisme de sérialisation (MSC), selon le contexte. Lorsque le texte est transmis ou stocké en tant que flux d'octets, par exemple, dans un protocole ou dans un système de fichiers, on mentionnera obligatoirement un MSC pour une interprétation correcte. Dans des contextes comme celui d'une interface de programmation d'application (API), où l'environnement (l'architecture du processeur typiquement) détermine l'ordre des octets des multiplets, une mention FSC suffira.

C015  [S]  Les spécifications DOIVENT soit définir un codage de caractères unique, soit fournir un mécanisme d'identification du codage de caractères, afin d'identifier le codage du texte avec certitude.

C016  [S]  En cas de création initiale d'un protocole, d'un format ou d'une interface de programmation (API), les spécifications DEVRAIENT imposer un codage de caractères unique.

C017  [S]  Lorsqu'un protocole, un format ou une interface de programmation (API) est fondé sur un autre protocole, format ou API déjà munis de règles de codage de caractères, les spécifications DEVRAIENT utiliser celles-ci plutôt que d'en changer.

EXEMPLE : Un format basé sur XML devrait se servir des règles XML existantes pour choisir et déterminer le codage de caractères des entités externes au lieu d'en inventer de nouvelles.

4.4.1 L'imposition d'un codage de caractères unique

L'imposition d'un codage de caractères unique est simple, efficace et robuste. Elle rend inutile de définir, de produire, de transmettre ou d'interpréter des étiquettes de codage. Le codage de caractères sera toujours compris par le récepteur. Il n'y aura également aucune ambiguïté concernant le codage de caractères à utiliser si les données étaient transmises par un biais non électronique puis devaient être reconverties en une représentation numérique. Même lorsqu'il faut assurer une compatibilité vis-à-vis de données, systèmes, protocoles ou applications existants, on peut toujours négocier les codages de caractères multiples aux limites ou en-dehors d'un protocole, d'un format ou d'une interface de programmation (API). Le modèle objet du document (DOM [DOM niveau 1] en est un exemple. Le choix d'un codage de caractères unique est plus avantageux lorsque le volume de texte est faible ou qu'il s'agit d'une spécification proche du traitement réel à effectuer.

C018  [S] Lorsqu'un codage de caractères unique est imposé, ce codage DOIT être UTF-8, UTF-16 ou UTF-32.

Le codage US-ASCII est compatible ascendant avec UTF-8 (une chaîne US-ASCII est aussi une chaîne UTF-8, cf. [RFC 3629]) et, par conséquent, le codage UTF-8 convient si on souhaite être compatible avec le codage US-ASCII. Dans d'autres situations, comme pour les interfaces de programmation (API), les codages UTF-16 ou UTF-32 seront peut-être plus appropriés. Les raisons possibles du choix de l'un d'eux sont à chercher dans l'efficacité du traitement interne et dans l'interopérabilité avec d'autres processus.

REMARQUE : La politique en matière de jeu de caractères de l'IETF [RFC 2277] indique que, sur Internet : Les protocoles DOIVENT être capables d'utiliser le jeu de caractères UTF-8.

REMARQUE : La spécification XML 1.0 [XML 1.0] impose à tous les processeurs XML conformes d'accepter les codages UTF-16 et UTF-8.

4.4.2 L'identification du codage de caractères

La spécification Internet MIME offre un bon exemple de mécanisme d'identification du codage de caractères [MIME-charset][RFC 2978]. La définition du paramètre MIME charset est destinée à fournir suffisamment d'information pour décoder, de façon unique, la séquence d'octets constituant les données reçues en une séquence de caractères. Les valeurs proviennent du registre des jeux de caractères de l'IANA [IANA].

REMARQUE : Malheureusement, certaines étiquettes charset ne représentent pas un codage de caractères unique. Au contraire, ces identificateurs représentent un certain nombre de petites variations. Bien que légères, ces différences peuvent être cruciales et varier au cours du temps. Pour ces identificateurs, la récupération de la séquence de caractères à partir d'une séquence d'octets est ambiguë. Par exemple, le caractère codé 0x5C dans le codage Shift_JIS est ambigu : ce point de code représente tantôt un SIGNE YEN tantôt une BARRE OBLIQUE INVERSÉE. Cf. [XML Japanese Profile] pour plus de détails sur cet exemple et pour d'autres exemples de tels identificateurs de jeu de caractères ambigus.

REMARQUE : Le terme charset est une abréviation pour jeu de caractères, dont l'histoire est longue et tortueuse (cf. [Connolly] pour une explication).

C020  [S]  Les spécifications DEVRAIENT éviter l'emploi des termes jeux de caractères et charset pour désigner un codage de caractères, sauf ce dernier quand il désigne le paramètre MIME charset ou ses valeurs enregistrées auprès de l'IANA. L'expression codage de caractères ou, dans des cas particuliers, les expressions forme stockée de caractères ou mécanisme de sérialisation de caractères, sont RECOMMANDÉES.

REMARQUE :Dans le langage XML, la déclaration XML, ou la déclaration de texte, contient un pseudo-attribut encoding qui identifie le codage de caractères au moyen d'une étiquette charset de l'IANA.

Le registre des jeux de caractères de l'IANA représente la liste officielle des noms et des alias de mécanisme de sérialisation de caractères sur Internet.

C021  [S]  Si l'option de codage unique n'est pas retenue, les spécifications DEVRAIENT imposer l'emploi des noms du registre des jeux de caractères de l'IANA et, en particulier, ceux identifiés comme noms MIME préférés, pour désigner les codages de caractères dans les protocoles, les formats de données et les interface de programmation (API).

C022  [S]  [I]  [C]  On NE DEVRAIT PAS se servir de codages de caractères absents du registre de l'IANA, sauf en cas d'accord mutuel.

C023  [S]  [I]  [C]  Si on se sert d'un codage de caractère non enregistré, on DOIT respecter la convention consistant à faire précéder le nom de x-.

C049  [I]  [C]  Le choix du codage de caractères du contenu DEVRAIT intervenir de façon à maximiser les occasions de représentation directe des caractères (c.à.d., minimiser le besoin de représenter les caractères par du balisage, tels que des masquages de caractère), tout en se gardant d'utiliser des codages obscurs qui seront vraisemblablement incompris des destinataires.

REMARQUE : Bénéficiant d'un vaste répertoire et d'un large appui, un codage de caractères fondé sur Unicode représentera un choix judicieux pour le codage des documents.

C034  [C]  Si des fonctions d'identification du codages de caractères sont prévues, le contenu DOIT s'en servir ; lorsque ces fonctions incluent des valeurs par défaut (par exemple, dans le langage XML 1.0 [XML 1.0]), compter sur ces valeurs suffit pour satisfaire cette exigence d'identification.

C024  [I]  [C]  Les contenus et logiciels étiquetant les données textuelles DOIVENT utiliser l'un des noms imposés par la spécification concernée (par exemple, la spécification XML pour la création d'un texte XML) et DEVRAIENT utiliser l'étiquette MIME préféré du codage de caractères pour étiqueter les données qui sont dans ce codage de caractères.

C025  [I]  [C]  On NE DOIT PAS utiliser une étiquette charset enregistrée auprès de l'IANA pour étiqueter des données textuelles dans un autre codage de caractères que celui identifié par l'enregistrement IANA de cette étiquette.

C026  [S]  Si l'option de codage unique n'est pas retenue, les spécifications DOIVENT désigner au moins l'une des formes de codage Unicode UTF-8 ou UTF-16 comme codage de caractères admissible et DEVRAIENT choisir au moins l'une des deux formes UTF-8 ou UTF-16 comme codage obligatoire (parmi les codages qui DOIVENT être gérées par les mises en œuvre de la spécification).

C027  [S]  Les spécifications qui imposent un codage par défaut DOIVENT définir soit UTF-8, soit UTF-16 comme codage par défaut, ou les deux si elles définissent des moyens convenables pour les distinguer.

C028  [S]  Les spécifications NE DOIVENT PAS proposer l'emploi de moyens heuristiques pour déterminer le codage des données.

Comme exemples de moyens heuristiques, l'utilisation de l'analyse statistique des fréquences (de configuration) d'octets ou des fréquences (de configuration) de caractères. Les méthodes heuristiques sont mauvaises parce qu'elles ne fonctionneront pas de la même manière entre des mises en œuvre différentes. Les instructions bien définies sur la manière de déterminer sans ambiguïté un codage de caractères, comme celles données dans la spécification XML 1.0 [XML 1.0], Annexe F vf, ne sont pas considérées comme étant des méthodes heuristiques.

C029  [I]  Le logiciel récepteur DOIT déterminer le codage des données à partir des informations disponibles conformément aux spécifications concernées.

C030  [I]  Si le logiciel récepteur reconnaît une étiquette charset enregistrée auprès de l'IANA, alors il DOIT interpréter les données reçues conformément au codage associé au nom dans le registre de l'IANA.

C031  [I]  Si aucun charset n'est fourni, le logiciel récepteur DOIT adhérer au(x) codage(s) de caractères implicite(s) défini(s) par la spécification.

Le logiciel récepteur peut reconnaître autant de codages de caractères et autant de noms et d'alias de ceux-ci que nécessaires.

Un mécanisme de mise à jour en ligne peut convenir à cet usage. Certains codages de caractères sont associés, à des degrés divers, à certaines langues (par exemple, le codage Shift_JIS et le japonais). La volonté de prise en compte d'une certaine langue ou d'une clientèle donnée peut signifier d'avoir à gérer certains codages de caractères. Toutefois, on ne peut pas supposer la reconnaissance universelle d'un codage qui, bien qu'étant favori, n'est pas obligatoire. Les codages de caractères qui doivent être reconnus peuvent changer au cours du temps. Ce document ne conseille pas de codage de caractères censé convenir ou être nécessaire à la gestion d'une langue donnée.

En raison de la structure en couches du Web (par exemple, les formats utilisés sur les protocoles), plusieurs sources d'information concernant le codage de caractères peuvent coexister et parfois se contredire.

C035  [S]  Les spécifications DOIVENT définir des mécanismes de résolution de conflit (par exemple, des règles de priorité) au cas où existeraient des informations multiples ou conflictuelles concernant le codage de caractères.

C033  [I]  Les logiciels DOIVENT mettre en œuvre entièrement les mécanismes d'identification des codages de caractères et de résolution de conflit.

4.5 Les points de code à usage privé

Certaines étendues de points de code Unicode sont destinées à un usage privé : la zone à usage privé (ZUP), de U+E000 à U+F8FF, et les plans 15 et 16, de U+F0000 à U+FFFFD et de U+100000 à U+10FFFD. Ces points de code sont garantis ne jamais être attribués à des caractères standards ; ils sont réservés à un usage en accord mutuel. Toutefois, les accords mutuels ne s'ajustent pas les uns les autres sur le Web : les points de code appartenant à des accords mutuels différents peuvent se télescoper. En outre, un accord mutuel est susceptible de disparaître rapidement, la signification de ces points de code se perdant alors avec lui.

C073  [C]  Un contenu échangé publiquement NE DEVRAIT PAS utiliser de points de code de la zone à usage privé.

REMARQUE : Une exception typique est celle consistant à utiliser la zone à usage privé pour créer et tester le codage d'écritures encore non codées (par exemple, une écriture historique ou rare).

C076 [C] Un contenu NE DOIT PAS utiliser de point de code pour toute autre destination que celle définie par son jeu de caractères codés (JCC).

Cette disposition interdit, par exemple, la construction de fontes qui détournent les points de code du jeu de caractères ISO Latin 1 pour représenter des écritures, des caractères ou des symboles différents de ceux effectivement codés en iso-8859-1.

C038  [S]  Les spécifications NE DOIVENT PAS imposer l'utilisation de caractères de la zone à usage privé à des affectations particulières.

C039  [S]  Les spécifications NE DOIVENT PAS imposer l'utilisation de mécanismes pour définir des accords sur les points de code à usage privé.

C040  [S]  [I]  Les spécifications et les mises en œuvre NE DEVRAIENT PAS interdire l'utilisation par un accord mutuel des points de code à usage privé.

Comme exemple, le langage XML n'interdit pas l'utilisation des points de code à usage privé.

C041  [S]  Les spécifications PEUVENT définir un balisage afin de permettre la transmission de symboles absents d'Unicode ou afin d'identifier des variantes spécifiques de caractères Unicode.

EXEMPLE : Le langage MathML (cf. [MathML2] section 3.2.9 vf) définit un élément mglyph pour les symboles mathématiques absents d'Unicode.

EXEMPLE : Le langage SVG (cf. [SVG] section 10.14 vf) définit un élément altglyph qui permet l'identification de variantes d'affichage particulières de caractères Unicode.

C068 [S] Les spécifications DEVRAIENT permettre d'inclure ou d'appeler des images et des graphiques, là où c'est nécessaire, afin que les mécanismes prévus pour des caractères ne soient pas utilisés (détournés) pour des images ou des graphiques.

4.6 Les mécanismes de masquage

Les langages de balisage ou de programmation désignent couramment certains caractères comme étant syntaxiques, en leur attribuant des fonctions particulières au sein du langage (par exemple, les caractères < et > servent de délimiteurs de balisage dans les langages HTML et XML). Par conséquent, on ne peut pas utiliser ces caractères syntaxiques pour leur propre représentation dans un texte de la même façon que les autres caractères, ce qui crée le besoin d'un mécanisme permettant de masquer leur signification syntaxique. Il y a aussi un besoin, souvent satisfait par le même mécanisme ou un mécanisme similaire, d'exprimer les caractères qui ne sont pas directement représentables par le codage de caractères choisi pour un document particulier, ou un programme particulier (une instance du langage de balisage ou de programmation).

Formellement, un mécanisme de masquage de caractère est un dispositif syntaxique, défini dans un langage de balisage ou de programmation, qui permet d'accomplir l'une (ou plusieurs) des tâches suivantes :

  1. Exprimer les caractères syntaxiques en ne tenant pas compte de leur signification dans la syntaxe du langage ;

  2. Exprimer les caractères non représentables dans le codage de caractères choisi pour une instance du langage ;

  3. Exprimer les caractères, en général, sans utiliser les caractères codés correspondants.

Échapper un caractère signifie exprimer celui-ci au moyen d'un tel dispositif syntaxique, qui est approprié au format, ou au protocole, dans lequel le caractère apparaît ; démasquer un caractère (démasquage) signifie le remplacer par le caractère qu'il représente.

EXEMPLE : Les langages HTML et XML définissent des appels de caractère numériques qui permettent à la fois de masquer une signification syntaxique et d'exprimer des caractères Unicode arbitraires. Par exemple, exprimé sous les formes &#x3C; ou &#60;, le caractère < ne sera pas interprété comme un délimiteur de balisage.

EXEMPLE : Le langage de programmation Java se sert de guillemets anglais doubles " pour délimiter les chaînes. Pour exprimer un tel " au sein d'une chaîne, on peut le masquer ainsi : \".

EXEMPLE : Le langage XML définit des sections CDATA qui permettent de masquer la signification syntaxique de tous les caractères compris entre leurs délimiteurs. Les sections CDATA empêchent l'expression des caractères en utilisant des appels de caractère numériques.

Les conseils suivants traitent de la façon dont les spécifications doivent définir les mécanismes de masquage des caractères.

  • C042  [S]  Les spécifications NE DEVRAIENT PAS inventer de nouveau mécanisme de masquage s'il en existe déjà un qui convient.

  • C043  [S]  Le nombre de façons différentes de masquer un caractère DEVRAIT être réduit (et idéalement être égal à un).

    Un contre-exemple bien connu est celui des langages HTML et XML qui, pour des raisons historiques, comportent tous les deux des masquages de caractère redondants, l'un décimal (&#ddddd;) et l'autre hexadécimal (&#xhhhh;) redondants.

  • C044  [S]  La syntaxe de masquage DEVRAIT imposer soit un délimiteur final explicite, soit un nombre de caractères fixe pour chaque masquage de caractère. Une syntaxe de masquage dont la fin est déterminée par un caractère en-dehors de l'ensemble des caractères admissibles dans le masquage de caractère en question DEVRAIENT être évitée.

    Ces masquages de caractère qui ne sont pas clairement visibles peuvent amener un éditeur à insérer des sauts de ligne douteux à l'occasion de retours à la ligne sur des espaces. Les formes, comme &UABCD; du langage SPREAD [SPREAD] et &#xhhhh; du langage XML, où le masquage de caractère se termine explicitement par un point-virgule, sont bien plus fiables.

  • C045  [S]  Chaque fois que les spécifications définissent des masquages de caractère permettant la représentation des caractères par un nombre, ce nombre DOIT représenter le point de code Unicode du caractère et il DEVRAIT être en notation hexadécimale.

  • C046  [S]  Les caractères masqués DEVRAIENT être acceptables partout où leurs formes démasquées le sont ; cela n'empêche pas que les caractères syntaxiques, lorsqu'ils sont masqués, perdent leur signification dans la syntaxe. En particulier, si un caractère est acceptable dans les identificateurs ou les commentaires, alors sa forme masquée devrait aussi l'être.

Les conseils suivants concernent les développeurs de contenus ainsi que les logiciels qui génèrent ces contenus :

  • C047  [I]  [C]  On DEVRAIT seulement utiliser des masquages quand les caractères à exprimer ne sont pas directement représentables dans le format ou le codage de caractères du document, ou quand la représentation visuelle des caractères est incertaine.

    REMARQUE : Un exemple où la représentation visuelle d'un caractère est incertaine est celui de l'utilisation du masquage &nbsp; pour distinguer une espace insécable d'une espace normale.

  • C048  [I]  [C]  Le contenu DEVRAIT utiliser la forme hexadécimale de masquage de caractère de préférence à la forme décimale lorsque les deux existent.

    REMARQUE : La forme hexadécimale est préférée parce que les standards de codage de caractères (en particulier Unicode) énumèrent habituellement les numéros de caractère sous forme hexadécimale, ce qui facilite les consultations.

5 Les caractères de compatibilité et de formatage

Cette spécification ne traite pas du bien-fondé de l'utilisation de tels ou tels caractères dans les langages de balisage, en particulier les caractères de formatage et les équivalents de compatibilité. Cf. Unicode dans XML et les autres langages de balisage [UXML] pour des conseils d'utilisation précis des caractères d'édition et de compatibilité.

C050  [S]  Les spécifications DEVRAIENT exclure l'utilisation de caractères de compatibilité dans les éléments syntaxiques (balisage, délimiteurs, identificateurs, etc.) des formats qu'elles définissent.

6 Les chaînes

6.1 Les concepts de chaîne

Diverses spécifications emploient la notion de chaîne, tantôt sans définir précisément ce qui est signifié, tantôt avec une définition qui diffère des autres spécifications. Les raisons de cette variabilité tiennent au fait qu'il existe plusieurs définitions raisonnables d'une chaîne, dépendant de ce que l'on attend de la notion ; on emploie le terme chaîne pour toutes ces notions car elles représentent en fait juste des vues différentes de la même réalité : un morceau de texte stocké dans un ordinateur.

Chaîne d'octets : Une chaîne vue comme une séquences d'octets représentant des caractères dans un codage de caractères particulier. Elle correspond à un mécanisme de sérialisation de caractères (MSC). Le traitement du texte d'une chaîne d'octets dépend du codage particulier employé. Lorsque le codage change, le traitement doit également changer pour refléter la structure du nouveau codage. Ce changement est susceptible d'imposer une réfection significative des fonctions ou de l'interface de programmation (API) utilisées pour traiter les chaînes d'octets comme du texte. C'est pourquoi, cette définition n'est utile, dans les spécifications, que lorsque la nature textuelle d'une chaîne n'importe pas et qu'on assimile celle-ci à un morceau de données opaques avec une longueur exprimée en octets (comme lors de la copie d'un tampon de mémoire).

C011  [S]  Les spécifications NE DEVRAIENT PAS définir une chaîne comme étant une chaîne d'octets.

EXEMPLE : Voici un contre-exemple illustrant pourquoi le fait d'assimiler les chaînes à des chaînes d'octets peut se révéler problématique. Soit un texte contenant le caractère U+233B4 (un caractère chinois signifiant souche d'arbre) codé en UTF-16 selon l'ordre des octets gros-boutien (UTF-16BE). Le texte contiendra les octets D8 4C DF B4. Si on recherche, dans ce texte considéré comme une chaîne d'octets, le caractère U+4CDF (un autre caractère chinois signifiant phénix), on obtiendra une fausse correspondance sur les octets 4C DF qui sont la représentation UTF-16BE du caractère U+4CDF.

Chaîne d'unités de stockage : Une chaîne vue comme une séquence d'unités de stockage représentant des caractères dans un codage de caractères particulier. Elle correspond à une forme stockée de caractères (FSC). La définition d'une chaîne d'unités de stockage doit inclure la dimension des unités de stockage (par exemple, 16 bits) et le codage de caractères employé (par exemple, UTF-16). Les chaînes d'unités de stockage sont utiles dans les interfaces de programmation (API) lesquelles exposent une représentation physique des données textuelles reposant sur une connaissance fiable des formes de codage vraisemblablement candidates à l'implémentation. Par exemple, pour le DOM [DOM niveau 1], le codage UTF-16 a été choisi du fait d'une pratique de mise en œuvre largement répandue. En général, une chaîne d'unités de stockage ne se révèle utile que si les codages candidats à l'implémentation sont vraisemblablement UTF-16 ou UTF-32.

Chaîne de caractères : Une chaîne vue comme une séquence de caractères, chacun représenté par un point de code dans Unicode [Unicode]. C'est ce que les programmeurs considèrent habituellement comme étant une chaîne, bien que cela puisse ne pas correspondre exactement à ce que la plupart des utilisateurs assimile à des caractères. C'est la couche d'abstraction la plus élevée assurant une interopérabilité avec un moindre effort de mise en œuvre. La définition de chaîne de caractères d'une chaîne est généralement la plus commode. Quelques bons exemples obéissant à cette définition comprennent la production [2] du langage XML 1.0 [XML 1.0], la déclaration SGML du langage HTML 4.0 [HTML 4.01] et le modèle de caractères décrit dans le document RFC 2070 [RFC 2070].

C012  [S]  La plupart des spécifications DEVRAIT utiliser la définition d'une chaîne de caractères.

EXEMPLE : Soit la chaîne composée des caractères U+233B4 (un caractère chinois signifiant souche d'arbre), U+2260 PAS ÉGAL À, U+0071 LETTRE MINUSCULE LATINE Q et U+030C DIACRITIQUE CARON, codée en UTF-16 en ordre des octets gros-boutien. Les rangées du tableau suivant montrent la chaîne vue en tant que chaîne de caractères, chaîne d'unités de stockage et chaîne d'octets, respectivement :

Glyphes Caractère idéographique supplémentaire: caractère chinois archaïque signifiant «  souche d'arbre » (encore utilisé en cantonais) PAS ÉGAL À LETTRE MINUSCULE LATINE Q DIACRITIQUE CARON
Chaîne de caractères U+233B4 U+2260 U+0071 U+030C
Chaîne d'unités de stockage D84C DFB4 2260 0071 030C
Chaîne d'octets D8 4C DF B4 22 60 00 71 03 0C

REMARQUE : On peut aussi assimiler une chaîne à une séquence de grappes de graphèmes. Les grappes de graphèmes divisent le texte en unités qui correspondent plus étroitement que les chaînes de caractères à la perception que l'utilisateur a de la position des limites des caractères dans un texte restitué visuellement. Une explication des grappes de graphèmes est donnée à la fin de la section 2.10 du standard Unicode, version 4 [Unicode 4.0] ; on trouvera une définition formelle dans l'annexe n° 29 du standard Unicode [UTR #29]. Le standard Unicode définit une mise en grappes des graphèmes par défaut. Certaines langues imposent une adaptation à cette définition par défaut. Par exemple, un utilisateur slovaque peut vouloir traiter le couple de grappes de graphèmes par défaut ch comme une seule grappe de graphèmes. Notez aussi que l'interaction entre la langue du contenu textuel et les préférences de l'utilisateur final peut être complexe.

6.2 L'indexation des chaînes

Il y a beaucoup de situations dans lesquelles un traitement logiciel a besoin d'accéder à une sous-chaîne ou un point dans une chaîne, ce qu'il parvient à faire en se servant d'indices, c'est-à-dire, des positions numériques dans une chaîne. Lorsque de tels indices sont échangés entre des composants du Web, il est nécessaire de s'accorder sur une définition de l'indexation d'une chaîne, afin d'assurer un fonctionnement compatible. Les conditions requises pour l'indexation d'une chaîne sont abordées dans Les conditions requises pour l'identité des chaînes [CharReq], chapitre 4. Les deux questions qui se posent sont les suivantes : Quelle est l'unité de comptage ? et Le comptage commence-t-il à 0 ou à 1 ?.

L'exemple de la section précédente 6.1 Les concepts de chaîne montre, respectivement, une chaîne vue comme une chaîne de caractères, une chaîne d'unités de stockage et une chaîne d'octets, chacune de ces vues impliquant des unités d'indexation différentes.

En fonction des exigences particulières d'un processus, l'unité de comptage sera susceptible de correspondre aux définitions d'une chaîne fournies dans la section 6.1 Les concepts de chaîne. En particulier :

  • C051  [S]  [I]  On RECOMMANDE la chaîne de caractères comme base pour l'indexation des chaînes.

    (EXEMPLE : le langage de chemin XML [XPath]).

  • C052  [S]  [I]  On PEUT se servir d'une chaîne d'unités de stockage comme base pour l'indexation d'une chaîne si, comparée à l'utilisation d'une chaîne de caractères, l'efficacité des opérations internes s'en trouve améliorée de manière significative.

    (EXEMPLE : l'utilisation du codage UTF-16 dans [DOM niveau 1]).

  • C071  [S]  [I]  On PEUT utiliser des grappes de graphèmes comme base pour l'indexation d'une chaîne dans les applications pour lesquelles l'interaction avec l'utilisateur constitue la préoccupation majeure.

    Cf. L'annexe n° 29 du standard Unicode Les limites de texte [UTR #29].

    C074 [S] Les spécifications qui définissent l'indexation en termes de grappes de graphèmes DOIVENT soit a) définir les grappes de graphèmes en fonction des grappes de graphèmes par défaut, comme défini dans l'annexe n° 29 du standard Unicode Les limites de texte [UTR #29], soit b) définir spécifiquement comment la personnalisation s'appliquera à l'opération d'indexation.

  • C072  [S]  [I]  L'utilisation d'une chaîne d'octets N'EST PAS RECOMMANDÉE pour l'indexation.

À noter qu'il existe d'autres moyens non numériques d'identifier des sous-chaînes qui présentent des propriétés avantageuses. Par exemple, les sous-chaînes basées sur une comparaison de chaînes sont plutôt robustes face aux petites éditions ; celles basées sur la structure d'un document (dans des formats structurés comme XML) sont encore plus robustes face aux éditions, et même face à la traduction d'un document d'une langue à une autre.

C053  [S]  Les spécifications qui ont besoin d'identifier des sous-chaînes ou un point au sein d'une chaîne DEVRAIENT offrir d'autres moyens qu'une indexation de chaîne pour réaliser cette opération.

C054  [I]  [C]  Les utilisateurs des spécifications (les développeurs de logiciels, les créateurs de contenus, etc.) DEVRAIENT, chaque fois que possible, préférer d'autres moyens qu'une indexation de chaîne pour identifier des sous-chaînes ou un point au sein d'une chaîne.

L'expérience prouve que les spécifications présentent un caractère plus robuste, flexible et général lorsque les caractères individuels sont compris et traités comme des sous-chaînes identifiées par une position avant et une position après la sous-chaîne. Comprendre les indices comme des positions de limite entre les unités de comptage facilite également la mise en équivalence des indices obtenus à partir des différentes définitions de chaîne.

C055  [S]  Les spécifications DEVRAIENT comprendre et traiter les caractères seuls comme des sous-chaînes, et considérer les indices comme des positions de limite entre les unités de comptage, quel que soit le choix des unités de comptage.

C056  [S]  Les spécifications des interfaces de programmation (API) NE DEVRAIENT PAS définir de caractères seuls ou d'unités de stockage seules comme argument ni comme type renvoyé.

EXEMPLE : La fonction uppercase("ß") ne peut pas renvoyer le résultat exact (la chaîne composée des deux caractères SS) si le type renvoyé par la fonction uppercase est défini comme étant un caractère seul. Remarquez également qu'il n'y a pas forcément de correspondance un-à-un entre les caractères et les unités de son, de saisie, etc., comme décrit dans le chapitre 3 Les perceptions des caractères.

La question de l'origine des indices, c'est-à-dire, si on compte à partir de 0 ou de 1, ne se pose en réalité qu'après la décision de compter soit les unités elles-mêmes, soit les positions entre ces unités.

C057  [S]  Lorsqu'on compte les positions entre les unités pour indexer une chaîne, la solution RECOMMANDÉE est de commencer par un indice de 0 pour la position au début de la chaîne, et l'indice final sera donc égal au nombre d'unités de comptage dans la chaîne.

7 Les références au standard Unicode et à la norme ISO/CEI 10646

Les spécifications ont souvent besoin de se référer au standard Unicode ou à la norme internationale ISO/CEI 10646. Ces références doivent être faites soigneusement, surtout quand elles sont normatives. Les questions à considérer sont les suivantes :

Le standard ISO/CEI 10646 est développé et publié conjointement par l'ISO et par la CEI. Le standard Unicode est développé et publié par le Consortium Unicode, une organisation d'entreprises informatiques majeures, d'éditeurs de logiciels, de vendeurs de bases de données, de gouvernements nationaux, d'instituts de recherche, d'agences internationales et de divers groupes d'utilisateurs et individus intéressés. Le standard Unicode a un statut normatif comparable aux recommandations du W3C.

La norme ISO/CEI 10646 et le standard Unicode définissent exactement le même jeu de caractères codés (JCC) (même répertoire, mêmes points de code) et les mêmes formes de codage. Ils sont activement maintenus en synchronisme grâce à des liaisons entre leurs comités techniques respectifs, qui ont des membres en commun. Outre le jeu de caractères codés et les formes de codage définis conjointement, le standard Unicode ajoute des listes de propriétés de caractère normatives et informatives, des spécifications normatives d'équivalence des caractères et de normalisation, un algorithme normatif pour le texte bidirectionnel et quantité d'informations de mise en œuvre utiles. En bref, le standard Unicode apporte une sémantique aux caractères dont la norme ISO/CEI 10646 fait simplement l'énumération. La conformité au standard Unicode implique la conformité à l'ISO/CEI 10646, cf. [Unicode 4.0], Annexe C.

C062  [S]  Dans la mesure où les spécifications ont besoin, généralement, à la fois d'une définition pour leurs caractères et de la sémantique qui leur est associée, elles DEVRAIENT comporter une référence au standard Unicode, qu'elles se réfèrent ou non à la norme ISO/CEI 10646.

En fournissant une référence au standard Unicode, les développeurs peuvent bénéficier de la richesse des informations offertes par le standard et le site Web du Consortium Unicode.

Le fait que la norme ISO/CEI 10646 et le standard Unicode évoluent (en synchronisme) pose la question des versions : une spécification devrait-elle se référer à une version particulière du standard, ou bien devrait-elle s'y référer de manière générique, de sorte que la référence normative vise la version courante au moment de la lecture de la spécification ? En général, la réponse est : les deux !

C063  [S]  On DOIT se référer au standard Unicode génériquement si on souhaite que les caractères alloués après la publication de la spécification puissent être utilisés avec celle-ci. On PEUT inclure une référence spécifique au standard Unicode afin de s'assurer qu'une fonctionnalité attachée à une version particulière soit disponible et ne changera pas avec le temps.

Un exemple serait l'ensemble des caractères admissibles comme caractères de nom dans XML 1.0 [XML 1.0], qui forme une liste énumérée que les analyseurs doivent mettre en œuvre pour valider les noms.

REMARQUE : Cf. http://www.unicode.org/unicode/standard/versions/#Citations pour des conseils sur la manière de désigner des versions spécifiques du standard Unicode.

Une référence générique peut se formuler de deux façons :

  1. En incluant explicitement une entrée générique dans la bibliographie d'une spécification et en s'y référant simplement depuis le corps de la spécification. Une telle entrée générique contiendra une mention de ce genre : [...] tel que révisé ou amendé de temps à autre.

  2. En incluant une entrée spécifique dans la bibliographie et en ajoutant une mention de ce genre : [...] tel que révisé ou amendé à l'endroit de l'appel dans le corps de la spécification.

La formulation à adopter relève des choix éditoriaux de chaque spécification. Cette spécification adopte la première formulation (cf. les entrées [ISO/CEI 10646] et [Unicode]). On trouvera des exemples de la deuxième formulation ainsi qu'une discussion concernant le versionnement des paramètres MIME charset pour les codages du JUC dans les documents [RFC 3629] et [RFC 2781].

C064  [S]  Toutes les références génériques au standard Unicode [Unicode] DOIVENT en citer la dernière version disponible à la date de publication de la spécification qui les contient.

C065  [S]  Toutes les références génériques à la norme ISO/CEI 10646 [ISO/CEI 10646] DOIVENT en citer la dernière version disponible à la date de publication de la spécification qui les contient.

A Références

A.1 Les références normatives

IANA
Les noms officiels des jeux de caractères, Internet Assigned Numbers Authority, (cf. http://www.iana.org/assignments/character-sets).
ISO/CEI 10646
Technologies de l'information — Jeu universel de caractères codés sur plusieurs octets (JUC), ISO/CEI 10646:2003, tel que, de temps à autre, amendé, remplacé par une nouvelle édition ou augmenté de nouvelles parties. Cf. http://www.iso.org/iso/fr/ISOOnline.openerpage pour la dernière version.
MIME-entity
Les extensions de courrier Internet multiusages (MIME) — première partie : le format du corps des messages Internet, N. Freed, N. Borenstein, RFC 2045, novembre 1996 (cf. http://www.ietf.org/rfc/rfc2045.txt).
MIME-charset
Les extensions de courrier Internet multiusages (MIME) — deuxième partie : les types de média, N. Freed, N. Borenstein, RFC 2046, novembre 1996 (cf. http://www.ietf.org/rfc/rfc2046.txt).
RFC 2119
Les mots-clés à utiliser dans les documents RFC pour indiquer les niveaux d'obligation, S. Bradner, IETC RFC 2119 (cf. http://www.ietf.org/rfc/rfc2119.txt).
Unicode
The Unicode Consortium, Le standard Unicode, version 4, ISBN 0-321-18578-1, tel que mis à jour de temps à autre par de nouvelles versions. Cf. http://www.unicode.org/unicode/standard/versions pour la dernière version et des renseignements concernant les versions du standard et de la base de données de caractères Unicode.
Unicode 3.2
The Unicode Consortium, Le standard Unicode, version 3.2.0 est défini par Le standard Unicode, version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), amendé par l'Annexe n° 27 du standard Unicode : Unicode 3.1 (cf. http://www.unicode.org/reports/tr27) et par l'Annexe n° 28 du standard Unicode : Unicode 3.2 (cf. http://www.unicode.org/reports/tr28).
Unicode 4.0
The Unicode Consortium, Le standard Unicode, version 4.0, Reading, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1. Cf. http://www.unicode.org/versions/Unicode4.0.0/.

A.2 Les autres références

CharNorm
Un modèle de caractères pour le Web 1.0 : La normalisation, Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Tex Texin, Addison Phillips, rédacteurs, version préliminaire du W3C (cf. http://www.w3.org/TR/charmod-norm).
CharIRI
Un modèle de caractères pour le Web 1.0 : Les identificateurs de ressource, Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Tex Texin, rédacteurs, recommandation candidate du W3C (cf. http://www.w3.org/TR/charmod-resid).
CharReq
Les conditions requises pour la correspondance de chaîne à l'identique et l'indexation des chaînes, Martin J. Dürst, version préliminaire du W3C (cf. http://www.w3.org/TR/WD-charreq).
Connolly
"Jeu de caractères" réputé nuisible, D. Connolly, note du W3C (cf. http://www.w3.org/MarkUp/html-spec/charset-harmful).
CSS2
Les feuilles de style en cascade niveau 2 vf (spécification CSS2), Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, rédacteurs, recommandation du W3C (cf. http://www.w3.org/TR/REC-CSS2).
DOM niveau 1
La spécification du modèle objet de document (DOM) niveau 1 vf, Vidur Apparao et al., recommandation du W3C (cf. http://www.w3.org/TR/REC-DOM-Level-1).
HTML 4.0
La spécification HTML 4.0, Dave Raggett, Arnaud Le Hors, Ian Jacobs, rédacteurs, recommandation du W3C, 18 décembre 1997 (cf. http://www.w3.org/TR/REC-html40-971218).
HTML 4.01
La spécification HTML 4.01 vf, Dave Raggett, Arnaud Le Hors, Ian Jacobs, rédacteurs, recommandation du W3C (cf. http://www.w3.org/TR/html401).
ISO/CEI 646
Technologies de l'information — Jeu ISO de caractères codés à 7 éléments pour l'échange d'information, ISO/CEI 646:1991 ; cette norme définit une version de référence internationale (IRV) qui correspond exactement à ce qui est largement connu sous le vocable ASCII ou US-ASCII. La norme ISO/CEI 646 se fondait sur le standard précédent ECMA-6. L'ECMA a maintenu son standard à jour avec ISO/CEI 646 et en propose une copie électronique à http://www.ecma-international.org/publications/standards/Ecma-006.htm
ISO/CEI 9541-1
Technologies de l'information — Échange d'informations sur les fontes -- Partie 1 : Architecture, ISO/CEI 9541-1:1991 (cf. http://www.iso.ch/iso/fr/CatalogueDetailPage.CatalogueDetail?CSNUMBER=17277 pour la dernière version).
ISO/CEI 14651
Technologies de l'information — Classement international et comparaison de chaînes de caractères — Méthode de comparaison de chaînes de caractères et description du modèle commun et adaptable d'ordre de classement, ISO/CEI 14651:2000, tel qu'amendé, remplacé par une nouvelle édition ou augmenté de nouvelles parties (cf. http://www.iso.org/iso/fr/ISOOnline.openerpage pour la dernière version).
MathML2
Le langage de balisage mathématique (MathML version 2.0 vf, David Carlisle, Patrick Ion, Robert Miner, Nico Poppelier, rédacteurs, recommandation du W3C (cf. http://www.w3.org/TR/MathML2).
Nicol
Le Web multilingue, Gavin Nicol, chapitre 2 : Le Web comme application multilingue (cf. http://www.mind-to-mind.com/library/papers/multilingual/multilingual-www.html).
RFC 2070
Internationalisation du langage de balisage hypertexte, F. Yergeau, G. Nicol, G. Adams, M. Dürst, IETC RFC 2070, janvier 1997 (cf. http://www.ietf.org/rfc/rfc2070.txt).
RFC 2277
La politique de l'IETF concernant les jeux de caractères et les langues, H. Alvestrand, IETC RFC 2277, BCP 18, janvier 1998 (cf. http://www.ietf.org/rfc/rfc2277.txt).
RFC 2978
Les procédures d'enregistrement de charset de l'IANA, N. Freed, J. Postel, IETC RFC 2978, BCP 19, octobre 2000 (cf. http://www.ietf.org/rfc/rfc2978.txt).
RFC 3629
UTF-8 : un format de transformation de ISO 10646, F. Yergeau, IETC RFC 3629, STD 63, novembre 2003 (cf. http://www.ietf.org/rfc/rfc3629.txt).
RFC 2781
UTF-16 : un codage de ISO 10646, P. Hoffman, F. Yergeau, IETC RFC 2781, février 2000 (cf. http://www.ietf.org/rfc/rfc2781.txt).
SPREAD
SPREAD — Un projet de standardisation des documents d'Asie Orientale : L'ensemble d'entités publiques universel, (cf. http://www.ascc.net/xml/resource/entities/index.html)
SVG
La spécification des graphiques vectoriels adaptables (SVG) 1.1 vf, Jon Ferraiolo, 藤沢 淳 (FUJISAWA Jun), Dean Jackson, rédacteurs, recommandation du W3C (cf. http://www.w3.org/TR/SVG).
UTR #10
L'algorithme d'interclassement Unicode, Mark Davis, Ken Whistler, rapport technique Unicode n° 10 (cf. http://www.unicode.org/unicode/reports/tr10).
UTR #17
Le modèle de codage des caractères, Ken Whistler, Mark Davis, rapport technique Unicode n° 17 (cf. http://www.unicode.org/unicode/reports/tr17).
UTR #29
Les limites de texte, Mark Davis, annexe du standard Unicode n° 29 (cf. http://www.unicode.org/unicode/reports/tr29 pour la dernière version).
UXML
Unicode dans XML et les autres langages de balisage vf, Martin Dürst et Asmus Freytag, rapport technique Unicode n° 20 et note du W3C (cf. http://www.w3.org/TR/unicode-xml).
XML 1.0
Le langage de balisage extensible (XML) 1.0 vf, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, rédacteurs, recommandation du W3C (cf. http://www.w3.org/TR/REC-xml).
XML Japanese Profile
Le profil japonais XML, MURATA Makoto, rédacteur, note du W3C (cf. http://www.w3.org/TR/japanese-xml).
XPath
Le langage de chemin XML (XPath) version 1.0 vf, James Clark, Steve DeRose, rédacteurs, recommandation du W3C (cf. http://www.w3.org/TR/xpath).

B Exemples de caractères, de frappes de touche et de glyphes (non normatif)

Quelques exemples vont permettre de comprendre toute cette complexité du texte dans les ordinateurs (qui est principalement le reflet de la complexité des systèmes d'écriture humains). Commençons par un exemple très simple : un utilisateur équipé d'un clavier américain tape Foo, ce que l'ordinateur code en valeurs 16-bits (le codage UTF-16 Unicode) et affiche à l'écran.

Touches Majuscule-f o o
Caractères saisis F o o
Caractères codés (valeurs d'octet en hexadécimal) 0046 006F 006F
Affichage Foo
EXEMPLE : Latin de base

La seule difficulté ici est l'emploi d'un modificateur (Majuscule) pour saisir le F majuscule.

Un exemple légèrement plus complexe est celui d'un utilisateur tapant çé sur un clavier français traditionnel, ce que l'ordinateur code à nouveau en UTF-16 et affiche. Nous supposons que cet ordinateur particulier utilise une forme entièrement composée du codage UTF-16.

Touches ¸ c é
Caractères saisis ç é
Caractères codés (valeurs d'octet en hexadécimal) 00E7 00E9
Affichage çé
EXEMPLE : Latin avec diacritiques

Un certain nombre de choses intéressantes apparaissent ici : lorsque l'utilisateur tape la cédille ¸, rien ne se produit sauf un changement d'état du pilote du clavier ; la cédille est une touche muette. Lorsque le pilote reçoit la frappe de touche c, il présente un caractère ç complet au système, qui le représente par une seule unité de stockage de 16-bits et affiche un glyphe ç. L'utilisateur appuie ensuite sur la touche dédiée é, ce qui produit, à nouveau, un caractère représenté par deux octets. La plupart des systèmes l'afficheront comme un seul glyphe mais il est également possible de combiner deux glyphes (la lettre de base et l'accent) pour obtenir la même restitution.

Maintenant un exemple en japonais : l'utilisateur emploie une méthode de saisie romaji pour saisir 日本語 (U+65E5, U+672C, U+8A9E), ce que l'ordinateur code en UTF-16 et affiche.

Touches n i h o n g o <espace> <entrée>
Caractères saisis
Caractères codés (valeurs d'octet en hexadécimal) 65E5 672C 8A9E
Affichage Trois caractères kanji U+65E5, U+672C, U+8A9E, prononcés 'nihongo'.
EXEMPLE : Japonais

Ici c'est la saisie qui constitue l'aspect intéressant : l'utilisateur tape des caractères latins, qui sont convertis à la volée en caractères kana (non visibles ici) puis en kanji lorsque l'utilisateur lance la conversion en pressant la touche espace ; les caractères kanji sont finalement envoyés à l'application lorsque l'utilisateur presse la touche entrée. L'utilisateur doit frapper un total de neuf touches avant que les trois caractères ne soient produits, lesquels sont alors codés et affichés assez simplement.

Un exemple en persan, utilisant l'écriture arabe, fera apparaître des phénomènes différents :

Touches LETTRE ARABE LAM LETTRE ARABE ALIF LIGATURE ARABE LAM-ALIF LETTRE ARABE FARSI YA LETTRE ARABE FARSI YA
Caractères saisis ل ا ل ا ی ی
Caractères codés (valeurs d'octet en hexadécimal) 0644 0627 0644 0627 06CC 06CC
Affichage La sortie s'affiche de droite à gauche : deux ligatures LAM-ALIF et un glyphe initial farsi yeh relié à un glyphe final farsi yeh.
EXEMPLE : Persan

Ici les deux premières frappes de touche produisent chacune un caractère d'entrée et un caractère codé mais le couple s'affiche comme un seul glyphe (LIGATURE ARABE LAM-ALIF, une ligature LAM-ALIF). La frappe de touche suivante est un LAM-ALIF, qui fait partie de certains claviers arabes ; elle produit les deux mêmes caractères qui s'affichent identiquement mais ce second LAM-ALIF se place à la gauche du premier à l'affichage. Les deux dernières frappes de touche produisent deux caractères identiques qui sont restitués par deux glyphes différents (une forme médiale suivie à sa gauche par une forme finale). Nous avons donc 5 frappes de touche produisant 6 caractères et 4 glyphes disposés de droite à gauche.

Un dernier exemple en tamoul, tapé avec un clavier ISCII, révèle d'autres phénomènes :

Touches LETTRE TAMOULE TTA VOYELLE DIACRITIQUE TAMOULE Â LETTRE TAMOULE NGA SYMBOLE TAMOUL VIRÂMA LETTRE TAMOULE KA VOYELLE DIACRITIQUE TAMOULE Ô
Caractères saisis
Caractères codés (valeurs d'octet en hexadécimal) 0B9F 0BBE 0B99 0BCD 0B95 0BCB
Affichage 'Tango' en lettres tamoules.
EXEMPLE : Tamoul

Ici l'entrée est directe mais remarquez que, contrairement à l'exemple latin accentué, le symbole (U+0BCD SYMBOLE TAMOUL VIRÂM) est tapé après la lettre (U+0B99 LETTRE TAMOULE NGA) à laquelle celui-ci s'applique. La restitution est intéressante pour les deux derniers caractères. Le dernier (U+0BCB VOYELLE DIACRITIQUE TAMOULE Ô) se compose manifestement de deux glyphes qui entourent le glyphe de l'antépénultième caractère (U+0B95 LETTRE TAMOULE KA).

C Le texte des exemples (non normatif)

La suite représente les versions textuelles des chaînes ou caractères utilisés dans les exemples avec images de ce document. On les fournit ici pour l'agrément de ceux qui désirent couper-coller le texte pour leurs propres expériences.

  1. Section : 3.3 Les unités de restitution visuelle

    EXEMPLE : Un exemple montrant l'ordre logique des caractères dans une chaîne contenant
deux mots arabes suivis par une année en chiffres. En mode de sélection logique, l'étendue des caractères sélectionnés en commençant
la sélection au milieu du second mot et en finissant au milieu de l'année en chiffres est dessinée en surbrillance. La surbrillance
couvre un seul bloc de caractères attenants.

    Texte : عدد مارس ١٩٩٨

  2. Section : 6.1 Les concepts de chaîne

    EXEMPLE : Caractère supplémentaire idéographique : un caractère chinois archaïque
signifiant 'la souche d'un arbre' (toujours utilisé en cantonais)NOT EQUAL TOLATIN SMALL LETTER QCOMBINING CARON

    Texte : ≠q̌

  3. Section : B Exemples de caractères, de frappes de touche et de glyphes

    EXEMPLE : Trois caractères kanji U+65E5, U+672C, U+8A9E, prononcés 'nihongo'.

    Texte : 日本語

  4. Section : B Exemples de caractères, de frappes de touche et de glyphes

    EXEMPLE : La sortie affichée apparaît ainsi, de droite à gauche : deux ligatures LAM-ALIF et un 
glyphe ghayn initial attaché à glyphe ghayn final.

    Texte : لالاغغ

  5. Section: B Exemples de caractères, de frappes de touche et de glyphes

    EXEMPLE : 'Tango' en lettres tamoules.

    Texte : டாங்கோ

D La liste des critères de conformité (non normatif)

Voici la liste des critères de conformité de cette spécification, rangée dans l'ordre du document. Elle peut servir à vérifier la conformité des spécifications, des mises en œuvre et des contenus par rapport à cette spécification.

Pour cet usage, les points suivants devraient être gardés à l'esprit :

C001 [S] [I] [C]  Les spécifications, les mises en œuvre et les contenus NE DOIVENT PAS imposer ni dépendre d'une correspondance biunivoque (d'un-à-un) entre les caractères et les sons d'une langue.
C002 [S] [I] [C]  Les spécifications, les mises en œuvre et les contenus NE DOIVENT PAS imposer ni dépendre d'une correspondance biunivoque entre les caractères et les unités du texte affiché.
C003 [S] [I] [C]  Les protocoles, les formats de données et les interfaces de programmation API DOIVENT stocker, échanger ou traiter les données textuelles en ordre logique.
C075 [I]  Quel que soit le mode de sélection, logique ou visuel, utilisé par une implémentation, les caractères sélectionnés DOIVENT être gardés en ordre logique pour le stockage.
C004 [S]  Les spécifications de protocoles et d'interfaces de programmation (API) qui font intervenir une sélection d'étendues DEVRAIENT permettre les sélections logiques non attenantes, au moins assez pour permettre la mise en œuvre d'une sélection visuelle à l'écran couvrant ces protocoles et interfaces.
C005 [S] [I]  Les spécifications et les mises en œuvre NE DOIVENT PAS imposer ni compter sur le fait qu'une seule touche donnera un seul caractère ni qu'un seul caractère sera entré par une seule touche (même avec des modificateurs) ni que les claviers seront identiques dans le monde entier.
C006 [S] [I]  Les programmes de tri ou de recherche pour les utilisateurs DEVRAIENT s'exécuter en tenant compte des unités d'interclassement et des règles de classement appropriées pour la langue ou l'application concernées.
C007 [S] [I]  Lorsque la recherche ou le tri sont dynamiques, en particulier dans un environnement multilingue, la langue concernée DEVRAIT être celle de l'utilisateur courant, et elle pourra donc différer d'un utilisateur à l'autre.
C066 [S] [I]  Les programmes permettant à l'utilisateur de trier ou de rechercher un texte DEVRAIENT aussi lui permettre de sélectionner des règles pour les unités d'interclassement et pour le tri.
C008 [S] [I]  Les spécifications et les mises en œuvre d'algorithmes de tri et de recherche DEVRAIENT accepter du texte contenant n'importe quels caractères dans Unicode.
C009 [S] [I]  Les spécifications, les mises en œuvre et les contenus NE DOIVENT PAS imposer ni dépendre d'une correspondance biunivoque entre les caractères et les unités de stockage physique.
C010 [S]  Quand les spécifications emploient le terme caractère, elles DOIVENT en définir le sens.
C067 [S]  Les spécifications DEVRAIENT employer des termes spécifiques, le cas échéant, au lieu du terme général caractère.
C013 [S] [C]  Les objets de données textuelles définis par les spécifications de protocole ou de format DOIVENT être dans un seul codage de caractères.
C014 [S]  Toutes les spécifications qui font intervenir un traitement du texte DOIVENT le définir conformément au modèle de traitement de référence, à savoir :
  1. Les spécifications DOIVENT définir le texte en termes de caractères Unicode, et non pas en termes d'octets ni de glyphes.

  2. Pour leurs objets de données textuelles, les spécifications PEUVENT autoriser l'usage de tout codage de caractères transcodables dans une forme de codage Unicode.

  3. Les spécifications PEUVENT choisir d'interdire ou de déconseiller certains codages de caractères, et d'en rendre d'autres obligatoires. Indépendamment du codage de caractères effectif, le comportement défini DOIT être le même que si le traitement avait été le suivant :

    • Le codage de caractères de tout object de données textuelles que reçoit l'application mettant en œuvre la spécification DOIT être déterminé et l'objet de données DOIT être interprété comme une séquence de caractères Unicode ; ceci DOIT être équivalent au transcodage de l'objet de données en une certaine forme de codage Unicode, en ajustant, le cas échéant, toute étiquette de codage de caractères et en la recevant dans la forme de codage Unicode en question ;

    • Tout le traitement DOIT avoir lieu sur cette séquence de caractères Unicode ;

    • Si l'application produit du texte, la séquence de caractères Unicode DOIT être codée selon un codage de caractères choisi parmi ceux autorisés par l'application.

  4. Si une spécification est telle que plusieurs objets de données textuelles soient concernés (comme un document XML appelant des entités analysables externes), elle PEUT permettre que ces objets de données aient des codages de caractères différents. Quel que soit le cas, le modèle de traitement de référence DOIT s'appliquer à tous les objets de données textuelles.

C070 [S]  Les spécifications NE DEVRAIENT PAS exclure arbitrairement les points de code de l'étendue entière des points de code Unicode compris dans l'intervalle U+0000 à U+10FFFF inclus.
C077 [S]  Les spécifications NE DOIVENT PAS autoriser les point de code au-delà de U+10FFFF.
C079 [S]  Les spécifications NE DEVRAIENT PAS autoriser l'utilisation des points de code réservés à un usage interne par Unicode.
C078 [S]  Les spécifications NE DOIVENT PAS autoriser l'utilisation des points de code de substitution.
C015 [S]  Les spécifications DOIVENT soit définir un codage de caractères unique, soit fournir un mécanisme d'identification du codage de caractères, afin d'identifier le codage du texte avec certitude.
C016 [S]  En cas de création initiale d'un protocole, d'un format ou d'une interface de programmation (API), les spécifications DEVRAIENT imposer un codage de caractères unique.
C017 [S]  Lorsqu'un protocole, un format ou une interface de programmation (API) est fondé sur un autre protocole, format ou API déjà munis de règles de codage de caractères, les spécifications DEVRAIENT utiliser celles-ci plutôt que d'en changer.
C018 [S]  Lorsqu'un codage de caractères unique est imposé, ce codage DOIT être UTF-8, UTF-16 ou UTF-32.
C020 [S]  Les spécifications DEVRAIENT éviter l'emploi des termes jeux de caractères et charset pour désigner un codage de caractères, sauf ce dernier quand il désigne le paramètre MIME charset ou ses valeurs enregistrées auprès de l'IANA. L'expression codage de caractères ou, dans des cas particuliers, les expressions forme stockée de caractères ou mécanisme de sérialisation de caractères, sont RECOMMANDÉES.
C021 [S]  Si l'approche de codage unique n'est pas retenue, les spécifications DEVRAIENT imposer l'emploi des noms du registre des jeux de caractères de l'IANA et, en particulier, ceux identifiés comme noms préférés MIME, pour désigner les codages de caractères dans les protocoles, les formats de données et les interface de programmation (API).
C022 [S] [I] [C]  On NE DEVRAIT PAS se servir de codages de caractères absents du registre de l'IANA, sauf en cas d'accord mutuel.
C023 [S] [I] [C]  Si on se sert d'un codage de caractère non enregistré, on DOIT respecter la convention consistant à faire précéder le nom de x-.
C049 [I] [C]  Le choix du codage de caractères du contenu DEVRAIT intervenir de façon à maximiser les occasions de représentation directe des caractères (c.à.d., minimiser le besoin de représenter les caractères par du balisage, tels que les masquages de caractère), tout en se gardant d'utiliser des codages obscurs qui seront vraisemblablement incompris des destinataires.
C034 [C]  Si des fonctions d'identification des codages de caractères sont prévues, le contenu DOIT s'en servir ; lorsque ces fonctions incluent des valeurs par défaut (par exemple, dans le langage XML 1.0 [XML 1.0]), compter sur ces valeurs suffit pour satisfaire cette exigence d'identification.
C024 [I] [C]  Les contenus et logiciels étiquetant les données textuelles DOIVENT utiliser l'un des noms imposés par la spécification concernée (par exemple, la spécification XML pour la création d'un texte XML) et DEVRAIENT utiliser le nom MIME préféré du codage de caractères pour étiqueter les données qui sont dans ce codage de caractères.
C025 [I] [C]  On NE DOIT PAS utiliser le nom d'un charset enregistré auprès de l'IANA pour étiqueter des données textuelles dans un autre codage de caractères que celui identifié par l'enregistrement IANA ayant ce nom.
C026 [S]  Si l'option de codage unique n'est pas retenue, les spécifications DOIVENT désigner au moins l'une des formes de codage Unicode UTF-8 ou UTF-16 comme codage de caractères admissible et DEVRAIENT choisir au moins l'une des deux formes UTF-8 ou UTF-16 comme codage obligatoire (parmi les codages qui DOIVENT être gérées par les mises en œuvre de la spécification).
C027 [S]  Les spécifications qui imposent un codage par défaut DOIVENT définir soit UTF-8, soit UTF-16 comme codage par défaut, ou les deux si elles définissent des moyens convenables pour les distinguer.
C028 [S]  Les spécifications NE DOIVENT PAS proposer l'emploi de moyens heuristiques pour déterminer le codage des données.
C029 [I]  Le logiciel récepteur DOIT déterminer le codage des données à partir des informations disponibles conformément aux spécifications concernées.
C030 [I]  Si le logiciel récepteur reconnaît une étiquette charset enregistrée auprès de l'IANA, alors il DOIT interpréter les données reçues conformément au codage associé au nom dans le registre de l'IANA.
C031 [I]  Si aucun charset n'est fourni, le logiciel récepteur DOIT adhérer au(x) codage(s) de caractères implicite(s) défini(s) dans la spécification.
C035 [S]  Les spécifications DOIVENT définir des mécanismes de résolution de conflit (par exemple, des règles de priorité) au cas où existeraient des informations multiples ou conflictuelles concernant le codage de caractères.
C033 [I]  Les logiciels DOIVENT mettre en œuvre entièrement les mécanismes d'identification des codages de caractères et de résolution de conflit.
C073 [C]  Un contenu échangé publiquement NE DEVRAIT PAS utiliser de points de code de la zone à usage privé.
C076 [C]  Un contenu NE DOIT PAS utiliser de point de code pour toute autre destination que celle définie par son jeu de caractères codés (JCC).
C038 [S]  Les spécifications NE DOIVENT PAS imposer l'utilisation de caractères de la zone à usage privé à des affectations particulières.
C039 [S]  Les spécifications NE DOIVENT PAS imposer l'utilisation de mécanismes pour définir des accords sur les points de code à usage privé.
C040 [S] [I]  Les spécifications et les mises en œuvre NE DEVRAIENT PAS interdire l'utilisation par un accord mutuel des points de code à usage privé.
C041 [S]  Les spécifications PEUVENT définir un balisage afin de permettre la transmission de symboles absents d'Unicode ou afin d'identifier des variantes spécifiques de caractères Unicode.
C068 [S]  Les spécifications DEVRAIENT permettre d'inclure ou d'appeler des images et des graphiques, là où c'est nécessaire, afin que les mécanismes prévus pour des caractères ne soient pas utilisés (détournés) pour des images ou des graphiques.
C042 [S]  Les spécifications NE DEVRAIENT PAS inventer de nouveau mécanisme de masquage s'il en existe déjà un qui convient.
C043 [S]  Le nombre de façons différentes de masquer un caractère DEVRAIT être réduit (et idéalement être égal à un).
C044 [S]  La syntaxe de masquage DEVRAIT imposer soit un délimiteur final explicite, soit un nombre de caractères fixe pour chaque masquage de caractère. Une syntaxe de masquage dont la fin est déterminée par un caractère en-dehors de l'ensemble des caractères admissibles dans le masquage de caractère en question DEVRAIENT être évitée.
C045 [S]  Chaque fois que les spécifications définissent des masquages de caractère permettant la représentation des caractères par un nombre, ce nombre DOIT représenter le point de code Unicode du caractère et il DEVRAIT être en notation hexadécimale.
C046 [S]  Les caractères masqués DEVRAIENT être acceptables partout où leurs formes démasquées le sont ; cela n'empêche pas que les caractères syntaxiques, lorsqu'ils sont masqués, perdent leur signification dans la syntaxe. En particulier, si un caractère est acceptable dans les identificateurs ou les commentaires, alors sa forme masquée devrait aussi l'être.
C047 [I] [C]  On DEVRAIT seulement utiliser des masquages quand les caractères à exprimer ne sont pas directement représentables dans le format ou le codage de caractères du document, ou quand la représentation visuelle des caractères est incertaine.
C048 [I] [C]  Le contenu DEVRAIT utiliser la forme hexadécimale de masquage de caractère de préférence à la forme décimale lorsque les deux existent.
C050 [S]  Les spécifications DEVRAIENT exclure l'utilisation de caractères de compatibilité dans les éléments syntaxiques (balisage, délimiteurs, identificateurs, etc.) des formats qu'elles définissent.
C011 [S]  Les spécifications NE DEVRAIENT PAS définir une chaîne comme étant une chaîne d'octets.
C012 [S]  La plupart des spécifications DEVRAIT utiliser la définition d'une chaîne de caractères.
C051 [S] [I]  On RECOMMANDE la chaîne de caractères comme base pour l'indexation des chaînes.
C052 [S] [I]  On peut PEUT se servir d'une chaîne d'unités de stockage comme base pour l'indexation d'une chaîne si, comparée à l'utilisation d'une chaîne de caractères, l'efficacité des opérations internes s'en trouve améliorée de manière significative.
C071 [S] [I]  On PEUT utiliser des grappes de graphèmes comme base pour l'indexation d'une chaîne dans les applications pour lesquelles l'interaction avec l'utilisateur constitue la préoccupation majeure.
C074 [S]  Les spécifications qui définissent l'indexation en termes de grappes de graphèmes DOIVENT soit a) définir les grappes de graphèmes en fonction des grappes de graphèmes par défaut, comme défini dans l'annexe n° 29 du standard Unicode Les limites de texte [UTR #29], soit b) définir spécifiquement comment la personnalisation s'appliquera à l'opération d'indexation.
C072 [S] [I] L'utilisation d'une chaîne d'octets N'EST PAS RECOMMANDÉE pour l'indexation.
C053 [S]  Les spécifications qui ont besoin d'identifier des sous-chaînes ou un point au sein d'une chaîne DEVRAIENT offrir d'autres moyens qu'une indexation de chaîne pour réaliser cette opération.
C054 [I] [C]  Les utilisateurs des spécifications (les développeurs de logiciels, les créateurs de contenus, etc.) DEVRAIENT, chaque fois que possible, préférer d'autres moyens qu'une indexation de chaîne pour identifier des sous-chaînes ou un point au sein d'une chaîne.
C055 [S]  Les spécifications DEVRAIENT comprendre et traiter les caractères seuls comme des sous-chaînes, et considérer les indices comme des positions de limite entre les unités de comptage, quel que soit le choix des unités de comptage.
C056 [S]  Les spécifications des interfaces de programmation (API) NE DEVRAIENT PAS définir de caractères seuls ou d'unités de stockage seules comme argument ni comme type renvoyé.
C057 [S]  Lorsqu'on compte les positions entre les unités pour indexer une chaîne, la solution RECOMMANDÉE est de commencer par un indice de 0 pour la position au début de la chaîne, et l'indice final sera donc égal au nombre d'unités de comptage dans la chaîne.
C062 [S]  Dans la mesure où les spécifications ont besoin, généralement, à la fois d'une définition pour leurs caractères et de la sémantique qui leur est associée, elles DEVRAIENT comporter une référence au standard Unicode, qu'elles se réfèrent ou non à la norme ISO/CEI 10646.
C063 [S]  On DOIT se référer au standard Unicode génériquement si on souhaite que les caractères alloués après la publication de la spécification puissent être utilisés avec celle-ci. On PEUT inclure une référence spécifique au standard Unicode afin de s'assurer qu'une fonctionnalité attachée à une version particulière soit disponible et ne changera pas avec le temps.
C064 [S]  Toutes les références génériques au standard Unicode [Unicode] DOIVENT en citer la dernière version disponible à la date de publication de la spécification qui les contient.
C065 [S]  Toutes les références génériques à la norme ISO/CEI 10646 [ISO/CEI 10646] DOIVENT en citer la dernière version disponible à la date de publication de la spécification qui les contient.

E Les changements survenus depuis la recommandation proposée (non normatif)

F Remerciements (non normatif)

Tim Berners-Lee et James Clark ont apportés des précisions importantes dans le chapitre traitant des adresses URI. Asmus Freytag , Addison Phillips et Ian Jacobs pour la phase initiale, ont été d'une grande aide dans la création et le processus d'édition. Le groupe de travail et le groupe d'intérêt I18N du W3C, comme beaucoup d'autres, ont fait énormément de remarques et de suggestions utiles.