UTF-8 : le standard sur Internet

« UTF-8 » est l’abré­via­tion de « 8-Bit UCS Trans­for­ma­tion Format » et désigne le codage de ca­rac­tères le plus largement répandu sur Internet. Ce standard in­ter­na­tio­nal Unicode comprend l’in­té­gra­lité des ca­rac­tères et éléments textuels de toutes les langues du monde (ou presque) pour le trai­te­ment in­for­ma­tique. UTF-8 joue un rôle de premier plan dans le jeu de ca­rac­tères Unicode.

Dé­ve­lop­pe­ment du codage UTF-8

UTF-8 est un codage de ca­rac­tères. Il attribue à chaque caractère Unicode existant une séquence de bits précise que l’on peut également lire comme un nombre binaire. Cela signifie qu’UTF-8 attribue un nombre binaire fixe à l’ensemble des lettres, chiffres et symboles d’une quantité toujours plus im­por­tante de langues. Certaines or­ga­ni­sa­tions in­ter­na­tio­nales, qui accordent une grande im­por­tance aux normes Internet et sou­hai­tent les établir, tra­vail­lent à faire d’UTF-8 un acteur in­con­tour­nable du codage. W3C mais aussi l’Internet En­gi­nee­ring Task Force (IETF) y tra­vail­lent notamment d’arrache-pied, non sans résultat puisque, depuis 2009, la plupart des sites Internet du monde utilisent le codage UTF-8. D’après une expertise de W3Techs, en avril 2025, 98,6 % des sites Internet existants uti­li­saient ce codage de ca­rac­tères.

Problèmes avant l’in­tro­duc­tion d’UTF-8

Dif­fé­rentes régions du monde disposant de langues et de systèmes d’écriture ap­pa­ren­tés ont développé leurs propres standards de codage afin de répondre à des exigences dif­fé­rentes. L’espace an­glo­phone, par exemple, se sa­tis­fai­sait du codage ASCII dont la structure permet d’attribuer 128 ca­rac­tères à une chaîne de ca­rac­tères lisible par or­di­na­teur.

Les polices asia­tiques ou l’alphabet cy­ril­lique disposent toutefois de ca­rac­tères plus sin­gu­liers et les voyelles in­flé­chies al­le­mandes (par exemple ä) sont également absentes de l’ASCII. Par ailleurs, les chaînes de ca­rac­tères at­tri­buées par dif­fé­rents codages pouvaient se che­vau­cher. On pouvait par exemple se retrouver dans des si­tua­tions où un document publié en russe n’était pas affiché avec des lettres cy­ril­liques sur un or­di­na­teur américain, mais avec les lettres latines at­tri­buées con­for­mé­ment au système de cet or­di­na­teur. La ca­co­gra­phie qui en résultait com­pli­quait sen­si­ble­ment la com­mu­ni­ca­tion in­ter­na­tio­nale.

Naissance d’UTF-8

Afin d’apporter une solution à ce problème, Joseph D. Becker a développé pour Xerox entre 1988 et 1991 le jeu universel de ca­rac­tères Unicode. À partir de 1992, le con­sor­tium in­for­ma­tique X/Open a également cherché à établir un système qui prendrait la relève de l’ASCII et élar­gi­rait le ré­per­toire de ca­rac­tères. Ce nouveau codage devait malgré tout rester com­pa­tible avec l’ASCII.

Une exigence à laquelle le premier codage intitulé UCS-2, qui se con­ten­tait de convertir les numéros de ca­rac­tères en valeurs de 16 bits, n’a pas su répondre. UTF-1 a également échoué dans cette tâche puisque les at­tri­bu­tions Unicode coïn­ci­daient par­tiel­le­ment avec les chaînes de ca­rac­tères at­tri­buées par l’ASCII. Par con­sé­quent, un serveur paramétré en ASCII affichait en partie des ca­rac­tères erronés. Ce problème s’est révélé con­si­dé­rable, car la majorité des or­di­na­teurs an­glo­phones utilisait ce codage à cette époque.

L’étape suivante fut franchie par le File System Safe UCS Trans­for­ma­tion Format (FSS-UTF) de Dave Prosser qui est parvenu à vaincre le che­vau­che­ment avec les ca­rac­tères ASCII.

En août de la même année, le projet a fait le tour des spé­cia­listes. Les co­fon­da­teurs d’Unix Ken Thompson et Rob Pike tra­vail­laient à l’époque sur le système d’ex­ploi­ta­tion Plan 9 pour les la­bo­ra­toires Bell Labs, qui ont reçu de nombreux prix Nobel. Ils ont repris l’idée de Dave Prosser, développé un codage auto-syn­chro­ni­sant (chaque caractère indique ainsi combien de bits lui sont né­ces­saires) et défini des règles pour l’at­tri­bu­tion des lettres qui pouvaient être re­pré­sen­tées de façon dif­fé­rente dans le code (par exemple : ä en tant que caractère propre ou sous la forme de « a+¨ »). Ils ont appliqué ce codage avec succès à leur système d’ex­ploi­ta­tion et l’ont présenté aux res­pon­sables. Les grandes lignes du FSS-UTF, aujourd’hui connu sous le nom d’« UTF-8 », étaient alors posées.

UTF-8 dans le jeu de ca­rac­tères Unicode : un standard pour toutes les langues

Le codage UTF-8 est un format de trans­for­ma­tion au sein du standard Unicode. La norme in­ter­na­tio­nale ISO 10646 définit les grandes lignes d’Unicode, appelé dans cette norme « Universal Coded Character Set ». Les dé­ve­lop­peurs d’Unicode ont limité certains pa­ra­mètres pour l’ap­pli­ca­tion pratique. Ce standard doit permettre un codage homogène et com­pa­tible à l’in­ter­na­tio­nal des ca­rac­tères et des éléments textuels.

Lors de son in­tro­duc­tion en 1991, Unicode dé­fi­nis­sait 24 systèmes d’écriture modernes ainsi que des symboles mo­né­taires pour le trai­te­ment des données. En 2024, il en compte 168. Il existe dif­fé­rents formats de trans­for­ma­tion Unicode, abrégés en « UTF », qui per­met­tent de re­pro­duire les 1 114 112 points de code possibles. Trois formats ont réussi à s’établir : UTF-8, UTF-16 et UTF-32. Même s’ils pré­sen­taient certains avantages, les autres codages, tels que UTF-7 ou le SCSU, ne sont pas parvenus à s’imposer. Unicode est divisé en 17 plans de 65 536 ca­rac­tères. Chaque plan est composé de 16 colonnes et lignes. Le plan 0, nommé « Basic Mul­ti­lin­gual Plane », regroupe une grande partie des systèmes d’écriture ac­tuel­le­ment utilisés dans le monde ainsi que les ca­rac­tères de ponc­tua­tion, des ca­rac­tères de contrôle et des symboles. Six autres plans sont ac­tuel­le­ment utilisés :

• « Sup­ple­men­tary Mul­ti­lin­gual Plane » (plan 1) : systèmes d’écriture his­to­riques, ca­rac­tères rarement utilisés
• « Sup­ple­men­tary Ideo­gra­phic Plane » (plan 2) : ca­rac­tères chinois, japonais et coréens rares
• « Tertiary Ideo­gra­phic Plane » (plan 3) : depuis la version 15.1 d’Unicode, d’autres ca­rac­tères CJC sont encodés ici
• « Sup­ple­men­tary Special-Purpose Plane » (plan 14) : ca­rac­tères de contrôle in­di­vi­duels
• « Sup­ple­men­tary Private Use Area – A » (plan 15) : uti­li­sa­tion privée
• « Sup­ple­men­tary Private Use Area – B » (plan 16) : uti­li­sa­tion privée

Les codages UTF per­met­tent d’accéder à tous les ca­rac­tères Unicode. Leurs pro­prié­tés res­pec­tives con­vien­nent à dif­fé­rents domaines d’ap­pli­ca­tion.

Les al­ter­na­tives : UTF-32 et UTF-16

UTF-32 travaille toujours avec 32 bits, soit 4 octets. Sa structure simple permet d’augmenter la li­si­bi­lité du format. Dans les langues qui utilisent prin­ci­pa­le­ment l’alphabet latin et donc uni­que­ment les 128 premiers ca­rac­tères, ce codage demande beaucoup plus d’espace disque que né­ces­saire (4 octets au lieu d’un).

UTF-16 s’est imposé comme format d’affichage dans les systèmes d’ex­ploi­ta­tion comme Apple macOS et Microsoft Windows. Il est également utilisé dans de nombreux en­vi­ron­ne­ments de dé­ve­lop­pe­ment logiciel. Il s’agit de l’un des UTF les plus anciens encore utilisé à l’heure actuelle. Sa structure convient tout par­ti­cu­liè­re­ment à un codage peu en­com­brant des ca­rac­tères lin­guis­tiques non latins. Seuls quelques rares ca­rac­tères né­ces­si­tent une longueur de 4 octets, la plupart des ca­rac­tères pouvant être affichés avec 2 octets (16 bits).

Efficace et évolutif : UTF-8

UTF-8 comporte jusqu’à quatre chaînes de 8 bits. Son pré­dé­ces­seur, l’ASCII, comprend quant à lui une chaîne de 7 bits. Les deux codages dé­fi­nis­sent les 128 premiers ca­rac­tères en les codant de la même façon. Ces ca­rac­tères, qui viennent prin­ci­pa­le­ment de l’espace an­glo­phone, sont ainsi re­pré­sen­tés avec un octet à chaque fois. Pour les langues utilisant l’alphabet latin, ce format est le plus économe en termes d’espace disque. Les systèmes d’ex­ploi­ta­tion Unix et Linux l’utilisent en interne. C’est toutefois dans le cadre des ap­pli­ca­tions Internet qu’UTF-8 joue son rôle le plus important, à savoir pour l’affichage du texte sur Internet ou dans les emails.

Sa structure auto-syn­chro­ni­sante permet de maintenir la li­si­bi­lité malgré une longueur par caractère variable. Sans li­mi­ta­tion Unicode, UTF-8 per­met­trait 4 398 046 511 104 at­tri­bu­tions de ca­rac­tères. Avec la li­mi­ta­tion à 4 octets d’Unicode, ce chiffre se porte dans les faits à 2²¹, ce qui est plus que suffisant. Certains plans de l’espace de codage Unicode restent vides et peuvent ac­cueil­lir de nombreux autres systèmes d’écriture. La précision des at­tri­bu­tions empêche les che­vau­che­ments de points de code qui li­mi­taient la com­mu­ni­ca­tion par le passé.

Même si l’at­tri­bu­tion permise par UTF-16 et UTF-32 est tout aussi précise, UTF-8 utilise l’espace disque de façon par­ti­cu­liè­re­ment efficace pour le système d’écriture latin et est conçu pour permettre la cou­ver­ture et la coexis­tence de dif­fé­rents systèmes d’écriture sans dif­fi­culté. Un affichage simultané et pertinent dans un champ de texte est ainsi possible sans problème de com­pa­ti­bi­lité.

Principes de base : codage UTF-8 et structure

Le codage UTF-8 séduit d’une part par sa ré­tro­com­pa­ti­bi­lité avec ASCII et d’autre part par sa structure auto-syn­chro­ni­sante, qui permet aux dé­ve­lop­peurs d’iden­ti­fier plus fa­ci­le­ment les sources d’erreurs a pos­te­riori. UTF utilise 1 seul octet pour l’ensemble des ca­rac­tères ASCII. Le nombre total de chaînes de bits est iden­ti­fiable aux premiers chiffres du nombre binaire. Puisque le code ASCII comporte uni­que­ment 7 bits, le tout premier chiffre est l’in­di­ca­teur 0. Le 0 remplit l’espace disque en­tiè­re­ment jusqu’à 1 octet et indique le début d’une chaîne sans octet de con­ti­nua­tion. En nombre binaire, le nom « UTF-8 » s’ex­pri­me­rait par exemple comme suit avec le codage UTF-8 :

Le codage UTF-8 attribue aux ca­rac­tères ASCII, comme ceux utilisés dans le tableau, une chaîne de bits unique. Tous les ca­rac­tères et symboles suivants d’Unicode com­por­tent de deux à quatre chaînes de 8 bits. La première chaîne est appelée octet de début de séquence et les chaînes sup­plé­men­taires des octets de con­ti­nua­tion. Les octets de début de séquence com­men­cent toujours par 11 alors que les octets de con­ti­nua­tion com­men­cent toujours par 10. Si vous re­cher­chez ma­nuel­le­ment un point précis dans le code, vous pouvez par con­sé­quent iden­ti­fier le début d’un caractère codé par les marqueurs 0 et 11. Le premier caractère de plusieurs octets im­pri­mable est le point d’ex­cla­ma­tion inversé :

Le codage du préfixe permet d’éviter qu’un autre caractère soit codé au sein d’une chaîne d’octet. Si un flux d’octet commence au milieu d’un document, l’or­di­na­teur affiche malgré tout les ca­rac­tères lisibles cor­rec­te­ment, puisqu’il n’affiche pas les ca­rac­tères in­com­plets. Si vous re­cher­chez le début d’un caractère, la limite de 4 octets impose de retourner au maximum trois chaînes d’octet en arrière pour retrouver l’octet de début de séquence, quel que soit le point où vous vous trouviez.

Autre élément struc­tu­rant : le nombre de 1 au début de l’octet de début de séquence indique la longueur de la chaîne d’octets :

• 110xxxxx indique 2 octets,
• 1110xxxx indique 3 octets,
• 11110xxx indique 4 octets.

Dans Unicode, la valeur d’octet attribuée cor­res­pond au numéro de caractère, ce qui permet un ordre lexical. Néanmoins, il existe des plages vides. La plage Unicode de U+007F à U+009F comporte des chiffres de contrôle in­vi­sibles. Le standard UTF-8 ne leur attribue aucun caractère im­pri­mable, uni­que­ment des commandes.

Comme indiqué pré­cé­dem­ment, jusqu’à huit chaînes d’octet peuvent théo­ri­que­ment se succéder avec le codage UTF-8. L’Unicode impose toutefois une longueur de 4 octets au maximum. Cela implique que les chaînes d’octet avec 5 octets ou plus ne sont pas valides par défaut. Par ailleurs, cette li­mi­ta­tion reflète la volonté de présenter le code de façon aussi compacte, c’est-à-dire avec un minimum d’en­com­bre­ment de l’espace disque, et aussi struc­tu­rée que possible. Utiliser toujours le codage le plus court possible constitue une règle de base dans le cadre de l’uti­li­sa­tion d’UTF-8.

Cependant, pour certains ca­rac­tères, il existe plusieurs codages équi­va­lents. La lettre ä est par exemple codée avec 2 octets : 11000011 10100100. En théorie, il est possible de combiner les points de code de la lettre a (01100001) et du tréma ¨ (11001100 10001000) pour afficher un ä : 01100001 11001100 10001000. On utilise ici la forme de nor­ma­li­sa­tion Unicode NFD, dans laquelle les ca­rac­tères sont dé­com­po­sés de manière canonique. Les deux encodages présentés donnent exac­te­ment le même résultat (à savoir ä) et sont donc ca­no­ni­que­ment équi­va­lents.

Certaines plages de valeurs Unicode n’ont pas été définies pour UTF-8, car elles existent déjà pour les demi-codets UTF-16. Cette vue montre quels octets sont autorisés dans UTF-8 sous Unicode d’après l’Internet En­gi­nee­ring Task Force (IETF) (IETF) : les cellules colorées en vert sont les octets valides, les cellules colorées en orange sont les octets invalides.

Plages de valeurs UTF-8 et des­crip­tion

Con­ver­sion d’hexa­dé­ci­mal Unicode en binaire UTF-8

Les or­di­na­teurs ne lisent que les chiffres binaires, tandis que l’être humain utilise un système décimal. Le système hexa­dé­ci­mal constitue une interface entre ces deux formes et permet de re­pré­sen­ter les longues chaînes de bits sous une forme compacte. Pour ce faire, il utilise les chiffres de 0 à 9 ainsi que les lettres de A à F et se base sur le nombre 16. En tant que quatrième puissance de 2, le système hexa­dé­ci­mal convient mieux que le système décimal pour re­pré­sen­ter des plages d’octet à huit chiffres.

Un nombre hexa­dé­ci­mal cor­res­pond à un « nible » (ensemble de quatre bits) au sein d’un octet. Un octet avec huit nombres binaires peut donc être re­pré­senté avec deux nombres hexa­dé­ci­maux seulement. L’Unicode utilise le système hexa­dé­ci­mal pour décrire la position d’un caractère au sein du système choisi. À partir de là, il est possible de dé­ter­mi­ner le nombre binaire et fi­na­le­ment le point de code UTF-8.

Le nombre binaire doit tout d’abord être obtenu à partir du nombre hexa­dé­ci­mal. Vous pouvez ensuite intégrer les points de code dans la structure du codage UTF-8. Afin de sim­pli­fier la struc­tu­ra­tion, utilisez l’aperçu suivant qui indique combien de points de code rentrent dans une chaîne d’octets et quelle structure vous êtes sus­cep­tible de ren­con­trer dans telle ou telle plage de valeurs Unicode.

Puisque l’ordre lexical pour la nu­mé­ro­ta­tion des points de code Unicode et des nombres binaires UTF-8 est respecté, vous pouvez pré­sup­po­ser le nombre d’octets en fonction de la plage de code. Dans la plage U+0800 et U+FFFF par exemple, UTF-8 utilise 3 octets. Il y a donc 16 bits dis­po­nibles pour exprimer le point de code d’un symbole. L’or­don­nan­ce­ment d’un nombre binaire déterminé selon le schéma UTF-8 s’effectue de droite à gauche, les éventuels espaces à gauche étant complétés avec des zéros.

Exemple : Le ca­rac­tè­reᅢ(Hangul Junseong, Ä) est situé à la position U+1162 dans Unicode. Pour dé­ter­mi­ner le nombre binaire, con­ver­tis­sez tout d’abord le nombre hexa­dé­ci­mal en nombre décimal. Chaque chiffre de ce nombre cor­res­pond à la puissance corrélée de 16. Le chiffre à droite a la valeur la plus faible avec 160 = 1. En partant de la droite, mul­ti­pliez la valeur numérique du chiffre avec celle de la puissance. Ad­di­tion­nez ensuite les résultats.

Close

4450 est le nombre décimal déterminé. Con­ver­tis­sons main­te­nant ce nombre décimal en nombre binaire. Pour ce faire, divisez le nombre par 2 et reportez le reste, jusqu’à ce que le résultat soit 0. Le reste, lu de droite à gauche, cor­res­pond au nombre binaire.

Close

Le code UTF-8 prévoit 3 octets pour le point de code U+1162, car ce point de code est situé entre U+0800 et U+FFFF. L’octet de début de séquence commence donc par 1110. Les deux octets de con­ti­nua­tion com­men­cent par 10. Complétez le nombre binaire avec les bits libres qui ne dé­ter­mi­nent pas la structure, de droite à gauche. Complétez les bits restants de l’octet de début de séquence avec 0 jusqu’à ce que l’octet soit complet. Le codage UTF-8 se présente alors comme suit : 11100001 10000101 10100010 (le point de code inséré est mis en gras)

UTF-8 dans les éditeurs

Même si UTF-8 est sans conteste le standard le plus répandu sur Internet, les éditeurs de texte simples n’en­re­gistrent pas né­ces­sai­re­ment les textes dans ce format par défaut. Microsoft Notepad utilise par exemple par défaut un codage qu’il désigne par « ANSI » (qui cor­res­pond en fait au codage « Windows-1252 » basé sur ASCII). Si vous souhaitez convertir un fichier texte depuis Microsoft Word au format UTF-8 (par exemple pour re­pré­sen­ter dif­fé­rents systèmes d’écriture), procédez comme suit : cliquez sur « En­re­gis­trer sous » et sé­lec­tion­nez l’option « Texte brut » dans Type.

Close

Close

Si vous ouvrez un fichier texte non marqué pour lequel vous ne con­nais­sez pas le codage utilisé, le trai­te­ment de ce fichier pourra poser problème. Sous Unicode, on utilise dans de tels cas l’« in­di­ca­teur d’ordre des octets » (« byte order mark » ou BOM). Ce caractère invisible permet d’afficher si le document est dans un format Big-Endian ou Little-Endian. En effet, si un programme décode un fichier codé en UTF-16 Little-Endian à l’aide de UTF-16 Big-Endian, le texte com­por­tera des erreurs.

Les documents reposant sur le jeu de ca­rac­tères UTF-8 ne ren­contrent pas ce problème, car l’ordre des octets est toujours lu comme une séquence d’octets Big-Endian. Dans ce cas, le BOM sert uni­que­ment à indiquer que le document en question est codé en UTF-8.

Le BOM est placé avant un flux de données ou au début d’un fichier. Ce marquage est prio­ri­taire sur toutes les autres in­di­ca­tions, même sur l’en-tête HTTP. Le BOM fait office de signature pour les codages Unicode et a le point de code U+FEFF. Selon le codage utilisé, le BOM peut adopter une forme codée dif­fé­rente.

L’in­di­ca­teur d’ordre des octets n’est pas utilisé lorsque le protocole l’interdit ex­pli­ci­te­ment ou lorsqu’un type spé­ci­fique a déjà été attribué à vos données. Selon le protocole, certains pro­grammes attendent des ca­rac­tères ASCII. Comme UTF-8 est ré­tro­com­pa­tible avec le codage ASCII et l’ordre de ses octets est fixe, un in­di­ca­teur d’ordre des octets est inutile. En réalité, Unicode ne re­com­mande pas l’uti­li­sa­tion d’un BOM sous UTF-8. Mais comme il est présent dans l’ancien code et peut causer des problèmes, il est essentiel de savoir iden­ti­fier un éventuel in­di­ca­teur de ce type.