Un décodage est une fonction sur un sous-ensemble fini d'entiers naturels (les codes) vers un ensemble dont les éléments sont les choses codées : caractères, groupes ou parties de caractères, actions, positions, sons, couleurs. Un décodage n'est pas nécessairement défini sur un seul intervalle ni injectif (ou univoque). Un codage est une fonction inverse d'un décodage. En gros, coder est numériser.

Codage de caractère

ASCII

Les caractères !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`\abcdefghijklmnopqrstuvwxyz{|}~ sont codés (dans l'ordre) sur les nombres entiers (en base 16) 0x21 à 0x7E, qui ont au plus 7 bits (chiffres en base 2).

ISO 8859-1 ou latin-1

C'est un prolongement d'ASCII. Les caractères ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ sont codés sur les nombres entiers à 8 bits 0xA1 à 0xFF, sauf 0xAD. Par exemple, le code de « é » est 0xE9.

ISO 8859-15 ou latin-9

Prolongement d'ASCII, incompatible avec (n'est pas un prolongement de) ISO-8859-1, comprenant en particulier les caractères français œŒ€Ÿ.

Mac Roman

Prolongement d'ASCII, incompatible avec les ISO-8859, utilisé dans Mac OS 9.

UCS-2 ou le plan multilingue de base

Prolongement de ISO 8859-1. Presque tous les caractères de toutes les langues, y compris arabe, chinois, japonais, coréen, sont codés sur les nombres entiers de 0 à 0xFFFF = 65535, qui ont au plus 16 bits ou 2 octets (1 octet = 8 bits). Exemple : le caractère de code 0x4E00, noté U+4E00, est 一 (yi, un), le premier caractère chinois. Pour les langues européennes, un octet sur deux étant toujours nul, UCS-2 est 100 % redondant.

UTF-8

Prolongement d'ASCII, incompatible avec ISO 8859-1, ce qui est une source de confusion. Notamment, les caractères ISO 8859-1 non ASCII sont codés sur deux octets, le premier étant 0xC2 ou 0xC3 ( et à en ISO-8859-1). Un code de « é » est 0xC3 0xA9. Les caractères UTF-8 non ISO 8859-1 sont codés sur trois ou quatre octets. Pour que toute suite d'octets soit séparable (en l'absence de séparateur explicite -- qui poserait d'autres problèmes), aucun code à n octets (n>1) ne doit commencer par un code à n-1 octet(s). Les caractères chinois étant codés sur trois octets (au lieu de deux en UCS-2), UTF-8 est 50 % redondant pour le chinois. Pour le français, à cause des caractères non ASCII codés sur deux octets au lieu d'un en ISO-8859-15, UTF-8 est environ 10 % redondant (en supposant qu'un caractère sur 10 est accentué). La redondance d'UTF-8 réalise un compromis mondial, entre Amérique, Europe et Asie, d'où son succès.

UCS-4

Prolongement d'UCS-2. Les caractères sont codés sur les nombres entiers de 0 à 0x10FFFF = 1.114.111, qui ont au plus 21 bits, occupant pratiquement 4 octets. UCS-4 n'est pas utilisé dans les ordinateurs pour cause de redondance.

UTF-16

Prolongement d'UCS-2. Même principe qu'UTF-8 mais avec un ou deux seizets. Les codes 0xD800 = 55296 à 0xDFFF = 57343 d'UCS-2 sont réservés aux seizets qui composent les paires d'UTF-16.

Par exemple, sur le site Paypal (an 2022 !), ISO 8859-1 est utilisé incorrectement au lieu d'UTF-8 :

Codage de caractère incompatible avec ASCII : EBCDIC d'IBM.

Représentation d'un placement de signe suivant

Pour représenter le placement du signe suivant, sans rien écrire, on utilise l'espace ou une balise commençant par le caractère d'échappement \ suivi d'une lettre autre que \ (et \\ désigne le \ normal).

ASCII :

Les autres nombres de 0x00 à 0x1F et 0x7F ne codent aucun caractère ou placement de signe suivant.

ISO 8859-1 :

placement de signe suivant	balise	code
espace insécable		0xA0
césure optionnelle		0xAD

La représentation du saut de ligne dépend du système d'exploitation :

système d'exploitation	saut de ligne
Mac OS 9	\r
Unix	\n
DOS	\r\n

Le code de saut de ligne DOS est probablement inspiré du fonctionnement des anciennes machines à écrire, qui permettaient de faire un retour de chariot en restant sur la même ligne, ce qui était utile par exemple pour souligner.

Décomposition

Le caractère accentué « é » peut être décomposé en « e » suivi du caractère accent aigu combinant, qui se trouve être en réalité à la fois un caractère et une instruction de placement. Précisément, « é » peut être codé, en UCS-2 : U+0065 U+0301, en UTF-8 : 0x65 0xCC 0x81. Quand on rencontre un 0x65 dans une suite d'octets (sans séparateur explicite) de code UTF-8, on ne peut pas savoir quel caractère est codé exactement (é, è, ë…), avant d'avoir lu les deux octets suivants. Autrement dit, si on considère « é » comme un caractère, le principe de séparation énoncé plus haut n'est pas valable pour le codage UTF-8.

Vu l'ennui de la chose et la minorité de développeurs concernés par les langues utilisant un alphabet latin étendu, la décomposition n'est pas totalement supportée par de nombreux programmes prétendus compatibles avec Unicode.

Décodage incorrect de texte et corruption de fichier

Le codage d'un texte devrait être indiqué quelque part, au début ou à la fin. Cependant, cela pose en principe un problème d'auto-référence : quel codage utiliser pour préciser le codage ? De plus, si le texte est découpé, alors l'indication de codage est perdue dans le reste des morceaux. Alors il est impossible de garantir un décodage correct.

Emacs, recode, charconv, iconv recodent les textes. ftp en mode texte recode les sauts de ligne. MIME recode le courrier électronique.

Une cause fréquente de corruption de fichier binaire (ne codant pas que des caractères) est un décodage-recodage, comme s'il s'agissait d'un texte. Par exemple, si on envoie un binaire exécutable avec ftp en mode texte, alors il ne fonctionnera plus forcément à l'arrivée. De plus, si le décodage initial est non injectif, alors la corruption est irréversible.

Codage de nom de fichier

HFS (Mac OS 9) :

Mac Roman,

Linux :

UTF-8,

HFS+ (Mac OS X étendu) :

utilise en interne UTF-16 décomposé (sauf U+2000-2FFF, F900-FA6A, 2F800-2FA1D) mais selon l'interface peut fournir UTF-8 décomposé alias UTF-8m, UTF-8-MAC.

Linux supporte la décomposition, alors que Mac OS X la force, recodant les noms de fichier en provenance d'autres sytèmes, ce qui peut pertuber les programmes de copie (comme rsync) : une copie de Linux vers Mac puis de Mac vers Linux crée un doublon du côté Linux.

Le programme convmv recode les noms de fichier.

Le séparateur entre nom de répertoire et nom de fichier dépend aussi du système (Mac : :, Unix : /, DOS : \).

Format de fichier

Un format de fichier est une représentation adaptée à une application particulière. Un fichier peut être rattaché à une application à l'aide d'une extension de nom de fichier (après le dernier point). Historiquement, DOS était limité à une extension de trois caractères.

Pour éviter de corrompre un fichier par transmission, on peut le représenter au format BinHex ou Base64, qui n'utilise que des caractères ASCII, ce qui le rallonge et, s'il codait un texte, le rend illisible en ASCII.

Pour éviter de mal décoder un fichier codant des caractères non ASCII ou placements de signe suivant, on peut les représenter en caractères ASCII. Par exemple, la balise de saut de ligne est <br>. C'est ainsi que HTML passe partout ou ASCII est reconnu.

Un format de fichier propriétaire (non public) compromet la portabilité, voir formats-ouverts.org.

Références

• Internationalization Programming Topics. Apple Computer, Inc. 2005-09-08.
• Fontes & codages. Yannis Haralambous. O'Reilly 2004.

Dernière modification : (2023-06-12 13:52:55 WEST)