L'un des meilleurs moyens de comprendre le format d'un fichier est d'ouvrir ce fichier bien sûr. Mais pas avec le logiciel qui est utilisé d'habitude pour lire votre fichier. Non, utilisez un éditeur hexadécimal. C'est quelque chose qui vous dit octet par octet ce qu'il y a dans votre fichier. Il ne faut pas avoir peur !!! :)

En fait un logiciel quelconque (ex : lecteur mp3, visionneuse d'images, ...) lit toujours un fichier octet par octet. Sauf qu'il traduit ces octets en quelque chose (de la musique, une image, ...). C'est pour ça que les octets doivent être toujours dans le même "ordre", respecter le même format : pour que les logiciels sachent comment lire l'information au travers des innombrables octets d'un fichier.

Exemple

Créez avec un logiciel de dessin un petit carré rouge de 5 pixels sur 5 pixels, un autre petit carré rouge de 6*7 et un petit carré vert 5*5. Enregistrez en *.bmp. Ouvrez ces fichiers avec un éditeur hexadécimal pour lire les octets, et regardons les différences, ou plutôt les ressemblances !
Comme la maison ne recule devant aucun sacrifice, elle vous propose ses copies d'écran :)

Dans l'ordre, rouge 6*7, rouge 5*5 et vert 5*5 :

Lecture d'un fichier hexa

Il y a en fait 3 tableaux sur chaque image : celui de gauche (0000000, 0000010, 00000020, ...), celui tout à droite (BM......., .......) et celui du milieu, de 16 colonnes (ici subdivisé en 4 sous colonnes).

Les nombres sur le deuxième tableau sont les valeurs des octets du fichier, en notation hexadécimale, un peu déroutante au début je vous l'accorde. Ainsi si vous pouviez regarder sur le disque dur avec une loupe et mesurer le magnétisme des bits (et additionner ça pour en faire des octets), vous verriez exactement ces informations là. Comme je le disais, c'est au logiciel de lire ça et de le transformer en une image, un film, un texte, ...

Ce deuxième tableau a 16 colonnes. Mais si l'on veut savoir que vaut l'octet 43 on ne va pas compter un à un jusqu'à 43. 43 = 2 * 16 + 11 (= 2B en hexa), donc on va à la 3eme ligne, et on regarde le onzième octet de cette ligne.

Les lignes sont donc numérotées à gauche (les fichiers ont souvent des milliers de lignes).

Le tableau de droite correspond à la retranscription pure des octets en lettres. Il y a en effet des tas de caractères (chiffres, lettres, ? " # @ ...) et tout est numéroté. A porte le numéro 65, B : 66, C : 67... a : 97, b : 98, ... C'est ce qui se passe quand on écrit du texte. Et bien là c'est ça. L'éditeur hexadécimal essaye de calquer les octets en lettres. Ainsi si vous ouvrez un vrai fichier texte avec l'éditeur hexadécimal, vous pouvez contempler votre prose sur le tableau de droite.
En pratique, il ne sert pas beaucoup.

Interprétation

Sans tomber dans la redéfinition du format bmp, on voit que les premiers octets sont quasiment tous pareils pour les 3 fichiers, et que les 2 premiers sont "BM" (comme 'bmp' !! whouaouh trop fort !)
Normalement c'est dans ces premiers octets qu'apparaissent la longueur puis la largeur de l'image (en pixels) entre autres choses. Tout ceci s'appelle l'en-tête.
En effet, pour le 5*5 rouge et le 5*5 vert, les 3 premières lignes + les 6 premiers octets sont exactement identiques. Ce n'est pas un hasard, non ?

Les couleurs viennent après. 11 1F E0 pour le rouge (avec du 10 qui s'intercalle tous les 5 'EO'), et 6B 2C FA pour le vert (et du 10 qui s'intercalle aussi). On en déduit que 11 1F EO est le code du rouge (d'ailleurs on le retrouve pour le 6*7 rouge) et que 10 doit signifier quelque chose comme "ligne finie".

Le fichier de 6*7 est un peu plus compliqué on dirait, mais son en-tête reste la même à un ou deux octets près. Youpi, cela veut dire que là où ça change est surement là où sont codées longueur et largeur ! Il faudra donc regarder attentivement.
Puis vient encore le dessin : il y a écrit de gauche à droite et de haut en bas exactement les couleurs des pixels du dessin.
On pourrait remplacer un des nombres pour voir ce que ça fait et vérifier nos dires.

Par contre on ne retrouve plus le '10' une fois sur 5 qui semblait marquer la fin d'une ligne, mais on vois '01 00' à la place, une fois sur 6. Pour une image qui a 6 lignes, c'est ok mais franchement je ne vois pas comment expliquer le fait qu'ils n'utilisent pas le même code pour dire "fin de la ligne, début de la nouvelle". Il faudrait d'autres fichiers.

En ce qui concerne les dimensions on regarde ce qu'il y a de différent entre l'en-tête de rouge 5*5 et rouge 6*7. Il y a plusieurs octets différents :

• l'octet n°3 : 86 pour l'image 5*5 et C2 pour 6*7
• l'octet n°19 (= le 3eme de la 2eme ligne) : 5 pour 5*5 et 6 pour 6*7 (!!!)
• l'octet n°23 : FB pour 5*5 et F9 pour 6*7

A priori, l'octet n° 19 indique donc le nombre de lignes de l'image, ça a l'air ok.
En ce qui est de l'octet n°3 (86 et de C2), regardez la numérotation des lignes sur le tableau de gauche. Et surprise... oui ! c'est ça. Le 3ème octet indique donc la taille de l'image, en octets. Comme taille de l'image = taille de l'entete + 3 * nbre de lignes * nb de colonnes, on retrouve donc le nb de colonnes.
* 3 parce qu'on a vu que les couleurs étaient 3 octets de suite (11 1F EO pour rouge et 6B 2C FA pour le vert), ce qui correspond bien à un code RGB (red green blue).
Seulement, mystère, on n'a pas pris en compte la taille du 'séparateur' (10 pour le 5*5 et 01 00 pour le 6*7). Comment faire ?? Je sèche. L'information doit être dans l'octet 23 a priori mais je ne vois pas comment. Enfin bon, j'espère que vous avez compris le principe et que ça vous a donné l'eau à la bouche ! ^^

Pour info, pourquoi une en-tête si longue alors qu'on a juste besoin de largeur et longueur ? Parce qu'une image bitmap peut aussi livrée avec une "palette" normalement, et on utilise que 16 couleurs (pour stocker l'info sur 1 octet au lieu de 3) mais du coup il faut préciser ces 16 couleurs, et cela se fait dans l'en-tête.

Ca y'est ! Vous comprenez maintenant ce que veux dire "organisation de l'information dans un fichier".

Télécharger un éditeur hexadécimal

Les éditeurs de ce type se valent tous plus ou moins. Je vous conseille cependant de toujours faire la copie d'un fichier avant de travailler dessus, même juste pour regarder ses entrailles. Une erreur est vite arrivée !

• Pour Mac : HexEdit
• Pour Windows : HexEdit
• Pour Linux : démerdez-vous. C'est bien pour ça que vous êtes passés à Linux, non ? ^^

Autres articles

Accusé de réception / Email read notification Activer l'accusé de réception dans Mail. Activate the email read notification in Mail.
Latex Utiliser Latex avec XCode Write Latex with XCode
Copier un énorme fichier sur Mac OS X Comment copier un gros fichier sur votre disque dur How to copy big files to a hard drive
Comment jouer un son en javascript / How to play a sound with javascript In French and English
Fichiers Wav Format, spécifications et code source C++ générant un .wav
Couleurs Fonctionnement des couleurs sur un ordinateur, et transformation HLS<->RGB
	La patrie du hamburger Quête vers le Saint Graal
	Tokyo Dome Avec en prime un cadeau vidéo :)
	San Francisco balade en vélo
	Sierra Nevada road trip encore plus à l'américaine que d'habitude
	10 jours dédiés au Guatemala A la rencontre des familles mayas
	Le Japon et les Japonais Quelques préjugés tombent
	Driving license Un pas de plus vers la citoyenneté américaine !
	Exposition Hugo Pratt à la pinacothèque
	Les restaurants japonais La découverte de Tokyo au travers de ses restos
Enigme Un petit remue-méninges...
	Los Angeles La ville de tous les vices.
	4 jours en Alaska Je m'en irai dormir dans le paradis blanc
	Halte aux envahisseurs Si ça peut vous rappeler votre enfance...
	Les coulisses du CES 2016 Exposer au CES pour la French Tech pour la première fois
	Configurer ses sauvegardes Du bon usage de DropBox, disques durs externes, des gestionnaires...
Ingrid Bettancourt Parle t'on trop d'elle ?
	Baba cool Voyager autrement
	Foxconn la surprise dévoilée