PrograZine #9 - Le codage de caractères

> Théorie

PrograZine issue #9 - http://www.citeweb.net/discase/9/CARACT.htm

Edito

Sommaire

Contribution

Contacts

Le codage de caractères
par Michel Jacobson - michel.jacobson@gmail.com CNRS/LACITO

Initié

>Les mythes

Avant d’entrer dans le vif du sujet, tuons d’abord un vieux mythe bien ancré : Les fichiers informatiques quels qu’ils soient, même si ce sont des fichiers texte, ne contiennent pas de caractères. Ils contiennent des suites d’unités binaires appelées bits, c’est à dire des unités qui ne peuvent prendre que deux valeurs et que l’on a coutume de représenter sous les formes '0' ou '1'. Il n’y a pas d’exception à cette règle.

Tant que nous y sommes, tuons un deuxième mythe : L’octet n’est pas l’avatar informatique du caractère. L’octet n’est jamais qu’une suite de 8 bits consécutifs. Si l’on interprète un octet comme représentant une valeur numérique codés en base 2, l’octet permet de distinguer 2⁸, soit 256 valeurs possibles. Ces valeurs vont

        de 0:    0000.0000
        à 255:   1111.1111

Mais ce n’est pas la seule interprétation possible d’un octet. Par exemple de nombreux langages permettent aussi d’y lire un entier signé allant de -128 à +127.

Mais alors, si les fichiers ne sont composés que de '0' et '1', et si les octets ne sont pas des caractères, qu’est ce qu’un caractère et où se cache-t-il lorsque l’on saisit du texte dans un éditeur ? Et, pourquoi quand on a réussi laborieusement à en mettre un dans un fichier se transforme-t-il en gros « pâté » quand on passe d’un système à un autre ? Enfin par quelle magie certains interpréteurs comme les navigateurs du web, MS-Word, TeX, etc. arrivent-ils à afficher les mêmes caractères d’un système à l’autre ?

>La petite histoire du caractère

Avant d’être traitée par l’informatique, l’industrie du texte a été dominée par l’imprimerie. Les « casses » étaient des supports physiques pour les caractères de plomb utilisés dans l’édition. Dans une casse, chaque caractère était positionné à un endroit précis et invariable. Le caractère était donc identifiable par la place qu’il occupait, et ceci quelle que soit la taille, ou le style utilisé. La casse qui comportait environ une centaine de cassetins était le reflet d’une analyse de la langue qu’elle codait et des traditions typographiques qui lui étaient attachées. Ainsi dans la casse Parisienne :

les lettres capitales, les minuscules, les chiffres, les lettres accentuées, etc. formaient des groupes avec une organisation interne indépendante d’un groupe à l’autre.

certaines groupes de caractères faisaient l’objet de ligatures prédéfinies.

Plus tard, mais avant la popularisation de l’informatique, les premiers alphabets internationaux sont apparus avec notamment le Télex et le Morse. Ces alphabets à 6 moments, soit 2⁶ ou 64 caractères possibles, ne comportaient que les lettres latines majuscules (ou du moins sans distinction majuscule ~ minuscule), les chiffres et quelques signes de ponctuation.

Ensuite, à l’avènement de l’informatique, les normalisations de codage de caractères se sont succédées cherchant à reproduire le même concept d’association entre un code identifiant (position dans la casse) et la définition d’un caractère. Le principal objectif de ces normes est bien sûr la standardisation en vue de l’échange des données.

>Qu’est-ce qu’un code caractère ?

Un code caractère est une norme qui :

Met en correspondance chaque position du code avec une définition (par exemple dans le code ASCII, la position décimale 33 correspond à la définition 'exclamation point')

Propose des symboles typographiques (glyphes) pour chaque position (par exemple dans le code ASCII , la position décimale 33 correspond au symbole graphique '!')

Propose une ou plusieurs façons de coder le caractère sous forme de suite organisée de bits. Par exemple les caractères du code ASCII sont codés sur un octet. Leur valeur numérique est donnée par l’interprétation des 7 derniers bits de l’octet. Le premier bit est inutilisé, ou réservé à d’autres tâches qu’à l’expression des caractères.

Il demeure de nombreux autres problèmes qu’un code doit aider à résoudre comme celui des équivalences entre caractères composés par exemple.

De nombreux codes caractères ont été proposés par les fabricants de matériel informatique, ou par des regroupement d’intérêts, et bien sûr par les organismes de normalisation (ISO AFNOR, IEC, etc.). Nous examinerons un certain nombre de ces normalisations par ordre chronologique et verrons comment ces dernières sont utilisées par les nouveaux outils d’édition.

>L’ASCII (American Standard Coded Information Interchange)

L’ASCII est certainement la plus connue des normes de codage de caractère. Elle a été modifiée en 1963 par l’ISO et le CCITT sous le nom de ISO-646. Il s’agit d’un alphabet codé sur 7 bits et donc comportant 2⁷, soit 128 caractères différents. Cette norme définit :

33 caractères dits de « contrôle ».

95 caractères graphiques
- les 26 lettres latines majuscules ( A - Z )
- les 26 lettres latines minuscules ( a - z )
- les 10 chiffres arabes ( 0 - 9 )
- le caractère d’espacement
- 20 signes de ponctuation ou autres : ( ! « % & ' ( ) * + , - . / : ; < = > ? _ )
- 2 caractères au choix ( # ou £ ) et ( $ ou ¤ )
- 10 caractères réservés aux usages nationaux (c’est à ces positions qu’ont été placées quelques lettres accentuées pour le français)

    Dans sa version finale de 1988 la norme ISO-646 IRV, (version internationale de référence) ne comprend plus de caractères accentués ni de caractères au choix ou d’usages différent suivant les nationalités. On voit que cette norme est loin de répondre même aux seuls besoins du français. Cependant, elle reste très répandue, et permet de satisfaire aux besoins de l’anglais et à la plupart des anciens langages de programmation.

    On remarquera une première dérive de la notion de caractère issue de l’imprimerie : En effet les caractères de contrôle ne sont plus des caractères typographiques, mais des caractères utiles uniquement pour l’informatique comme le caractère 'BEL' pour déclencher un bip sonore ou le caractère 'EOT' pour 'END OF TRANSMISSION'.

    Le tableau ci-dessous donne la signification sous forme typographique quand c’est possible, sinon sous la forme d’un nom symbolique, de toutes les positions du code ISO-646 IRV. La position est donnée en hexadécimal. Par exemple : le caractère 'L' est à la position '4C' (hexadécimal), équivalent à 76 en décimal.

>Tableau des positions de l’ISO-646 IRV

	0-	1-	2-	3-	4-	5-	6-	7-
-0	NUL	DLE	SP	0	@	P	`	p
-1	SOH	DC1	!	1	A	Q	a	q
-2	STX	DC2	"	2	B	R	b	r
-3	ETX	DC3	#	3	C	S	c	s
-4	EOT	DC4	¤	4	D	T	d	t
-5	ENQ	NAK	%	5	E	U	e	u
-6	ACK	SYN	&	6	F	V	f	v
-7	BEL	ETB	'	7	G	W	g	w
-8	BS	CAN	(	8	H	X	h	x
-9	HT	EM	)	9	I	Y	i	y
-A	LF	SUB	*	:	J	Z	j	z
-B	VT	ESC	+	;	K	[	k	{
-C	FF	FS	,	<	L	\	l	\|
-D	CR	GS	-	=	M	]	m	}
-E	SO	RS	.	>	N	^	n	~
-F	SI	US	/	?	O	_	o	DEL

La plupart des outils d’édition de texte permettent de saisir et de gérer des textes en ASCII, mais souvent ces mêmes outils peuvent se servir du premier bit de chaque octet pour adresser des caractères non ASCII. En fait, beaucoup d’éditeurs utilisent le code caractère de la machine sur laquelle ils tournent (code Mac, code MS-Windows, etc.). Le codage des caractères s’effectue alors sur les 8 bits de l’octet, ce qui permet 256 caractères distincts. Mais ces codes restent compatibles avec l’ASCII, c’est à dire que les 128 premières positions sont celles de l’ASCII, les 128 suivantes sont spécifique au code utilisé. Ainsi donc, si l’on fait attention à ne saisir aucun caractère supérieur à 127, c’est à dire en laissant le premier bit de chaque octet à zéro (positions : 00000000 à 01111111), le texte est du pur ASCII, et parfaitement échangeable d’une plate-forme à une autre.

On notera pour finir l’organisation du code avec les 2 premières colonnes correspondant aux 32 premiers caractères non graphiques. Ce principe d’organisation sera en effet reproduit dans les codes que nous allons examiner à présent.

>L’ISO-8859-n (ISO-Latin-n)

La volonté (commerciale) de pouvoir saisir et échanger des textes en langues de grandes cultures autre que l’anglais a poussé les fabricants et les organismes de normalisation à l’établissement de nouvelles normes. Une de ces normes connue sous le nom d’ISO-Latin-n ou ISO-8859-n permet de coder les caractères sur 8 bits soit 256 caractères différents possibles. Il existe pour l’instant 12 versions de cette norme déclinée suivant des groupes de langues ou de cultures.

        8859-1  Europe occidentale, Amérique latine,
		    allemand, anglais, danois, espagnol, féroïen, finnois,
		    français, islandais, italien, néerlandais, norvégien, portugais, suédois
        8859-2  Europe orientale
        8859-3  autres langues utilisant l’alphabet latin
        8859-4  Europe du nord
        8859-5  latin/cyrillique
        8859-6  latin/arabe
        8859-7  latin/grec
        8859-8  latin/hébreu
        8859-9  variante de Latin-1 pour le turc
        8859-10 sami/nordique/eskimo
        8859-11 latin/thaïlandais (en préparation)
        8859-11 latin/devanagri (en préparation)

La composition de l’ISO-Latin-1 concernant le français, comme toutes les autres normes ISO-8859-n, reprend dans ses 128 premiers caractères ceux de la norme US-ASCII (US-ASCII ne diffère de l’ISO-646 que par le symbole monétaire '$' à la place du '¤'). Les 128 caractères supplémentaires sont organisés comme les 128 premiers : à savoir 32 caractères de contrôle suivis de 96 caractères graphiques qui sont utilisés pour placer des lettres accentuées, des accents flottants et quelques symboles spéciaux. Armé de cette norme, la saisie du français et l’échange des documents est facilitée. On déplore quand même l’absence dans l’ISO-Latin-1 du 'ÿ' majuscule et des ligatures 'œ' et 'Œ'. Ces omissions, pour l’anecdote, sont souvent imputées dans la littérature à l’absence du représentant français, ou au manque de consultation par ce dernier, lors d’une réunion d’un groupe de travail sur la normalisation.

>Tableau des positions 128 à 255 de l'ISO-8859-1

	8-	9-	A-	B-	C-	D-	E-	F-
-0	PAD	DCS	NBSP	°	À	Ð	à	ð
-1	HOP	PU1	¡	±	Á	Ñ	á	ñ
-2	BPH	PU2	¢	²	Â	Ò	â	ò
-3	NBH	STS	£	³	Ã	Ó	ã	ó
-4	IND	CCH	¤	´	Ä	Ô	ä	ô
-5	NEL	MW	¥	µ	Å	Õ	å	õ
-6	SSA	SPA	¶	¦	Æ	Ö	æ	ö
-7	ESA	EPA	§	·	Ç	×	ç	÷
-8	HTS	SOS	¨	¸	È	Ø	è	ø
-9	HTJ	SGCI	©	¹	É	Ù	é	ù
-A	VTS	SCI	ª	º	Ê	Ú	ê	ú
-B	PLD	CSI	«	»	Ë	Û	ë	û
-C	PLU	ST	¬	¼	Ì	Ü	ì	ü
-D	RI	OSC		½	Í	Ý	í	ý
-E	SS2	PM	®	¾	Î	Þ	î	þ
-F	SS3	APC	¯	¿	Ï	ß	ï	ÿ

L’emploi des ces normes reste délicate et ambiguë, car à un même code caractère peuvent correspondre plusieurs caractères différents suivant que le document est saisie en ISO-Latin-1 ou, par exemple, en ISO-Latin-5. La lecture d’un fichier saisie en ISO-8859-x suppose donc que l’on connaisse le numéro (x) de cette norme (de 1 à n) pour savoir à quel caractère un code fait référence. Il faut donc que cette information figure dans le document. Mais les systèmes qui permettent d’indiquer cette valeur associent souvent celle-ci au document dans sa globalité, ce qui empêche la saisie de documents multilingues. Le langage HTML, par exemple, permet de saisir des documents avec toutes ces normes et même d’autres. La déclaration se fait dans la partie entête du document :

<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
</HEAD>

Cette déclaration reste valable pour l’ensemble du document. A titre d’exemple, un caractère à la position décimale 143 sera donc interprété comme :

soit un 'ê' c’est à dire le caractère 'LATIN SMALL LETTER E WITH CIRCUMFLEX' si on a déclaré le code caractère ISO-8859-1

soit un '' c’est à dire 'CYRILLIC CAPITAL LETTER SHCHA' si on a déclaré le code ISO-8859-5 correspondant au cyrillique.

Les langages de balisage de texte comme HTML, mais plus encore les langages génériques comme SGML (Standard Generalized Markup Language) et XML (Extensible Markup Language) procurent un mécanisme (les entités) qui permet d’utiliser des caractères qui seraient sinon inaccessibles, lors de leur saisie avec de simples éditeurs ASCII. Les entités sont des suites de caractères délimités par des marques de début d’entité '&' et de fin d’entité ';'. La suite de caractères, comprise entre ces limites, représente soit la place du caractère dans son code, soit le nom logique du caractère. Ce nom devra être défini par ailleurs (dans la DTD Document Type Definition). Ainsi notre 'ê' de l’ISO-Latin-1 peut être saisi avec un simple éditeur ASCII en :

ê nom standardisé ISO-8879 :1986 qui doit être déclarée, par exemple, dans la DTD de HTML

 place (en hexadécimal) que le caractère occupe dans le code

 place (en décimal) que le caractère occupe dans le code

Mais même avec l’aide d’un outil qui permettrait de changer l’encodage des caractères en cours de document, certains systèmes d’écriture comme les syllabaires japonais ou les idéogrammes chinois demeurent des systèmes utilisant beaucoup trop de positions pour être stockés dans des codes à 256 places. C’est afin de palier à ce manque de place pour coder les caractères de ces différents systèmes d’écriture que de nouvelles normes ont vu le jour.

Il est à noter qu’à ce jour les plus importantes plates-formes micros (PC et Macintosh ~ Windows, DOS, MacOS, Unix...) ont toutes adopté la norme ASCII, mais aucune n’utilise réellement les normes ISO-Latin. De plus, les choix de standard divergent (par exemple le jeu de caractères de MS-Windows correspond à l’ISO-Latin1 sauf qu’il a utilisé la place laissée par les caractères de contrôle de 128 à 159 pour y mettre des caractères graphiques). Les gros systèmes IBM quant à eux sont restés avec leur codage propriétaire (EBCDIC).

>L’UNICODE

Le Consortium Unicode est un regroupement de constructeurs d’ordinateurs créé en 1989. Il a défini une norme de codage pour la majeure partie des caractères utilisés dans le monde. Il s’agit cette fois d’un codage sur 2 octets, ce qui offre la possibilité de disposer théoriquement de 2¹⁶, soit plus de 65000 caractères. Comme à l’habitude, les 128 premiers caractères sont ceux de l’ISO-646 IRV et pour assurer la compatibilité avec les normes existantes, les 256 premiers caractères sont ceux de l’ISO-Latin-1 (à la différence près qui existe entre US-ASCII et ISO-646 IRV).

0	128	256	65536
			positions
ISO-646 IRV
ISO-8859-1
UNICODE

Unicode ne définit à ce jour (version 2.1), de valeur de caractère que pour environ la moitié des codes caractères théoriquement disponibles. Il est déjà composé d’un grand nombre d’écritures. Nous citerons à titre d’illustration :

Plage des positions en hexadécimal	alphabets
`0401 à 04CC`	le cyrillique
`05B0 à 05F4`	l’hébreu
`0970 à 09FA`	le bengali
`3041 à 309E`	le syllabaire japonais hiragana
`30A1 à 30FE et 32D0 à 32FE`	le syllabaire japonais katakana
`2100 à 2182 et 2200 à 22F1`	les symboles mathématiques
`0250 à 02AF`	l’Alphabet Phonétique International (API)répartis en fait dans les alphabets : Basic Latin,Latin-1 Supplement, Latin Extended-A, Latin Extended-B, IPA Extensions (0250 à 02AF), Spacing Modifier Letters, Combining Diacritical Marks
`4E00 à E000`	les idéogrammes d’origine chinoise utilisés pour le chinois, le coréen et le japonais (le codage a utilisé un schéma appelé " unification Hun " pour réduire le nombre de caractères)
	de nombreux autres alphabets...

Ce type de codage de caractère possède l’avantage de permettre la saisie de textes multilingues et de passer d’un système d’écriture à un autre sans problèmes. De plus il est non ambigu c’est à dire qu’à un code caractère ne peut correspondre qu’un seul caractère. Nous citerons aussi au titre des avantages la réapparition des caractères ligaturés perdus lors de la création de l’ISO-Latin-1, c’est à dire les caractères 'œ' (position hexadécimal 0153), 'Œ' (position hexadécimal 0152) et le caractère 'ÿ' majuscule (position hexadécimal 0178).

Il demeure pour l’instant encore quelques réticences à utiliser une telle norme. Par exemple : le choix fait par Unicode pour la codification des tons n’est pas partagé par tous les transcripteurs. Certains alphabets ne sont pas encore normalisés comme le Birman (en cours de normalisation), voir même ne le seront jamais. Le fait que les caractères phonétiques doivent être piochés soit dans les jeux de caractères propres à l’API soit dans d’autres alphabets rend cette codification relativement ambiguë contrairement à son objectif. Par exemple la saisie d’un 'a' latin ('LATIN SMALL LETTER A') pour noter le 'a' de l’API (

'OPEN FRONT UNROUNDED
VOWEL'

) peut poser des problèmes lors d’une édition car il peut y avoir confusion entre le 'a' Latin italique (glyphe: a) et le 'a' de l’API (

'LOW BACK UNROUNDED
VOWEL'

) de même glyphe. Le a rond italique est une norme typographique qui peut s’appliquer au 'a' du latin et non à celui de l’API sous peine de confusions gênantes.

Un autre frein plus important à l’utilisation d’Unicode, est le manque d’outils sachant gérer les caractères sur plus d’un octet. Nous pouvons citer tout de même au nombre des implémentations d’Unicode : le langage JAVA, le système MS-Windows NT, tous les outils tournant autour du langage de balisage de texte XML, l’éditeur de texte MS-Word, les navigateurs Web, et quelques autres outils. Mais le problème de la saisie des textes reste omniprésent dans les rares outils d’édition, et comme des claviers à 65000 touches restent improbables, les interfaces se font attendre. Bien sûr, il reste toujours la possibilité de saisir des textes structurés avec des langages de balisage de texte pour utiliser le mécanisme des entités. D’autres normes comme RTF ou TeX utilisent aussi un mécanisme équivalent à celui des entités, mais certainement pas plus convivial. Par exemple le glyphe é s’écrira \'e avec TeX et \'e9 avec RTF .

>L’ISO/IEC 10646

    Une dernière norme de codage que l’on ne fera que citer brièvement est la norme ISO/IEC 10646. C’est une norme de codage sur 4 octets, et qui permet de définir théoriquement 2³² positions, soit plus de 4 milliards de caractères possibles. On décompose ce code caractère en 256 groupes (1er octet) de 256 plans (2ème octet) de 256 rangées (3ème octet) de 256 cellules (4ème octet). Pour l’instant seul le plan 00 du groupe 00 est défini. Il correspond à l’Unicode et est appelé BMP (Basic Multilingual Plane).

    Cette norme définit aussi plusieurs types de codage sur plusieurs octets UCS (Universal Multiple-Octet Coded Character Set) appelés UCS-4 pour un codage sur 4 octets, et UCS-2 pour un codage sur 2 octets, permettant de coder tous les caractères Unicode (plan BMP).

    Un codage avec UCS-4 est très gourmand en place, car il stocke tous les caractères sur 4 octets, même si les deux premiers octets sont systématiquement à zéro, (puisque seuls les caractères du plan 00 du groupe 00 existent à l’heure actuelle). Un codage de type UCS-2 est donc pour l’instant largement suffisant. Mais même ainsi le codage de textes latin ou à forte composante latine en UCS-2 conduit à gonfler les fichiers car la plupart des caractères utilisés sont dans la partie correspondant à l’ISO-Latin-1 voir même à l’ISO-646 et donc laissent le premier octet à zéro. Ces caractères pourraient être stockés sur un seul octet, c’est pourquoi plusieurs formats de transformation UTF (UCF Transformation Format) ont été créés afin d’alléger les fichiers, de faciliter la transmission des données et de maintenir une compatibilité avec les anciens systèmes d’édition.

    Il existe plusieurs formats de transformation suivant le nombre de bits que l’on va utiliser : UTF-16, UTF-8, UTF-7. Par exemple UTF-8 (UCS Transformation format 8-Bits) permet d’exprimer tous les caractères l’ASCII (de 32 à 127) sur 1 seul octet, la plupart des caractères non-idéographiques sont codés sur 2 et le reste des caractères Unicode sont codés sur 3 octets (le premier octet indique le nombre d’octets sur lesquels le caractère est codé). Enfin les « surrogate pairs » utilisés par Unicode pour représenter les caractères en dehors du plan multilingue (BMP), sont codés sur 4 octets.

>Tableau des correspondances UCS-2 vs UTF-8

UCS-2	UTF-8
valeur Unicode	1er octet	2ème octet	3ème octet	4ème octet
`000000000xxxxxxx`	`0xxxxxxx`
`00000yyyyyxxxxxx`	`110yyyyy`	`10xxxxxx`
`00000yyyyyxxxxxx`	`1110zzzz`	`10yyyyyy`	10xxxxxx
`110110wwwwzzzzyy +110111yyyyxxxxxx`	`11110uuu* * où uuuuu = wwwww + 1`	`10uuzzzz`	`10yyyyyy`	`10xxxxxx`

>Exemple de script PERL pour la transformation d’un encodage UTF-8 en ISO-Latin-1 quand c’est possible, sinon sous forme d’entité décimale

while ($line = <STDIN>) {
	$line = &UTF8toENTITY ($line);
	print $line;
}
#------------------------------------------------------------------
sub UTF8toENTITY {
	my $line = shift;
	my $result = "";
	my $size = length($line);
	for ($i=0; $i<length($line); $i++) {
		my $car = substr($line, $i, 1);
		my $val = ord($car);
		if ($val >= 128) {	# codage sur 2 octets
			if ($val < 224) {
				my $car2 = substr($line, ++$i, 1);
				$car = &convert2($car, $car2);
			} else  {               # codage sur 3 octets
				my $car2 = substr($line, ++$i, 1);
				my $car3 = substr($line, ++$i, 1);
				$car = &convert3($car, $car2, $car3);
			}
		}
		$result = $result.$car;
	}
	return $result;
}
#------------------------------------------------------------------
sub convert2 {
	my($car, $car2) = @_;
	my $val2 = ord($car2) - 128;
	my $val  = (ord($car) - 192) << 6;
	my $result = $val + $val2;
	if ($result < 256) {
		return chr($result);
	} else
		return "&#$result;";
	}
}
#------------------------------------------------------------------
sub convert3 {
	my($car, $car2, $car3) = @_;
	my $val3 = ord($car3) - 128;
	my $val2 = (ord($car2) - 128) << 6;
	my $val  = (ord($car) - 224) << 12;
	my $result = $val + $val2 + $val3;
	return "&#$result;";
}
#------------------------------------------------------------------

>Résultats du script :

entrée UTF-8: La sÅ"ur aÃ®nÃ©e le remonta Ã son tour
sortie ISO-Latin-1: La s&#339;ur aînée le remonta à son tour

à noter la ligature œ définie dans Unicode mais pas en ISO-Latin.

>Conclusion

La norme ISO/IEC 10646 semble résoudre un certain nombre des problèmes qui se posent actuellement pour le codage et l’échange de documents. Cette norme n’entraîne pas de surcharge pondérale dans les fichiers, puisqu’il existe, nous l’avons vu, plusieurs manières de coder les caractères en fonction des besoins. Par contre, une telle norme nécessite la maîtrise d’une couche supplémentaire, d’un langage de description de document de haut niveau. De tels langages existent et implémentent déjà cette norme. Il s’agit des langages de balisage de document tels que SGML ou XML... mais ceci est une autre histoire. D’autres langages comme TeX ou RTF permettent, eux aussi, d’adresser les caractères du plan multilingue, qui de toute façon sont pour l’instant les seuls à être définis.

En guise de conclusion, je dirais que si l’on veut échanger des documents, et plus généralement si l’on souhaite communiquer, nous avons besoin de définir un langage commun. La normalisation des codes caractères n’est qu’un aspect de ce langage commun, mais sans celle-ci nous retournons à l’âge de l’imprimerie, et alors tous les beaux outils de informatique créés pour automatiser ou faciliter des tâches laborieuses (recherches, édition, transformations, etc.) sont à mettre au panier, et nous pouvons retourner à nos bouliers et à nos fiches bristol. La normalisation est aussi un outil contre la dialectisation, au prix parfois d’un appauvrissement de l’expression. Alors si l’on doit utiliser des normes pour coder et échanger des documents autant utiliser les normes les plus riches pour que la perte soit la plus limitée possible. Le caractère public et ouvert des normes est aussi un bon indicateur de pérennité. Et c’est bien ce que nous cherchons tous : exprimer le plus possible, pouvoir s’échanger cette information sans perte, et enfin que la trace de cette information dure dans le temps.

>Liens

Site web du Consortium Unicode (LIEN)

Jacques ANDRÉ et Michel GOOSSENS "Codage des caractères et multi-linguisme: de l'ASCII à Unicode et ISO/IEC-10646" Les cahiers de GUTenberg n°20, mai 1995. (LIEN)

Jacques ANDRÉ "ISO Latin-A, norme de codage des caractères européens? trois caractères français en sont absents!" Les cahiers de GUTenberg n°25, nov 1996. (LIEN)

Tony GRAHAM "Unicode: What is it and how do I use it?" Markup Technologies '98. (LIEN)

Cet article est la propriété de Michel Jacobson. La copie et la diffusion sont libres sauf dans un but lucratif sans accord explicite de l'auteur.