Site d’informations sur les formats numériques

Auteur Message
S’il vous arrive d’avoir besoin des spécifications officielles ou non d’un format numérique, ce site peut vous intéresser : www.digitalpreservation.gov.

Le lien ci‑dessus est la page d’accueil, les deux points d’entrés les plus intéressants sont :


Les informations fournies pour chaque formats sont assez détaillées (techniques, qualitatives, légales, …), et je n’avais jamais vu ça avant.

Quand la source de la spécification d’un format le permet, un lien vers la spécification officielle est fourni. Dans le cas contraire et quand cela est possible, un lien vers des documentations rédigées par des sources non‑officielles, leur sont substitués.

Je suis tombé sur ce site en voulant me renseigner sur le format MS Bitmap version 5.

— Édit du 2025-12-28 —

Aussi : Let's Document all the File Formats! (fileformats.archiveteam.org).

Les choix d’une bibliothèque universitaire en Suisse, concernant les formats a préférer pour la préservation sur le long terme : Data management toolbox: File formats for long-term preservation and re-use (guides.bium.ch).

— Édit du 2026-01-01 —

La base de données PRONOM semble connue de tous les gens qui sont concernés par les formats numériques et la pérennité des supports : PRONOM Search by format (nationalarchives.gov.uk). Seulement entrer une extension de fichiers dans ce formulaire, fait des miracles et vaut des heures de recherche sur le web (et sans IA, preuve qu’une forme d’organisation appropriée est ce dont on a le plus besoin).

Le site d’un langage de description des formats de données, nommé Kaitai : kaitai.io. C’est un langage qui se compile dans divers langage source, incluant le C, JavaScript et Rust, entre autres, mais il peut aussi être vu comme un langage de description vérifié, puisque que compilable. Il a des avantages et des limitations. Son avantage et de s’appliquer à beaucoup de formats, de penser à la documentation et à la source des références utilisées. Il a des limitations. La page qui décrit le format des fichiers MIDI, précise que les runnings status ne sont pas supportés, parce que leur interprétation n’est apparemment pas trivial à décrire dans ce langage qui décrit des choses statiques. C’est peut‑être la raison pour laquelle HTTP par exemple ne figure pas dans la galerie des formats décrits, alors qu’il a été l’une des premières choses décrites dans un langage logique nommé Twelf, qui a fini à l’abandon, faute d’investissements dans tous les sens du mot. Pour la même raison, il faudrait savoir s’il est approprié pour définir des récupérations en cas d’erreur de format, ce qui n’est pas si rare. Quoiqu’il en soit, ce langage qui est une idée de génie, a un site qui mérite sa place parmi les références dans le premier message de ce sujet.
Une liste de langages de balisages, couvrant des domaines variés, de la physique à la musique : The Physical Markup Language — Standards (mit.edu).

Ne pas s’arrêter sur le titre du site, cette section de ce site présente bien une liste multi‑domaine, de standards effectivement utilisés.
Pour la documentation sur le format RIFF et autres basés sur ce format, comme WAV, il faut chercher sur le web, le fichier RIFFMCI.TXT ou RIFFMCI.RTF (exemple de site web plus loin), et vraiment éviter le fichier RIFFMCI.PDF, qui est erroné. Le PDF affiche des choses en double rapportées n’importe où tandis qu’il en omet d’autres. Avec RIFFMCI.TXT, quelques caractères s’affichent mal parce qu’ils sont probablement d’une ancienne page de code Windows, mais mieux vaut le fichier TXT que le PDF. En tous cas, le caractère « Ý » doit être lu comme une flèche vers la droite, genre « ‑> ». Les FormFeed qui s’affichent peut‑être comme FF dans votre visionneuse texte, n’en font pas partie, ce sont des caractères de contrôle ; c’est mieux de ne pas les supprimer, de garder l’original intacte, parce que ce fichier texte est plus l’original que le PDF, mais probable que le vrai original soit un fichier RTF. Édit : oui, voir plus loin.

Même si le RTF, plus bas, est encore préférable au TXT, le TXT peut être récupéré depuis cette page quand‑même intéressante par ailleurs : Vertrauen Computer sound programs (synchro.net). Récupérer l’archive nommée RIFFWAVE.ZIP, la décompresser ; elle contient plusieurs fichiers, dont RIFFMCI.TXT. Le fichier README.DOC qu’elle contient aussi, n’est pas un fichier Word, c’est un fichier texte ordinaire.

En effet, le RTF est bien le document d’origine. Il a quasiment disparu du web, ne peut pas être retrouvé avec Google, mais avec Bing on peut trouver cette page : Topic: RIFF specs (hydrogenaudio.org), 18 Juillet 2004. Au cas où cette source disparaîtrait aussi, en voici une copie zipée : riffmci.rtf.zip (les-ziboux.rasama.org). Le flèche allant vers la droite, mentionné précédemment, ne s’affiche pas correctement sur AbiWord au moins, qui affiche à la place 279D, ce qui désigne le caractère Unicode U+279D, qui est bien celui de cette flèche. Peut‑être que c’est spécifique à cette liseuse RTF. En l’absence de visionneuse RTF, le fichier TXT est suffisant, il contient la même chose, à un mauvais caractère près.

Édit : sous réserve que ce ne soit pas seulement une erreur de la liseuses RTF utilisé, il y a une omission dans le RTF et le TXT, qui omettent la formule wChannels x wBitsPerSecond x (wBitsPerSample / 8) et une autre seconde formule, qui n’apparaissent que dans le PDF. Le mieux est finalement de garder les trois et de vérifier les autres quand il manque visiblement quelque chose ou qu’une chose semble étrange.

À la suite de RIFFMCI.RTF qui date de 1991, il y a eu en 1994, un fichier nommé RIFFNEW.PDF. Il reste facile à trouver et cette fois, le PDF est le document d’origine, comme le laisse voir l’entête.

Voir le message « Re: Le format WAVE » pour une suite concernant un détail sur les fichiers RIFF, même s’il concerne surtout les fichiers WAVE, qui sont un cas de fichier RIFF.
Une liste de sections des fichiers RIFF, qui ont été définies extérieurement, c’est à dire qui ne sont pas définies dans les documentations sur le format RIFF. Avec un bémol pour mieux lire, juste après : RIFF Tags (exiftool.org). Ce ne sont pas des tags, mais des chunks, mais ce n’est pas grave, c’est le site de EXIFTools. Il faut juste faire attention en lisant le tableau : il est écrit par exemple 'LIST_exif' quand il faudrait lire “ LIST (exif <…>) ”. Les noms des chunks ne peuvent être que sur 4 caractères au plus ; dans cet exemple, c’est en fait ce qui est appelé une form, dans la terminologie RIFF, exactement une LIST form exif. Idem pour le reste. Ces petites erreurs pourraient laisser penser que la page n’est pas sérieuse, alors qu’elle l’est. Les formats des chunks sont décrits plus bas dans la page. Attention aussi à une LIST form qui est appelée Tdat. Normalement, ce nom n’est pas correcte, parce que les noms sont soit en minuscules soit en majuscules, avec éventuellement des digits décimaux. Les noms en majuscules sont ceux qui sont répertoriés, ceux en minuscules ne le sont pas ou sont locaux à une forme. Les lecteurs RIFF validants peuvent devoir faire attention à ce cas particulier.

Ce qui ne passe pas inaperçu, est qu’il existe apparemment un standard de fait pour ajouter des tags ID3 dans les fichiers RIFF.