> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/fr/articles-approfondis/51-unicode-utf-8-and-multilingual-text-an-introduction.md).

# Unicode, UTF-8 et texte multilingue : une introduction

## Unicode et OpenType : caractères et glyphes

Les moteurs TeX modernes, c.-à-d. XeTeX et LuaTeX, ont évolué à partir du moteur TeX original de Knuth en grande partie en raison de la nécessité de suivre le rythme des évolutions du paysage technologique, en particulier Unicode (pour le texte) et OpenType (pour les polices). Aujourd'hui, grâce à l'utilisation de paquets tels que [fontspec](https://ctan.org/pkg/fontspec?lang=en) et [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), les utilisateurs de LaTeX peuvent accéder à des capacités de composition extrêmement sophistiquées offertes par les polices OpenType — y compris la composition multilingue avancée et la composition mathématique fondée sur OpenType ([pionnière de Microsoft](https://blogs.msdn.microsoft.com/murrays)).

Cependant, pour tirer le meilleur parti de l'utilisation des polices OpenType avec XeTeX/LuaTeX, il peut être utile de se familiariser avec un certain nombre de sujets/concepts de base — en particulier pour résoudre des problèmes ou pour préparer le terrain à des travaux plus avancés/complexes. Par exemple, vous pourriez lire que les moteurs XeTeX et LuaTeX utilisent une « entrée UTF-8 » ou qu'ils sont « sensibles à Unicode », et des lectures complémentaires sur les polices OpenType pourraient aborder ou mentionner des sujets tels que « l'encodage Unicode », les « fonctionnalités » OpenType, les « glyphes », les « ID de glyphes », les « noms de glyphes », et ainsi de suite. Notre objectif est de fournir une introduction à ces termes/sujets et de reconstituer un cadre de base montrant comment ils sont liés et, espérons-le, d'apporter un soutien pour des travaux ultérieurs ou la résolution de problèmes.

Les sujets que nous visons à couvrir se répartissent assez nettement en deux grands domaines : *Unicode* qui, en pratique, relève du monde du texte/des caractères et de l'encodage du texte, et *OpenType* dont le monde est celui des polices et des glyphes ; mais, bien sûr, ces deux mondes sont interconnectés et il existe des recoupements, même dans ce premier article.

### Quels sujets allons-nous aborder ?

Le principal objectif de cet article est d'aborder quelques sujets liés à Unicode : en commençant par une discussion sur ce que signifie un « caractère », puis en introduisant les écritures/langues, l'encodage Unicode et UTF-8 — ainsi qu'un exemple de travail avec des fichiers texte multilingues. Un article de suivi s'appuiera sur cette partie pour couvrir des sujets de base liés à la technologie des polices OpenType. Il est clair que, dans les limites d'un billet de blog, il n'est pas possible de faire une « plongée en profondeur » dans tous les domaines que nous espérons aborder : notre objectif déclaré est de fournir le cadre général montrant comment quelques concepts clés sont liés et fonctionnent ensemble. Nous commencerons par le concept le plus fondamental : celui du *caractère*.

## Le caractère : un élément de base

Une idée/un concept fondamental au cœur de nos discussions (et de celles d'Unicode) est la signification d'un « caractère » : c'est l'un de ces mots dont le sens est souvent « supposé » par son usage dans le travail et les conversations de tous les jours. Cependant, du point de vue d'Unicode, de la composition et des technologies de polices, nous devons être un peu plus précis et définir ce que l'on entend par « un caractère ». Par exemple, il pourrait nous sembler tout à fait naturel de penser à **a** et *a* comme à des « caractères » différents : « a gras » et « a italique ». Mais non : ce ne sont que des représentations visuelles différentes du même caractère fondamental, auquel Unicode donne le nom officiel [LATIN SMALL LETTER A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [définit un caractère](http://www.unicode.org/glossary/#character) comme :

> « Le plus petit composant du langage écrit qui possède une valeur sémantique ; il renvoie au sens abstrait et/ou à la forme, plutôt qu'à une forme spécifique... »

qui distingue clairement la *l'apparence visuelle* forme spécifique *et sa*.

signification *écriture*On peut considérer un caractère comme l'unité fondamentale, ou élément constitutif, d'une langue ou, plus correctement, d'une *et sa* — un sujet que nous abordons ci-dessous. L'aspect réel d'un caractère lorsqu'il est affiché dans une police particulière n'entre pas en ligne de compte dans la définition Unicode d'un caractère : seule la *rôle et la finalité* de chaque caractère en tant que l'un des blocs de construction à partir desquels les écritures/langues sont finalement construites.

### Écriture et langue

Il vaut la peine de mentionner brièvement deux concepts importants : *les écritures* et *langues*. [définition d'une écriture](https://www.unicode.org/standard/supported.html):

> « La norme Unicode encode les écritures plutôt que les langues. Lorsque des systèmes d'écriture pour plus d'une langue partagent des ensembles de symboles graphiques dont les dérivations sont historiquement apparentées, l'union de tous ces symboles graphiques est traitée comme un seul ensemble de caractères pour l'encodage et est identifiée comme une seule écriture. »

En prenant un [exemple de Wikipédia](https://en.wikipedia.org/wiki/Script_\(Unicode\)), l'écriture latine est composée d'un [ensemble de caractères](http://unicode.org/charts/) qui sont utilisés dans plusieurs langues : anglais, français, allemand, italien, et ainsi de suite. Bien sûr, tous les caractères définis dans l'écriture latine ne sont pas utilisés par toutes les langues fondées sur l'écriture latine — par exemple, l'alphabet anglais ne contient pas les caractères accentués présents dans d'autres langues européennes telles que le français ou l'allemand.

### Polices OpenType : écritures et langues

À ce stade, nous passerons d'Unicode aux polices OpenType, car les concepts d'écriture et de langue jouent également un rôle extrêmement important dans la technologie des polices OpenType.

Un ensemble de langues qui utilisent la même [écriture](http://www.unicode.org/glossary/#script) peut chacune avoir des traditions typographiques différentes lorsqu'il s'agit d'afficher (composer) un texte écrit dans une langue particulière. Un bon exemple se trouve dans la langue turque et le [comportement du i sans point](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (voir les notes de cette page sur les ligatures). Les « règles » typographiques relatives aux écritures/langues sont intégrées aux fonctionnalités des polices OpenType grâce à l'utilisation de ce qu'on appelle des *balises* étiquettes d'écriture et de langue [package fontspec](https://ctan.org/pkg/fontspec?lang=en).

#### Examen à l'intérieur d'une police OpenType : écritures/langues

Pour plus de clarté, voici une capture d'écran montrant la police OpenType libre [Scheherazade OpenType](http://software.sil.org/scheherazade/download/) ouverte dans le logiciel (également libre) [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) d'édition de polices. Sur cette image, vous pouvez voir les écritures, les langues et les fonctionnalités typographiques intégrées à Scheherazade — avec VOLT, vous pouvez ajouter des fonctionnalités et des capacités supplémentaires à Scheherazade, mais cela dépasse largement le cadre de cet article !

![La police Scheherazade OpenType (au format TrueType) ouverte dans Microsoft VOLT](/files/00e73695f2cbd41f2bb60edae9718a41270e3a9d)

À partir de cette capture d'écran, vous pouvez voir que Scheherazade prend en charge les écritures arabe et latine et offre un soutien spécialisé supplémentaire pour plusieurs langues qui utilisent l'écriture arabe — en utilisant les soi-disant fonctionnalités OpenType, qui sont सूची?

Le lecteur intéressé peut parcourir le registre des balises OpenType pour voir les [balises d'écriture](https://www.microsoft.com/typography/otspec/scripttags.htm) et [balises de langue](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) actuellement utilisées dans la spécification OpenType.

### Retour aux caractères : différents rôles des caractères

L'ensemble des caractères qui constituent les éléments fondamentaux d'une écriture (ou d'une langue) n'assument pas tous le même rôle. Par exemple, dans la plupart des langues, il existe des caractères pour *la ponctuation*, des caractères pour les nombres *chiffres* ainsi que les caractères que nous considérons comme des *lettres* de l'alphabet qui, pour certaines écritures, existent aussi sous des formes majuscules et minuscules. Le concept de caractère est assez large et la norme Unicode comprend des caractères spécialisés qui ne sont *pas conçus pour être affichés* mais dont le rôle est « de contrôler l'interprétation ou l'affichage du texte ». Par exemple, lors de la composition de texte arabe, vous pouvez vouloir forcer ou empêcher le comportement de liaison de certains caractères ; la norme Unicode fournit des caractères de contrôle spéciaux à cet effet : les soi-disant [JOIGNEUR À LARGEUR NULLE](https://en.wikipedia.org/wiki/Zero-width_joiner) et le [NON-JOIGNEUR À LARGEUR NULLE](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Ces caractères ne sont pas destinés à être affichés et sont « absorbés » par le logiciel lors du traitement du texte afin de produire leurs effets visuels souhaités.

Tous les caractères spécifiés dans la norme Unicode se voient attribuer un ensemble de propriétés qui, en pratique, décrit le rôle et la fonction de chaque caractère dans l'encodage Unicode — les noms de caractères, tels que LATIN SMALL LETTER A, ne sont qu'un élément de la liste des propriétés d'un caractère. Ces propriétés sont entièrement décrites dans la [Base de données des caractères Unicode (UCD)](http://www.unicode.org/reports/tr44/) et sont largement utilisées dans les opérations de traitement de texte informatisées telles que la recherche, le tri, la vérification orthographique, etc. Des fichiers de données répertoriant les propriétés des caractères Unicode sont également [disponibles en téléchargement](http://www.unicode.org/Public/UCD/latest/).

Parmi les propriétés attribuées à chaque caractère, la plus importante pour notre discussion est un *identifiant numérique* attribué par son encodage Unicode, sujet auquel nous allons maintenant nous intéresser.

### Caractères : nombres et encodages

C'est évident, mais les ordinateurs et autres appareils numériques ont pour activité de stocker et de traiter des données numériques : alors comment cela se rapporte-t-il au texte ? Lorsque vous tapez du texte au clavier d'un ordinateur, ou en touchant l'écran d'un appareil mobile, vos frappes sont transformées en nombres qui représentent la chaîne de caractères que vous êtes en train de saisir.

À un moment donné, vous souhaiterez peut-être transférer ce texte (une suite de nombres) par e-mail, par message texte ou via une communication en ligne telle qu'un Tweet ou une publication sur une forme de réseau social. Il est clair que l'appareil sur lequel vous avez rédigé le texte et le ou les appareils utilisés par son ou ses destinataires doivent, d'une manière ou d'une autre, s'accorder sur les nombres qui représentent quels caractères. Sinon, votre texte pourrait ne pas s'afficher correctement sur l'appareil du destinataire.

Pour que les communications mondiales d'aujourd'hui fonctionnent, les appareils d'envoi et de réception ont besoin d'une « convention mutuellement acceptée » selon laquelle un ensemble particulier de nombres représente un ensemble spécifique de caractères. Cette convention s'appelle un *codage*: un ensemble de nombres utilisé pour représenter un ensemble particulier de caractères, et l'encodage Unicode est désormais la *de facto* norme mondiale.

## Unicode : bits et octets pour stocker le texte

Unicode est une norme énorme qui couvre bien, bien plus que le simple encodage du texte, mais ici nous nous concentrons uniquement sur l'encodage qu'elle fournit.

#### Bits, octets et combien de caractères ?

Nous avons mentionné que les appareils stockent et représentent le texte sous forme de nombres — plus précisément, les caractères seront stockés sous forme d'entiers : des nombres entiers. Pour comprendre les implications de cela pour l'encodage Unicode, nous devons faire une *très* brève, *très* simple revue de la manière dont les ordinateurs stockent les entiers (nous n'avons pas l'intention de nous aventurer dans l'informatique).

Pour raccourcir une très longue histoire, les appareils de bureau ou portables actuels stockent les entiers dans des « blocs » discrets qui peuvent mesurer 1, 2, 4 ou 8 octets. Chacune de ces unités de stockage peut stocker des entiers jusqu'à une valeur positive maximale basée sur le nombre total de bits contenus dans chaque unité de stockage :

* 1 octet (8 bits) : l'entier positif maximal est 255 ;
* 2 octets (16 bits) : l'entier positif maximal est 65535 ;
* 4 octets (32 bits) : l'entier positif maximal est 4 294 967 295 ;
* 8 octets (64 bits) : l'entier positif maximal est 18 446 744 073 709 551 615.

En pratique, la norme Unicode utilise des nombres dans l'intervalle 0 à 1 114 111 pour encoder tous les caractères du monde, de sorte qu'elle n'a besoin que de 21 bits pour encoder l'ensemble de la plage. On peut le voir en notant que des unités de stockage contenant n bits peuvent représenter tout entier positif de 0 jusqu'à une valeur maximale de $$2^n -1$$; par conséquent :

* la valeur maximale pouvant être stockée sur 20 bits est $$2^{20} -1 = 1,048,575$$ (trop petite) ;
* la valeur maximale pouvant être stockée sur 21 bits est $$2^{21} -1 = 2,097,151$$ (suffisamment grande).

Nous avons noté que les ordinateurs stockent les données (nombres) dans des unités de 1, 2, 4 (ou 8) octets, alors quelle doit être la taille de l'unité de stockage si nous devons stocker des valeurs allant jusqu'à la valeur Unicode maximale de 1 114 111 ? De toute évidence, une unité de stockage de la taille d'un octet peut contenir une valeur maximale de 255 et 2 octets peuvent stocker 65535 : aucun de ces deux formats n'est suffisant pour stocker la plage complète de caractères encodés par Unicode. L'option suivante disponible est celle des unités de stockage de 4 octets, qui peuvent stocker des entiers jusqu'à un maximum de 4 294 967 295, soit bien plus que ce dont nous aurions réellement besoin. Donc, si nous choisissions 4 octets comme unité de stockage, nous aurions certainement plus qu'assez de place pour stocker toutes les valeurs Unicode, chaque caractère étant stocké comme un entier nécessitant 4 octets (32 bits). Cependant, utiliser 4 octets pour tout stocker est très gaspilleur d'espace, car même les plus grandes valeurs Unicode n'ont besoin que d'un maximum de 21 bits — ce qui, si elles étaient stockées sur 32 bits, signifierait que 11 de ces 32 bits ne seraient jamais utilisés.

**Remarque**: Bien que la plage Unicode s'étende de 0 à 1 114 111, toutes les valeurs de cette plage ne sont pas réellement utilisées : pour des raisons techniques, certaines valeurs sont considérées comme invalides pour une utilisation réelle en tant que caractères Unicode.

### Alors, qu'est-ce que UTF-8 ?

Si vous lisez des informations sur XeTeX ou LuaTeX, vous rencontrerez presque certainement des explications indiquant que ces moteurs TeX lisent le texte et les fichiers d'entrée LaTeX au « format UTF-8 ». Alors qu'est-ce que le « format UTF-8 » et comment se rapporte-t-il à Unicode ? Dans le vocabulaire Unicode, chacune de ses 1 114 112 valeurs (allant de 0 à 1 114 111) utilisées pour encoder les caractères du monde est appelée un [point de code](http://www.unicode.org/glossary/#code_point).

Nous avons vu que, *en théorie*, nous devrions stocker tout notre texte encodé en Unicode en utilisant 4 octets par caractère afin de représenter toute la plage des points de code Unicode. Cependant, en pratique, des personnes plutôt ingénieuses ont inventé une manière simple de représenter un seul nombre Unicode (point de code) sous la forme d'une *séquence* suite de nombres plus petits, chacun de ces nombres plus petits étant stocké dans un seul octet : un processus qui *transforme* un entier unique (plus grand) en une séquence de plus petits (de la taille d'un octet). Grâce à cette transformation, les caractères de notre fichier texte ne sont plus chacun représentés par une seule valeur numérique : chaque caractère devient une *séquence multi-octets*— de 1 à 4 octets (consécutifs) dans le fichier texte peuvent représenter un seul caractère Unicode individuel (c.-à-d. la valeur de son point de code).

UTF signifie *Format de transformation Unicode* et le mot clé ici est *Transformation*. En substance, vous pouvez considérer UTF-8 comme une « recette » ou un algorithme permettant de convertir (transformer) une valeur unique de point de code Unicode en une séquence de 1 à 4 éléments de taille octet. À mesure que la valeur du point de code Unicode augmente, le nombre d'octets individuels nécessaires pour le représenter au format UTF-8 augmente lui aussi.

Il existe des raisons techniques et historiques à la création d'UTF-8, et l'histoire derrière l'invention d'UTF-8 est [consignée dans un courriel fascinant de 2003](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), qui, vers le début du courriel, contient la ligne :

> « Ce n'est pas vrai. UTF-8 a été conçu, sous mes yeux, sur une serviette dans un diner du New Jersey une nuit de septembre 1992, ou à peu près. »

#### Exemple : la lettre arabe ل

Prenons l'exemple de la lettre arabe ل (nom Unicode ARABIC LETTER LAM), à laquelle est attribuée la valeur de point de code Unicode 1604 (décimal) ou 0644 (hexadécimal) : sa représentation en UTF-8 est la *séquence de deux octets* D9 84 (hex) ou, en décimal, 217 132. Lorsqu'on utilise UTF-8 comme format de stockage du texte, plutôt qu'un fichier texte contenant le nombre unique 1604 pour représenter ل, celui-ci est converti en deux valeurs de la taille d'un octet : 217 et 132 — le caractère ل est stocké comme une *séquence de deux octets*. Les lecteurs qui souhaitent explorer l'algorithme UTF-8 plus en détail peuvent trouver une explication approfondie, ainsi que du code C, sur mon [blog personnel de cet auteur](http://www.readytext.co.uk/?p=1284).

Lorsqu'un logiciel (par ex. XeTeX ou LuaTeX) lit du texte au format UTF-8, ce logiciel doit déterminer la valeur Unicode de chaque caractère présent dans ce fichier, il utilise donc un algorithme pour *inverser* le processus de transformation UTF-8. Grâce à cet « algorithme de rétrotransformation », les deux octets (217 et 132) sont recombinés pour générer l'entier 1604, qui peut alors être reconnu comme la valeur du point de code Unicode pour la lettre arabe ل.

Ainsi, en conclusion, UTF-8 n'est vraiment qu'un format de données intermédiaire utilisé pour le stockage et la transmission de texte encodé en Unicode.

**Remarque**: Certains systèmes choisissent d'utiliser/de stocker le texte avec 32 bits par caractère, cela s'appelle [UTF-32](https://en.wikipedia.org/wiki/UTF-32)— il existe aussi [UTF-16](https://en.wikipedia.org/wiki/UTF-16) mais UTF-8 est le moyen le plus courant de stocker du texte encodé en Unicode.

## Fichiers TeX multilingues : XeTeX et LuaTeX

XeTeX et LuaTeX sont tous deux capables d'une composition multilingue très sophistiquée, bien que leurs mécanismes pour y parvenir soient assez différents et reflètent la philosophie de conception/développement de chaque moteur. Nous n'explorerons pas cela en profondeur mais noterons simplement que le moteur XeTeX contient des composants logiciels (intégrés à son exécutable) qui ne sont pas présents dans LuaTeX — notamment des logiciels pour un processus appelé *mise en forme OpenType* (par ex. via une bibliothèque appelée [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX, en revanche, adopte une approche différente : plutôt que d'intégrer directement des facilités dans le moteur TeX lui-même, LuaTeX fournit une collection extrêmement riche de commandes (primitives TeX) et une API très puissante basée sur Lua [basée sur Lua](/latex/fr/articles-approfondis/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) par laquelle les développeurs peuvent construire des solutions tout aussi avancées pour la composition multilingue. Bien que la philosophie de LuaTeX puisse impliquer un travail supplémentaire pour les développeurs de paquets LaTeX, elle offre beaucoup plus de flexibilité, car les solutions ne sont pas « codées en dur » dans le moteur LuaTeX lui-même, mais sont construites à partir de code TeX et Lua — ou de greffons écrits en C/C++.

**Aparté**: Les lecteurs souhaitant explorer plus avant le monde fascinant, mais complexe, de la mise en forme OpenType pourraient être intéressés de lire à propos de l'excellente bibliothèque open source appelée [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)— utilisée par de nombreuses applications, notamment Firefox, Chrome et LibreOffice et, bien sûr, par XeTeX. L'auteur de cet article a utilisé HarfBuzz pour créer [des greffons LuaTeX pour faire de la composition arabe](http://www.readytext.co.uk/?p=3186).

C'est désormais courant (par ex. sur les réseaux sociaux) de transmettre du texte contenant des caractères issus de plusieurs langues, et un fichier texte UTF-8 stockant du texte multilingue peut facilement contenir des caractères dont la représentation en UTF-8 fait 1, 2, 3 ou 4 octets de long. Ainsi, en pratique, un fichier texte UTF-8 n'est qu'un flux d'octets simples, mais chaque caractère réel de ce fichier peut mesurer de 1 à 4 octets : les caractères individuels sont devenus des *séquences multi-octets*.

Pour explorer davantage certains aspects clés du travail avec du texte multilingue (composition), nous utiliserons un exemple contenant l'écriture arabe, car l'arabe nous offre la possibilité d'aborder plusieurs concepts.

#### Aparté : l'écriture arabe

Le [L'écriture arabe](https://en.wikipedia.org/wiki/Arabic_script) s'écrit dans un style cursif qui se lit et s'écrit de droite à gauche. Chaque lettre arabe peut, potentiellement, adopter l'une de 4 formes différentes selon :

* qu'elle soit affichée comme un caractère unique, autonome (isolé), non lié à quoi que ce soit d'autre ;
* qu'elle apparaisse à l'intérieur d'un mot — au début, au milieu ou à la fin d'un mot : on parle alors des formes *initiales*, *médianes* et *final* respectivement.

Chaque caractère de l'écriture arabe possède son propre ensemble de règles de liaison et peut, ou non, changer de forme/aspect lorsqu'il a un autre caractère à sa gauche, à sa droite ou à sa gauche et à sa droite. Les lecteurs souhaitant approfondir peuvent trouver une [liste complète sur Wikipédia](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Exemple : texte arabe et anglais en UTF-8

Supposons que nous créions un fichier texte UTF-8 contenant une seule ligne de texte anglais et arabe : Ceci est العَرَبِيَّة texte !

Cette ligne de texte contient 3 caractères espace, 11 caractères anglais (écriture latine) et 12 caractères arabes (même si cela peut ne pas être immédiatement évident/apparent). Une fois enregistrée comme fichier texte UTF-8, elle occupe 38 octets de stockage, ce qui résulte de ce qui suit :

* **Écriture latine**: espaces plus texte anglais : 14 ✕ caractères d'un octet = 14 octets ;
* **L'écriture arabe**: 12 caractères arabes ✕ 2 octets par caractère = 24 octets.

Au total, 14 + 24 = 38 octets.

#### Allons plus loin

Si nous enregistrons notre texte d'exemple dans un fichier UTF-8 appelé `arabic.txt` et l'ouvrons dans un éditeur hexadécimal, nous pouvons l'examiner pour voir les octets réels qu'il contient. À partir de l'étude de la capture d'écran annotée suivante, vous pouvez voir que le texte arabe est stocké à raison de 2 octets par caractère :

![Un fichier texte UTF-8 contenant du texte anglais et arabe ouvert dans un éditeur hexadécimal.](/files/f10c28fb475b9276259a1bfa8e5153b10c9d85e3)

Un fichier texte UTF-8 contenant du texte anglais et arabe ouvert dans un éditeur hexadécimal. Vous pouvez clairement voir que les caractères de l'écriture latine nécessitent un seul octet, tandis que les caractères de l'écriture arabe sont stockés à raison de deux octets par caractère.

Vous pouvez tirer deux observations de cette capture d'écran :

* le texte arabe est stocké dans une séquence de gauche à droite et les caractères sont les versions brutes non mises en forme (isolées) des lettres et voyelles arabes ;
* il n'y a aucune information supplémentaire après le texte latin « This is » pour indiquer à tout logiciel lisant ce fichier que le caractère suivant relève de l'écriture arabe.

Si vous composez un document multilingue (par ex. contenant de l'anglais et de l'arabe), alors lors de la lecture/du traitement du fichier texte d'entrée (sous forme d'un flux d'octets), XeTeX ou LuaTeX doit être en mesure de détecter le début et la fin de chaque caractère et de lire le nombre correct d'octets nécessaires pour inverser la transformation UTF-8 et générer le point de code Unicode correspondant. C'est l'algorithme UTF-8 lui-même qui permet au logiciel de faire cela : il permet de détecter le premier octet de chaque caractère individuel et combien d'octets doivent être lus afin de calculer le point de code Unicode correspondant. UTF-8 est simple à utiliser, mais vraiment ingénieux.

#### Ordre logique, ordre d'affichage et mise en forme OpenType

Si vous regardez attentivement l'arabe ci-dessus (العَرَبِيَّة), il peut être difficile de voir que notre fichier texte contient bel et bien 12 caractères arabes individuels — surtout si vous n'êtes pas familier avec l'écriture arabe ! Cependant, si vous comptez soigneusement les caractères arabes affichés sur le côté droit de la capture d'écran ci-dessus, vous pouvez voir qu'il y en a 12 au total.

Pour les langues à écriture complexe, telles que l'arabe, ce que notre fichier texte *stocke* et ce que vous *voyez à l'écran* sont visiblement *très* vraiment différents ! Ce que vous voyez lorsque vous consultez ce texte dans, par exemple, un navigateur, est (selon la police utilisée) :

![Image de texte arabe composé](/files/2f1a2d6dcb745b6bad50ad8791bbcae7d4fb56e5)

Mais, comme le montre la capture d'écran ci-dessus, ce que contient réellement le fichier texte UTF-8 est ceci :

![Image de texte arabe non composé (caractères isolés)](/files/186333e3ae0da33404b7d0507af4f11e0e19e110)

Même si vous n'êtes pas familier avec la nature cursive de l'écriture arabe, vous pouvez clairement voir que « quelque chose » s'est produit au cours du transfert des caractères arabes contenus dans un fichier texte vers la composition et/ou l'affichage à l'écran (sous forme de glyphes). Si vous avez l'habitude d'utiliser TeX/LaTeX avec des langues à écriture simple, par exemple les langues fondées sur le latin, cela peut être très déroutant !

Plusieurs concepts importants sont en jeu ici, car les fichiers texte Unicode ont pour fonction de stocker… eh bien, du texte (Unicode), tandis que les systèmes de composition et d'affichage ont pour fonction d'utiliser des polices et des glyphes (OpenType) :

* le fichier texte a enregistré les caractères arabes dans un ordre de gauche à droite, mais l'arabe se lit/s'affiche de droite à gauche : les fichiers texte stockent le texte dans ce qu'on appelle *l'ordre logique*;
* le fichier texte contient des caractères individuels qui ont un aspect très différent de l'affichage réel présenté à l'écran : le fichier texte contient les caractères arabes dans leur forme isolée, non liée.

#### Que se passe-t-il ?

Dans un fichier texte, l'arabe est stocké comme une séquence de gauche à droite de caractères sous forme isolée : si vous y réfléchissez, le fichier texte stocke le texte arabe dans l'ordre/la séquence *dans lequel il a été saisi* (la *l'ordre logique*). Ce n'est que lorsque ce texte est traité pour l'affichage, ou composé, qu'il est affiché dans son ordre de lecture correct, souvent appelé *ordre visuel* ou *ordre d'affichage*; de plus, les formes isolées des caractères arabes sont *mises en forme* dans leurs versions d'affichage typographiquement correctes. Une façon de considérer cela est qu'un simple fichier texte doit stocker le texte (caractères Unicode) sous la forme la plus élémentaire possible : des caractères textuels bruts, non mis en forme, individuels — le rôle du logiciel système est de restituer ces caractères pour l'affichage en fonction du système d'exploitation, des polices et du logiciel de composition/rendu disponibles sur l'appareil d'affichage.

Lorsque le texte arabe de ce fichier est composé/affiché, il subit un processus appelé *mise en forme*. Les caractères arabes individuels sont convertis en glyphes mis en forme qui représentent correctement la variante de chaque caractère requise selon les règles de liaison de l'écriture et du système d'écriture arabes. En outre, un logiciel de composition de haute qualité (utilisant de bonnes polices OpenType) ajoutera d'autres traitements en appliquant une sophistication typographique supplémentaire grâce à un processus appelé *mise en forme OpenType*—un processus qui englobe un large éventail d'opérations typographiques pouvant inclure :

* le remplacement de plusieurs glyphes individuels par un seul glyphe de ligature complexe (très courant en arabe), ou
* des opérations de positionnement qui, par exemple, ajustent la position des voyelles arabes en fonction du glyphe au-dessus ou au-dessous duquel elles se trouvent.

![Image montrant la transformation subie par le texte arabe lors de sa composition](/files/d62d00bfc9cc36a9d0c63c7d3cd6665d20d01f65)

La différence entre l'ordre logique et l'ordre visuel (d'affichage). Dans ce graphique, vous pouvez voir que les caractères arabes stockés dans un fichier texte subissent un réordonnancement et un façonnage lorsqu'ils sont affichés ou composés.

Les concepteurs et créateurs de polices OpenType avancées investissent énormément de temps et d'expertise pour offrir les capacités typographiques sophistiquées intégrées à leurs polices.

Pour désactiver le façonnage appliqué au texte arabe, nous pouvons utiliser l'excellent, gratuit, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) éditeur de texte Unicode (Windows uniquement) qui vous permet de désactiver le façonnage pour voir les caractères bruts, individuels et non liés (non façonnés) réellement présents dans le fichier texte—voir la moitié inférieure de cette capture d'écran combinée :

![Image montrant la capacité de l'éditeur de texte BabelPad à désactiver le façonnage OpenType](/files/37ebcb0517e57ff093ed7a89d95e74311253ccd1)

Utilisation de l'éditeur de texte Unicode BabelPad pour activer le façonnage OpenType (figure du haut) ou le désactiver (figure du bas). Désactiver le façonnage OpenType facilite grandement l'édition du texte arabe.

Les concepts d'ordre logique et d'ordre d'affichage, associés aux processus de façonnage, peuvent être assez déroutants lorsqu'on les rencontre pour la première fois lors de l'édition ou de la composition de fichiers texte multilingues contenant des écritures complexes telles que l'arabe : j'espère que ce qui précède a aidé à éviter une certaine confusion initiale.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/fr/articles-approfondis/51-unicode-utf-8-and-multilingual-text-an-introduction.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.