UTF-8(7) | Miscellaneous Information Manual | UTF-8(7) |
UTF-8 - Encodage Unicode multioctet compatible ASCII
The Unicode 3.0 character set occupies a 16-bit code space. The most obvious Unicode encoding (known as UCS-2) consists of a sequence of 16-bit words. Such strings can contain—as part of many 16-bit characters—bytes such as '\0' or '/', which have a special meaning in filenames and other C library function arguments. In addition, the majority of UNIX tools expect ASCII files and can't read 16-bit words as characters without major modifications. For these reasons, UCS-2 is not a suitable external encoding of Unicode in filenames, text files, environment variables, and so on. The ISO 10646 Universal Character Set (UCS), a superset of Unicode, occupies an even larger code space—31 bits—and the obvious UCS-4 encoding for it (a sequence of 32-bit words) has the same problems.
L’encodage UTF-8 de l'Unicode et de l'UCS n'a pas ces inconvénients et est un moyen d'utiliser le jeu de caractères Unicode sous les systèmes d'exploitation compatibles UNIX.
L’encodage UTF-8 a les propriétés suivantes.
Les suites d'octets suivantes sont utilisées pour représenter un caractère. Les suites utilisées dépendent du numéro de code UCS du caractère :
Les positions des bits xxx sont remplies avec les bits du numéro de code du caractère en représentation binaire, bit de poids fort en premier (gros-boutiste). Seule la plus petite suite multioctet permettant de représenter un numéro de code doit être utilisée.
The UCS code values 0xd800–0xdfff (UTF-16 surrogates) as well as 0xfffe and 0xffff (UCS noncharacters) should not appear in conforming UTF-8 streams. According to RFC 3629 no point above U+10FFFF should be used, which limits characters to four bytes.
Le caractère Unicode 0xA9 = 1010 1001 (le symbole copyright) est encodé en UTF-8 de la manière suivante :
et le caractère 0x2260 = 0010 0010 0110 0000 (le symbole « différent de ») est encodé ainsi :
Les utilisateurs doivent sélectionner des paramètres régionaux UTF-8, par exemple en faisant
afin d'activer la gestion de l’UTF-8 dans les applications.
Les applications qui doivent connaître l’encodage de caractères utilisé doivent toujours définir la locale, en faisant par exemple
et les programmeurs peuvent tester l'expression
pour savoir si des paramètres régionaux UTF-8 ont été sélectionnés, et si les entrées et sorties texte, les communications avec les terminaux, le contenu des fichiers textes, les noms de fichiers et les variables d'environnement sont encodés en UTF-8.
Les programmeurs habitués aux jeux de caractères mono-octet comme US-ASCII ou ISO 8859 doivent savoir que deux hypothèses valables jusque là ne le sont plus dans les paramètres régionaux UTF-8. D'abord, un octet seul ne correspond pas nécessairement à un unique caractère. Ensuite, comme les émulateurs de terminaux modernes en mode UTF-8 gèrent également les caractères double largeur du chinois, du japonais ou du coréen et les caractères combinés sans espacement, l’affichage d'un unique caractère ne fait pas avancer obligatoirement le curseur d'une position comme c'était le cas en ASCII. Les fonctions de bibliothèques comme mbsrtowcs(3) et wcswidth(3) doivent être désormais utilisées pour compter les caractères et les positions de curseur.
La suite ESC officielle pour basculer d'un encodage ISO 2022 (comme utilisé par exemple par les terminaux VT100) en UTF-8 est ESC % G (« \x1b%G »). La suite de retour depuis UTF-8 est ISO 2022 est ESC % @ (« \x1b%@ »). D'autres suites ISO 2022 (comme celle pour basculer entre les jeux G0 et G1) ne sont pas applicables en mode UTF-8.
Les normes Unicode et UCS demandent que le fabricant utilisant UTF-8 utilise la forme la plus courte possible, par exemple, produire une suite de deux octets avec un premier octet 0xc0 n'est pas conforme. Unicode 3.1 a ajouté la nécessité pour les programmes conformes de ne pas accepter les formes non minimales en entrée. Il s'agit de raisons de sécurité : si une saisie est examinée pour des problèmes de sécurité, un programme doit rechercher seulement la version ASCII de « /../ » ou « ; » ou NUL. De nombreuses manières non ASCII existent pour représenter ces choses dans un encodage UTF-8 non minimal.
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.
locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)
La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot <david@tilapin.org> et Grégoire Scano <gregoire.scano@malloc.fr>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.
10 février 2023 | Pages du manuel de Linux 6.03 |