Encodage des fichiers texte

On a déjà parlé de ASCII et Unicode – cours sur chaînes de caractères. Allons un peu plus loin en examinant les fichiers de texte.

Reconnaître un fichier texte

Un fichier en mémoire est une suite de bits, ou si on veut une suite d'octets.

Ces octets peuvent signifier n'importe quoi. On ne sait pas forcément ce qu'ils représentent à priori. Il nous faut des indices :

Le fichier peut avoir une extension. Le format .txt sous Windows indique qu'il s'agit d'un fichier texte.
Chaque octet représente un caractère selon le codage ANSI de Windows, compatible avec ASCII.
Mais cet indice ne constitue pas une preuve !
Exercice : modifier l'extension
Si on renomme en monimage.doc, l'ouverture avec Word ne fonctionnera pas.
En effet, .doc est un format plus compliqué contenant un certain nombre d'informations placées d'une certaine façon. Si les données ne correspondent pas à ce qui est attendu, Word retourne une erreur.

On peut donc analyser le fichier selon plusieurs format connus et ne conserver que les formats compatibles.

Les encodages

Supposons que l'on ait un fichier texte, un fichier simple, contenant seulement la suite des caractères.

Donc ni un fichier '.doc' ni un fichier '.pdf' par exemple.

Il s'agit maintenant de savoir comment lire ces octets. Doit-on les considérer un par un ? par groupe de deux ? etc. Il n'y a pas un seul choix possible !

Il y a une histoire qui a vu les systèmes se complexifier à mesure que les performances le permettaient.
Il y a une inertie importante : un choix ancien – comme ASCII – demeure simplement pour assurer la compatibilité avec ce qui existe déjà et que l'inertie est parfois importante.
Différentes entreprises concurrentes tentent d'imposer leurs choix.
Des situations différentes peuvent entraîner des besoins différents et donc des choix différents.
Quand l'informatique ne concernait que les USA, ASCII suffisait. Mais aujourd'hui, il faut tenir compte de la grande diversité des systèmes d'écriture.

Avec internet, les échanges de fichiers deviennent mondiaux. De plus certains fichiers restent accessibles pendant très longtemps. Le problème de l'encodage est donc très important.

ASCII

Déjà mentionné, 128 caractères sans accent, donc 7 bits par caractère.

Dans les fait on utilise plutôt un des codages suivants qui sont compatibles avec ASCII si bien qu'on n'utilise jamais moins d'un octet par caractère.

ISO 8859-1

Latin-1 = Europe occidentale [1986]

Ajoute des caractères accentués à ASCII. Suffit pour le français.

	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF
0x	NUL	SOH	STX	ETX	EOT	ENQ	ACK	BEL	BS	HT	LF	VT	FF	CR	SO	SI
1x	DLE	DC1	DC2	DC3	DC4	NAK	SYN	ETB	CAN	EM	SUB	ESC	FS	GS	RS	US
2x	SP	!	“	#	$	%	&	'	(	)	*	+	,	-	.	/
3x	0	1	2	3	4	5	6	7	8	9	:	;	<	=	>	?
4x	@	A	B	C	D	E	F	G	H	I	J	K	L	M	N	O
5x	P	Q	R	S	T	U	V	W	X	Y	Z	[	\	]	^	_
6x	`	a	b	c	d	e	f	g	h	i	j	k	l	m	n	o
7x	p	q	r	s	t	u	v	w	x	y	z	{	\|	}	~	DEL
8x	PAD	HOP	BPH	NBH	IND	NEL	SSA	ESA	HTS	HTJ	VTS	PLD	PLU	RI	SS2	SS3
9x	DCS	PU1	PU2	STS	CCH	MW	SPA	EPA	SOS	SGCI	SCI	CSI	ST	OSC	PM	APC
Ax	NBSP	¡	¢	£	¤	¥	¦	§	¨	©	ª	«	¬	-	®	¯
Bx	°	±	²	³	´	µ	¶	·	¸	¹	º	»	¼	½	¾	¿
Cx	À	Á	Â	Ã	Ä	Å	Æ	Ç	È	É	Ê	Ë	Ì	Í	Î	Ï
Dx	Ð	Ñ	Ò	Ó	Ô	Õ	Ö	×	Ø	Ù	Ú	Û	Ü	Ý	Þ	ß
Ex	à	á	â	ã	ä	å	æ	ç	è	é	ê	ë	ì	í	î	ï
Fx	ð	ñ	ò	ó	ô	õ	ö	÷	ø	ù	ú	û	ü	ý	þ	ÿ

On retrouve les HT, LF, CR et SP de ASCII. Parmi les nouveaux, notons NBSP pour Non Beakable SPace, espace insécable, noté   en code HTML.

Tend à disparaître au profit d'UTF-8. Pas plus de 10 % d'utilisation.

ANSI

Windows-1252 ou CP1252

C'est un codage Windows, très proche de ISO 8859-1.

ANSI se contente de remplacer certains codes de contrôles – octets ne correspondant pas à un caractère affichable – par des caractères.

UTF8

Universal character set Transformation Set - 8 bits

C'est un codage fait pour utiliser Unicode mais en allégeant un peu.

Avec UTF-8, selon les cas, un caractère peut-être codé sur 1, 2 ou 4 octets.

Quand c'est un caractère ASCII, il ne prend qu'un octet. Ainsi, un fichier en ASCII est parfaitement compatible avec UTF-8. Être compatible ASCII est quasiment obligatoire.
Un caractère comme é va être encodé par deux octets : 0xC3 A9.
L'encodage est fait pour que l'on sache à chaque fois combien on devra lire d'octets pour le prochain caractère.

Je donne ici un peu plus de détails. C'est optionnel, vous pouvez ignorer ces détails si vous n'êtes pas intéressés.

Quand l'octet commence par 0, UTF8 considère que la fin de l'octet, les 7 bits restants, codent un caractère ASCII.
Quand l'octet commence par 110, UTF8 comprend que le prochain caractère utilisera deux octets, celui-ci et le suivant. L'octet suivant devra commencer par 10, sinon ce sera une erreur.
Par exemple, le caractère é :
- é est codé en UTF8 0x C3 A9 = 0b 1100 0011 1010 1001
- Le premier des deux octets commence bien par 110 et le second par 10.
- Quand on enlève ces codes 110 et 10 (je mets des _ à la place) il reste ___00 0011 __10 1001 ce qui correspond au é en unicode : 0xE9 = 1110 1001.
Il y a encore d'autres codes spéciaux pour des caractères plus rares.

Exercice : fonctions encode et decode

Reconnaître l'encodage

Pour éviter les problèmes, le mieux est d'indiquer d'une façon ou d'une autre le codage utilisé. Par exemple avec un fichier .html :

Le fichier .html est un fichier texte écrit avec un certain encodage xxx.
Dans le fichier .html on ajoute une balise <meta charset='xxx'> dans la partie <head>.

Ainsi le navigateur ouvrant la page reconnaît la balise <meta charset> – écrite uniquement en ASCII donc compatibles avec tous les encodages – et en déduit l'encodage à utiliser.

Rien n'empêche de s'amuser à enregistrer le fichier en ISO-8859-1 puis d'écrire <meta charset='utf-8'>. Le navigateur essaiera alors d'ouvrir le fichier avec l'encodage UTF8. Des caractères spéciaux indiqueront qu'il y a des caractères non reconnus.

Exercices : vérifier l'encodage