<figure><img src="image_127.png" /></figure>

## 4.31. ProRes (codec)

### Description

ProRes est un codec propriétaire de compression vidéo avec perte développé par Apple Inc. pour une utilisation en post-production (non pour la diffusion, donc) qui prend en charge toutes les résolutions, de la SD à la 8K. Il est le successeur de l'Apple Intermediate Codec et a été lancé en 2007 avec le logiciel de montage, Final Cut Studio 2.

Il offre un bon compromis entre qualité et compression.

### Sociabilité

Ce format est très répandu pour la post-production de contenus vidéo, notamment pour le cinéma, mais aussi pour les documentaires et autres programmes destinés à la télévision, particulièrement dans sa famille de profils 422. Quoique moins répandus, ses profils 4444 sont notamment utilisés pour la réalisation de publicités.

### Relations à d'autres formats

ProRes n'est que le codec de compression vidéo ; il est quasiment toujours embarqué dans un [conteneur QuickTime](https://www(138, 663, 563, 686],

### Versions

On distingue plusieurs profils du codec, introduits successivement par Apple. Les différences majeures entre les profils 422 et 4444 résident dans le débit (supérieur pour les profils 4444), la profondeur couleur (10 bits pour les profils 422, jusqu'à 12 bits pour les profils 4444, ce qui donne à ces derniers une plus grande précision dans la restitution des couleurs) et le sous-échantillonnage de la chrominance (4:2:2 pour les profils 422, 4:4:4 pour les profils 4444). Les profils sont les suivants, classés par niveau de qualité croissant :

- 422 Proxy ;

- 422 LT ;

- 422 ;

- 422 HQ ;

- 4444 ;

- 4444 XQ.

### Contenu

Le flux vidéo d'un fichier ProRes peut présenter toutes les tailles, de la SD (720x480 ou 720x576) à la 8K.

### Organisme de maintenance et documentation de référence

Le format n'est pas documenté à proprement parler, mais Apple a dévoilé une partie de sa structure interne dans un *white paper*.

En outre, le site Multimedia Wiki fournit quelques informations techniques.

### Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q47246311</td></tr><tr><td>Bibliothèque du Congrès</td><td>Famille des profils 422 : fdd000389</td></tr><tr><td>PRONOM</td><td>fmt/797</td></tr></tbody></table>

### Caractéristiques techniques

Ce codec fournit une compression avec perte mais celle-ci n'est pas visible à l'œil nu. La compacité du format dépendra essentiellement du profil, du nombre d'images par seconde (la cadence) et de la résolution. Dans le tableau suivant, on présente le poids estimé des fichiers selon ces paramètres. Les valeurs de ces paramètres sont
<figure><img src="image_128.png" /></figure>

limitées à celles déterminées pour le dépôt d'œuvres cinématographiques. Le poids est indicatif ; il pourra différer légèrement car le débit du flux vidéo ProRes est variable et en raison des caractéristiques du flux audio.

<table><thead><tr><th rowspan="2">Profil</th><th rowspan="2">Cadence en images par seconde</th><th colspan="2">Résolution 2K cinéma (2048 x 1080)</th><th colspan="2">Résolution 4K cinéma (4096 x 2160)</th></tr><tr><th>Débit</th><th>Poids estimé pour 1 heure</th><th>Débit (Mb/s)</th><th>Poids estimé pour 1 heure</th></tr></thead><tbody><tr><td rowspan="2">ProRes 422 LT</td><td>24</td><td>93 Mb/s</td><td>42 Go</td><td>350 Mb/s</td><td>157 Go</td></tr><tr><td>25</td><td>97 Mb/s</td><td>44 Go</td><td>365 Mb/s</td><td>164 Go</td></tr><tr><td rowspan="2">ProRes 422 HQ</td><td>24</td><td>201 Mb/s</td><td>91 Go</td><td>754 Mb/s</td><td>339 Go</td></tr><tr><td>25</td><td>210 Mb/s</td><td>94 Go</td><td>786 Mb/s</td><td>354 Go</td></tr><tr><td rowspan="2">ProRes 4444</td><td>24</td><td>302 Mb/s</td><td>136 Go</td><td>1131 Mb/s</td><td>509 Go</td></tr><tr><td>25</td><td>315 Mb/s</td><td>142 Go</td><td>1180 Mb/s</td><td>531 Go</td></tr></tbody></table>

Le format ProRes conserve suffisamment d'information pour permettre de réaliser le montage, d'où son poids relativement important (il n'est donc pas adapté à la diffusion).

## Métadonnées internes

Le codec ProRes ne porte pas de métadonnées descriptives ; celles-ci, lorsqu'elles existent, sont codées dans le format conteneur associé.

Les métadonnées techniques internes ne sont pas connues du fait du caractère propriétaire du codec.

## Outils connus par la BnF

Depuis 2008, le logiciel Quicktime dispose d'un décodeur gratuit permettant de lire les fichiers ProRes sur un système d'exploitation Windows ou Mac.

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo, qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7. Au 1er février 2021, la sortie MPEG-7 de l'outil MediaInfo ne contient pas toutes les métadonnées de caractérisation souhaitées par la BnF.

L'outil ffmpeg permet le décodage et la conversion de ce format vers des formats de diffusion, comme par exemple le MP4 H.264.

## Usage ou présence dans les collections de la BnF

Quelques exemples existent dans le cadre de dons numériques, actuellement dans le Système Audiovisuel de la BnF.

Des partenaires de la BnF (Centre Pompidou Virtuel, Centre National du Cinéma) reçoivent ou produisent ce format pour conserver des contenus audiovisuels nativement numériques.
<figure><img src="image_129.png" /></figure>

## 4.32. Quicktime File Format (MOV) (conteneur)

### Description

Le format MOV ou *QuickTime File Format* est un format conteneur pour des contenus multimédia. Créé en 1989 par Apple dans une perspective commerciale et de télédiffusion, il accompagnait le logiciel QuickTime de création et surtout de diffusion de vidéo. Il s'agit d'un format propriétaire maintenu par Apple (**CPO-LIB**), qui publie néanmoins ses spécifications (**CPO-DOC**).

Apple a utilisé l'intitulé « Quicktime Movie » pour désigner l'usage de ce conteneur pour embarquer des images animées, d'où l'extension majoritaire .mov, bien que l'on trouve également des fichiers qui portent l'extension .qt.

Ce format permet d'embarquer plusieurs pistes (*tracks*) qui peuvent contenir des données de plusieurs types : audio, vidéo, texte (en particulier, pour les sous-titres), *timecode*.

### Sociabilité

Ce format reste répandu dans la communauté des utilisateurs d'ordinateurs Macintosh (qui comprend en particulier les producteurs de vidéo) mais tend, en particulier pour la diffusion, à être remplacé par le MP4, dont il est à la base et qui dispose d'une norme. Il est de ce fait moins universellement géré que MP4, en particulier par les matériels : la Playstation Portable (PSP) et plusieurs lecteurs de DVD peuvent lire du MP4 mais non du MOV.

### Relations à d'autres formats

Le format MOV est la base du format conteneur MP4 version 1, défini dans la partie 1 de la norme MPEG-4 (ISO/IEC 14496-1:2001). La révision de cette partie de la norme donne naissance à la version 2 de MP4, publiée en 2003 dans la partie 14 de la norme (ISO/IEC 14496-14:2003). Par ailleurs, cette dernière est généralisée en 2004 pour créer la partie 12 (ISO/IEC 14496-12:2004, définissant l'ISO Base Media File Format, qui sert de base à d'autres codecs vidéo (MJPEG 2000, 3GP, etc.). La section 'History' de la page Wikipédia anglophone sur MPEG-4 part 12 donne plus de détails à ce sujet.

La structure des conteneurs MOV et MP4 est donc très similaire, mais certaines divergences font que ces deux formats ne sont pas interchangeables.

### Versions

Les spécifications de deux versions du format ont été rendues publiques par Apple :

- la version *classique* qui date de 2001 ;

- une version plus *moderne* mise à jour en 2012.

### Contenu

Un fichier au format MOV est constitué d'un arbre d'atomes qui décrivent les différentes parties du fichier. Certains atomes embarquent du contenu tandis que d'autres servent à héberger des métadonnées techniques ou descriptives. Chaque atome est identifié par un type sur 4 octets (par exemple avc1 pour du H.264 ou mjpg pour du Motion-JPEG). Selon la nature de son contenu, on parlera de « QuickTime Video » (ou « Quicktime movies »), de « QuickTime Audio » ou même de « QuickTime Image ».

Ainsi, un *fichier vidéo* au format MOV a un atome principal typé *moov* qui fait référence à des atomes techniques (par exemple, un profile prfl) et des atomes de pistes (*trak*) qui portent les données. Les atomes de pistes peuvent contenir directement les données ou une simple référence à ces données localisées ailleurs.

Parmi le *grand nombre de codecs audio et vidéo qu'il peut embarquer*, l'usage majoritaire en 2021 est l'utilisation du Apple ProRes.

Le format MOV gère les *timecodes* dans un atome spécifique typé *tmcd*.

### Usages obsolètes

Le format conteneur MOV a été employé dans des usages divers, aujourd'hui (mars 2021) abandonnés :

- pour un flux audio seul au format AAC, protégé par DRM, par le logiciel Apple iTunes avec l'extension .m4p ;

- pour des images fixes sous le nom *QTIF* et les extensions .qti, voire .qtif ou .qif (les produits Apple en ont désormais abandonné le support) ;

- à partir de 1995 pour des images virtuelles à 360°, sous le nom « QTVR » (Quicktime Virtual Reality).
<figure><img src="image_130.png" /></figure>

## Organisme de maintenance et documentation de référence

Ce format est propriétaire, mais Apple a publié ses spécifications sur son site developer.apple.com (voir la section Versions de cette fiche).

## Identifiants

Extension : .mov

Type MIME : video/quicktime

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q942350</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000052</td></tr><tr><td>PRONOM</td><td>x-fmt/384</td></tr><tr><td>Just Solve the File Format Problem</td><td>QuickTime</td></tr></tbody></table>

## Caractéristiques techniques

Le conteneur et sa structure sont relativement **transparens (CPO-TRA)**, la complexité des fichiers étant plutôt liée à la diversité des formats de ses composants audio et vidéo (**CPO-SIM**).

Afin de faciliter l'édition, le format permet de référencer les composants média sans les embarquer dans le fichier. Les fichiers MOV qui utilisent cette fonctionnalité ne sont donc pas **auto-suffisants (CPO-AUT)**. En outre, une dépendance envers un fichier *resource fork* est identifiée pour d'anciens fichiers QTFF : la lecture sur des systèmes Mac plus récents et la préservation peuvent être compromises par le fait que l'atome *moov*, obligatoire, est conservé dans le fichier *resource fork* (voir à ce propos le billet de Tyler Thorsted, "Quicktime MOOV").

La Bibliothèque du Congrès rapporte dans sa description du format le fait que des fichiers Quicktime distribués par Apple iTunes comportent des **mesures techniques de protection (CPO-PRO)** imposant l'entrée de codes pour limiter leur lecture sur trois appareils différents au maximum.

## Métadonnées internes

Les métadonnées sont portées par des atomes particuliers, typés *meta*.

La liste des clés utilisées par le logiciel QuickTime d'Apple est définie ici. Toutes ces clés commencent par le préfixe `com.apple.quicktime`.

L'annexe D de la spécification indique comment sont alignées les métadonnées d'autres formats sur celles du format MOV.

## Outils connus par la BnF

L'environnement QuickTime d'Apple produit et lit ces fichiers. Disponible lors de sa création uniquement sur MacOs, il fonctionne aussi sous Windows depuis 1992. Néanmoins, Apple ne maintient plus la version Windows de Quicktime depuis 2016 en raison de failles de sécurité.

La lecture est possible avec d'autres outils (VLC pour la vidéo ou XnView pour l'image) mais reste toujours partielle.

Pour l'usage vidéo, l'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est `MediaInfo`, qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7. Au 1er février 2021, la sortie MPEG-7 de l'outil `MediaInfo` ne contient pas toutes les métadonnées de caractérisation souhaitées par la BnF.

De même, l'outil `ffmpeg` permet le décodage et la conversion de ce format vers des formats de diffusion, comme par exemple le [MP4 H.264](https://www.w3.org/TR/mp4-2003-06-01/).

## Usage ou présence dans les collections de la BnF

Quelques exemples existent dans le cadre de dons numériques, actuellement dans le Système Audiovisuel de la BnF.
<figure><img src="image_131.png" /></figure>

Des partenaires de la BnF (Centre Pompidou ou Centre National du Cinéma) reçoivent ou produisent ce format pour les films numériques.
<figure><img src="image_132.png" /></figure>

## 4.33. Shapefile (SHP)

### Description

Le Shapefile, Esri Shapefile ou SHP est un format cartographique vectoriel et binaire développé par Esri pour son système d'information géographique ArcView GIS version 2.x en 1994. Esri en publie une spécification stable et ouverte. (CPO-DOC, CPO-LIB, CPO-STA).

Le format est largement adopté à toutes les étapes de production de la donnée. Il permet de constituer des bases et jeux de données géographiques associant des valeurs sémantiques à des points, des lignes et des polygones. Il ne décrit cependant pas la topologie des objets et certaines géométries complexes.

Pour la préservation ses handicaps sont le manque de compacité, d'expressivité et de robustesse. Ses avantages sont la sociabilité, la simplicité et la stabilité.

### Qualité et caractéristiques du flux

Le format connaît des limitations de volume (2 Go pour `.shp` et `.dbf`), nombre d'attributs (25) et pour le nombre de caractères des noms (10) et des textes (250) (CPS-EXP).

### Sociabilité

Le Shapefile, malgré l'apparition régulière de concurrents, demeure massivement utilisé à travers le monde pour constituer des bases de données géographiques de toutes thématiques. Les agences nationales de cartographie, même si elles proposent souvent des formats alternatifs, continuent à diffuser leurs produits en Shapefile, par exemple les bases topographiques de l'IGN français, du BKG allemand ou de l'OFTS suisse. Le format est également utilisé pour fournir des métadonnées géographiques d'autres types de documents (images, bases matricielles).

En préservation numérique, le SHP est accepté par dix institutions répondant à l'enquête de l'OPF sur les formats recommandés. Il est l'un des quatre formats cartographiques vectoriels préférés par la Bibliothèque du congrès. Il n'est en revanche pas le format d'archivage de l'IGN français qui dispose de son propre format (CPO-SOC).

Le format est pris en charge par les principaux systèmes d'information géographique, notamment QGIS et ARCGIS. Il est lu par la bibliothèque GDAL (CPO-OUT).

### Relations à d'autres formats

Le format Shapefile consiste en l'association de plusieurs fichiers dont un fichier « principal » comportant l'extension `.shp` qui n'est pas autonome. Cette fiche décrit cet ensemble et non le seul composant `.shp` (géométries des objets).

Le fichier `.dbf` est fondé sur le format `DBASE` créé dans les années 1980.

### Versions

Esri publie une spécification datée de 1998. Il n'est pas fait mention d'une version précédente mais la création de nouveaux composants optionnels (extensions) a été progressive. Le SHP n'est pas un standard OGC.

### Contenu

Dans un Shapefile tous les fichiers possèdent le même nom et une extension différente.

## 1. Fichiers obligatoires dans un Shapefile

- `.shp`: le fichier "principal" ("main file") qui contient les géométries des objets ;

- `.dbf`: le fichier `DBASE`, une table qui stocke les informations attributaires dans le même ordre que les géométries, ordre qui assure la correspondance entre attributs et géométries (la sémantique des objets) ;

- `.shx`: le fichier d'index des géométries qui contient les positions exactes de chaque géométrie dans le `.shp` et permet d'y accéder rapidement.

## 2. Fichiers facultatifs dans un Shapefile

### Métadonnées :

- `.prj`: stocke le système de coordonnées de référence dans le format `Well-known text (WKT)` ;
<figure><img src="image_133.png" /></figure>

- `.shp.xml`: métadonnées XML sur le Shapefile (nom, thématique du SHP, projection, structure des données, source des données...);

- `.cpg`: encodage des caractères.

Les fichiers `.lyr` (layer file), de symbologie (sémiologie graphique), qui peuvent être associés à un répertoire Shapefile ne font pas partie du format lui-même mais sont issus du SIG ArcGis (aussi lus par QGIS).

### Index spatiaux :

- `.sbn et .sbx`: les parties 1 et 2 d'un index spatial qui permet, par exemple, de trouver rapidement des objets dans une zone donnée;

- `.fbn et .fbx`: index spatiaux en lecture seule;

- `.ixs et .mxs`: index de géocodage et optimisation de recherches spatiales;

- `.qix`: un index spatial basé sur un quadtree pour diviser les géométries en fonction de leur position géographique. Généré notamment par GDAL.

### Index attributaires :

- `.atx`: un index attributaire pour optimiser les recherches dans le fichier `.dbf`;

- `.ain et .aih`: index attributaires liés à un champ actif particulier dans le `.dbf`.

## Organisme de maintenance et documentation de référence

La spécification est publiée par Esri sur son site et [archivée](https://www.esri.com/arcgis/arcgis-standards). Il n'y a pas d'évolution. Le Shapefile n'est pas un standard OGC.

### Identifiants

Extensions: `.shp`, `.shx`, `.dbf`

Types MIME: `application/vnd.shp`, `application/vnd.shx`, `application/vnd.dbf`

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q278934</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000280</td></tr><tr><td>PRONOM</td><td>x-ffmt/235</td></tr><tr><td>Just Solve the File Format Problem</td><td>Shapefile</td></tr></tbody></table>

### Caractéristiques techniques

Quand les jeux de données dépassent plusieurs Mo, le Shapefile est beaucoup moins compact que ses concurrents Geopackage et GeoJSON. Il est plus performant sur les jeux de données de quelques Ko (CPO-COM).

Le Shapefile a une structure *simple* avec des spécifications courtes. La segmentation des Shapefile facilite l'identification de ses composants mais la pluralité des fichiers induit un risque dans le transfert de l'information. De plus le Shapefile est un format binaire dépendant de logiciels SIG pour son interprétation (CPO-SIM, CPO-TRA).

Les fichiers non obligatoires du Shapefile sont très souvent utilisés pour fournir des informations cartographiques fondamentales comme la projection (CPO-AUT).

Le Shapefile ne dispose d'aucune fonctionnalité native pour protéger les données (CPO-PRO). Il ne comporte pas de fonction pour garantir l'intégrité des données, ignorer des sections corrompues ou parer la perte d'un fichier constitutif (CPO-ROB).

### Métadonnées internes

En-têtes du `.shp` et du `.shx` (identiques) : codé sur 100 octets, contient la taille du fichier, le type de géométries utilisées et les coordonnées minimales et maximales en X, Y et Z.

En-tête du `.dbf`: date de mise à jour des données et nombre d'enregistrements du fichier.
<figure><img src="image_134.png" /></figure>

Les seules métadonnées internes des fichiers obligatoires ne permettent pas d'embarquer des informations cartographiques fondamentales comme la projection ou la source des données. Elles peuvent cependant intégrer les fichiers additionnels.

## Outils connus par la BnF

- **Caractérisation** : OGR avec la commande ogrinfo

- **Validation** : QGIS dispose d'un outil de validation des géométries. FME est une solution payante.

- **Édition** : l'édition et la production de fichiers Shapefile est faite à partir de systèmes d'information géographique. La bibliothèque open source GDAL gère également l'ensemble des formats matriciels ou vectoriels géographiques, dont Shapefile.

## Usage ou présence dans les collections de la BnF

La BnF reçoit par dépôt légal la base de données topographique, la base de données cartographique historique, la base de données forestière et le plan parcellaire édités par l'IGN en Shapefile (éditions à partir de 2010).
<figure><img src="image_135.png" /></figure>

## 4.34. S-57 (ENC)

### Description

Le format S-57 ou IHO S-57 (ENC) est la norme de l'Organisation hydrographique internationale (OHI, IHO) pour le transfert des données hydrographiques numériques dont la première version *date de 1992*. Elle définit un format cartographique vectoriel et binaire pour les cartes marines numériques vectorielles ou ENC (Electronic Navigational Chart). Leur affichage obéit à la norme S-52 de l'OHI. Les spécifications sont ouvertes, maintenues et publiées par l'OHI (**CPO-DOC**). La version 3.1 en vigueur est inchangée depuis 2000. (**CPO-STA**).

La validation de cartes officielles ressort des autorités hydrographiques. Il s'agit en France du Service Hydrographique et Océanographique de la Marine (Shom) (**CPO-LIB**).

S-57 est le format unique pour les cartes marines électroniques officielles. Elles sont obligatoires à bord des navires de marchandises de plus de 3 000 tonneaux de jauge brute (GT) et des navires de passagers de plus de 500 GT depuis la mise à jour en 2011 de la convention de 1974 pour la sécurité en mer (*SOLAS, Safety of Life at Sea*). Pour ces catégories de navires la possession de cartes marines imprimées ou matricielles (*Raster navigational chart, RNC* n'est plus suffisante. Pour la plaisance, des éditeurs privés (Navionics, C-MAP, OpenSeaMap) diffusent des cartes vectorielles hors S-57 adaptées aux ECS (Electronic Chart Systems) dont les formats peuvent être propriétaires (NV2, CM93) (**CPS-EXP**).

Pour la préservation ses handicaps sont le manque de simplicité et de transparence. Ses avantages sont la compacité, la robustesse, la stabilité et l'expressivité.

### Sociabilité

La communauté d'experts producteurs des données, les cartographes des autorités hydrographiques, est restreinte, d'autant que certains pays assurent la cartographie pour plusieurs autres (le *United Kingdom Hydrographic Office*, UKHO, pour plus de 70 pays et le Shom pour 14 pays). Les professionnels de la navigation maritime, s'ils peuvent avoir une connaissance du format, sont avant tout experts des ENC comme documents utilisés dans les ECDIS. Enfin, les usagers de systèmes d'information géographiques peuvent être amenés à récupérer l'information géographique de référence des ENC en S-57 pour la réutiliser dans un format générique.

En préservation, le S-57 est le format préféré par les archives nationales des États-Unis pour les cartes vectorielles de navigation dans leur *plan de préservation des cartes marines numériques*. Il est jugé acceptable par les *Bibliothèques et archives du Canada (CPO-SOC)*.

A bord des bateaux où les ENC sont obligatoires leur lecture doit se faire sur une console ECDIS (*Electronic Chart Display and Information System*) conforme aux normes de l'Organisation maritime internationale (OMI). Elles permettent d'afficher de manière interactive les informations de l'ENC, celles relatives à la position, au cap et à la vitesse du navire et, éventuellement, d'autres capteurs de navigation (radar, sonar, NAVTEX pour la météo et AIS pour l'échange avec d'autres navires). La combinaison de l'ENC et de l'ECDIS particulier d'un navire forme le *System Electronic Navigational Chart* (SNEC).

Le S-57 peut être lu par des ECS, non conformes à la norme ECDIS, destinés à la plaisance (*chartplotter ou traceur*). Il existe également des logiciels permettant d'afficher les ENC conformément à la norme S-52 sur des ordinateurs de bureau (*SeeMyENC et OpenCPN*). Teledyne diffuse aussi gratuitement *un visualiseur S-57 et S-100*. En SIG, *une extension d'ArcMap affiche le S-57* mais il n'existe pas d'équivalent pour QGIS. (*CPO-OUT*)

### Relations à d'autres formats

L'OHI a adopté en 2022 la norme S-100 destinée à remplacer la S-57 et les normes associées. Elle est conforme aux normes ISO 19000 sur l'information géographique et permettra l'interopérabilité avec les SIG. La norme S-101 pour les cartes électroniques, tout en conservant les principes du S-57, *comprend des modèles géométriques plus riches, une meilleure représentation des attributs complexes, facilite la mise à jour du catalogue des objets et comporte des règles de représentation qui remplacent la norme S-52*. Elle fera partie d'un ensemble intégrée de normes concernant par exemple également la surface bathymétrique (S-102) ou les courants de surface (S-111).

### Versions

#### Versions des spécifications

- La version 1.0 date de 1992. La version 2.0 est antérieure à 1994.

- La version 3.0 date de 1996. Par rapport à la version 2.0 elle comporte une implémentation binaire du format, en plus du format ASCII existant, le concept de cellule (une couverture territoriale, équivalente à
<figure><img src="image_136.png" /></figure>

une carte), un mécanisme de mise à jour révisé basé sur des identificateurs d'objets uniques et un modèle de données plus complet. Elle réorganise également le document en trois parties (voir contenu).

- La version 3.1 de 2000, en vigueur, n'incorpore que de nouvelles valeurs d'attributs qui n'étaient pas présentes dans la 3.0. Aucun changement jusqu'à présent, les travaux concernent la S-100.

## Types d'ENC

### ENC destinés à la navigation civile en mer, suivant la norme S-57 commune

Ces ENC sont chiffrés selon la norme S-63 pour la diffusion des ENC par les centres de diffusion agréés par les autorités hydrographiques et l'OHI : Primar (utilisé par le Shom) et IC-ENC utilisé par le UKHO. La norme a été adoptée en 2002.

### Inland Electronic Navigational Chart (IENC) ou « cartes électroniques de navigation au standard ECDIS Intérieur »

Cartes nautiques au format S-57 destinées à la navigation dans les eaux intérieures (fleuves, rivières, canaux, lacs). La spécification actuelle de produit est la 2.4. Elle sera remplacée par la norme S-401 de la série de normes S-100. Le logiciel SeeMyENC est recommandé par Voies navigables de France pour lire sur PC les IENC.

### Additional Military Layer (AML)

Cartes nautiques militaires au format S-57 comportant des couches adaptées aux besoins des membres de l'OTAN. Le document « AML Implementation and Guidance Document » donne un tableau comparatif des couches ENC et AML. Différents états des spécifications AML sont appliqués suivant les pays (1.0, 2.0 ou 3.0). Il existe depuis 2018 une spécification d'affichage des AML, fondée sur la S-52, à destination des Warship ECDIS (WECDIS) mais elle n'est pas obligatoire. Le logiciel libre SeeMyENC lit les AML. Dans le cadre du développement des normes S-100, les AML seront comprises dans les normes S-500.

### Contenu

La norme S-57 présente le modèle conceptuel et logique utilisé pour décrire le monde réel dans les cartes marines numériques vectorielles ou ENC (Electronic Navigational Chart). Elle comporte deux appendices : le catalogue des objets et la spécification de produit ENC qui permet l'échange physique des données suivant la norme ISO/IEC 821.

### Arborescence

Les ENC se présentent obligatoirement sous forme d'un répertoire racine appelé ENC_ROOT dans lequel se trouve :

- Un ou plusieurs fichiers de donnée. 000. Un fichier.000 contient toute la donnée géographique d'une édition de carte marine (cellule) et est autonome. Aucun autre fichier n'est nécessaire pour sa lecture dans un logiciel adapté. Les fichiers.001 jusqu'à.999 sont des mises à jour.

Dans les métadonnées (DSID), une nouvelle carte a pour numéro d'édition 1 (EDTN = 1), sa mise à jour (.001) garde ce numéro d'édition 1 (EDTN = 1) et un numéro de mise à jour de 1 (UPDN, update number = 1). La réédition de la carte intégrant les mises à jour et de nouvelles informations reprend l'extension .000, porte un numéro d'édition 2 (EDTN=1) et un numéro de mise à jour de zéro (UPDN = 0).

<table><thead><tr><td>Type de carte (cellule)</td><td>Extension</td><td>Numéro (EDTN)</td><td>d'édition</td><td>Numéro de mise à jour (UPDN)</td></tr></thead><tbody><tr><td>Nouvelle carte</td><td>.000</td><td>1</td><td></td><td>0</td></tr><tr><td>Mise à jour de la nouvelle carte</td><td>.001</td><td>1</td><td></td><td>1</td></tr><tr><td>Nouvelle édition de la même carte</td><td>.000</td><td>2</td><td></td><td>0</td></tr></tbody></table>

Les noms de fichiers obéissent à la structure suivante : CCPXXXXX.EEE

CC = code pays du producteur

P = catégorie de la carte correspondant à des tranches d'échelles

XXXXX = code individuel de cellule (carte)

EEE = numéro de mise à jour (extension du fichier, .000 pour une nouvelle carte)
<figure><img src="image_137.png" /></figure>

- Un seul fichier **CATALOG**: fichier de répertoire (table de contenu) pointant vers un nombre défini de fichiers S-57 (.000) à charger ensemble dans le cas d'une livraison multiple. Le fichier est présent même si une seule carte est livrée. L'extension se rapporte la version du produit, 3.1 actuellement.

- Un fichier lisez-moi README.TXT en langage naturel. Le Shom place aussi dans ses livraisons un fichier de métadonnées XML au format ISOTC211 sur l'information géographique.

## Ordre des données

L'ordre des données dans chaque ENC (nouvelle édition ou mise à jour) est fixe, métadonnées internes puis données géométriques et sémantiques :

- Data set file > Data set general information record > Data set geographic reference record >

- Vector records > Isolated nodes (SG3D) > Isolated nodes (SG2D) > Connected nodes > Edges >

- Feature records > Meta features > Geo features (ordered from slave to master) > Collection features

Le seul système de référence des ENC est le WGS84 non projeté. Les latitudes et longitudes sont exprimées en degrés décimaux. Les profondeurs, hauteurs et la précision de positionnement en mètres. La distance en miles nautiques ou mètres.

## Organisme de maintenance et documentation de référence

L'organisme de maintenance du S-57 est l'Organisation hydrographique internationale

Les normes relatives aux ENC sont :

- La norme S-57 portant sur le modèle et la structure de données des ENC et ses appendices ;

- La norme S-52 portant sur l'affichage des ENC et ses appendices ;

- La norme S-58 portant sur la validation des ENC ;

- La norme S-63 portant sur le cryptage des ENC.

### Ces normes sont archivées

L'organisme de maintenance des **IENC** est le Inland ENC Harmonization Group (IEHG). Les spécifications relatives à la version 2.4 en vigueur (dont affichage) sont disponibles mais à archiver.

L'organisme de maintenance des **AML** est le United Kingdom Hydrographic Office (UKHO), équivalent britannique Shom. Les spécifications de toutes les versions utilisées et un guide des AML sont archivées

### Identifiants

Extensions : .000, 0.001 etc.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q29644051</td></tr><tr><td>PRONOM</td><td>fmt/1935</td></tr></tbody></table>

## Caractéristiques techniques

Le S-57 est très compact (**CPO-COM**). Un ENC pèse entre 500 et 3000 Ko. La National Oceanic and Atmospheric Administration (NOAA) propose un convertisseur d'ENC qui permet de comparer les volumes pour une même carte. Le S-57 est deux fois plus léger que la Geodatabase d'Esri, dix fois plus que le SHP et vingt fois plus que le DXF<fnref n="44" />. Le SHP est pourtant déjà un format compact pour des fichiers peu volumineux.

La structure du S-57 peut être parfois complexe (topologie), l'information relève d'un domaine spécialisé et l'accès de logiciels particuliers. (**CPO-SIM**)

La norme de chiffrement S-63 protège les ENC diffusés par les centres agréés. Les modalités pratiques en sont :

- Un chiffrement par l'algorithme Blowfish, en hachant les données par la fonction SHA-1 sur la base d'une clé aléatoire et en ajoutant une vérification CRC32.

<footnote n="44">⁴⁴ exemple avec US4GA11M, Doboy Sound to Fernandina</footnote>
<figure><img src="image_138.png" /></figure>

- L'utilisation de signatures au format DSA pour authentifier l'expéditeur des données. En pratique les signatures sont effectuées de manière centralisée par l'OHI qui agit en tant qu'administrateur du système (CPO-PRO).

Le S-57 est robuste : la norme impose une validation des données et suit les principes de l'ISO 8211 qui organise rigoureusement les données (CPO-ROB).

La spécification de produit des ENC exige que seul l'encodage binaire soit employé pour les cartes officielles. Il n'est donc pas possible d'avoir un accès direct à son contenu sous forme textuelle. De plus, une fois le contenu binaire décodé par des programmes adaptés (par exemple OGR), les libellés ne sont pas transparents (CPO-TRA).

L'utilisation comme carte interactive, à laquelle est destinée le format, implique de restituer la donnée selon la norme d'affichage pour une consultation interactive. Au plan logiciel elle requiert :

- Un système de navigation ECDIS pour lesquels les ENC sont primairement produits. Il existe des simulateurs d'ECDIS permettant de reproduire cette consultation sur un ordinateur de bureau. Il s'agit de logiciels propriétaires désormais essentiellement accessibles en ligne pour la formation des marins.

- Un logiciel proposant la carte en simple consultation hors données de navigation. Il existe des logiciels libres permettant cette consultation. Des modules pour SIG peuvent également afficher les données conformément à la S-52.

Une utilisation dérivée du format est la récupération des informations de référence que contient l'ENC sous forme de jeux de données géographiques. Dans ce cas les logiciels SIG génériques sont nécessaires (CPO-AUT).

## Métadonnées internes

Les trois premiers blocs d'un ENC standard comportent des métadonnées internes concernant l'ensemble de la carte.

Le bloc de métadonnées interne se nomme : Data Set Identification field – DSID. Il comporte des dates, des informations sur les producteurs et des identifiants.

Il se divise en deux sous-blocs (l'interrogation de DSID avec OGR les fournit aussi) :

- Data Set Structure Information field – DSSI : nombre d'enregistrements de divers types de la cellule.

- Data Set Parameter field – DSPM : référentiels géographiques, unités de mesure.

Les tableaux p. 23-25 de la spécification de produit les récapitulent ainsi que leurs valeurs.

## Outils connus par la BnF

- Caractérisation : OGR avec la commande OGR info.

- Validation :

- OGR peut fournir une indication en testant la possibilité de convertir le fichier en S-57 (ogr2ogr -f) ;

- 7cs-analyzer de SevenCs (payant) : https://www.sevencs.com/enc-production-tools/7cs-analyzer/ ;

- Arcgis (payant) : https://pro.arcgis.com/en/pro-app/latest/tool-reference/maritime/validate-s-57-file.htm ;

- Caris de Teledyne (payant).

Cependant, à partir du moment où la donnée S-57 à préserver a été diffusée par une autorité hydrographique elle a été validée en conformité avec la norme S-58 de l'OHI (algorithme CRC-32, Cyclic Redundancy Check).

- Édition : pour la production et l'édition peuvent être utilisés CARIS et ARCGIS Maritime. QGIS permet d'ouvrir un S-57 sans affichage normé ce qui rend difficile la manipulation de la donnée (une conversion en SHP peut y remédier).

Pour la migration de S-57 vers S-101 le Shom a jugé en 2021 que les outils GEOMOD étaient les plus performants. Toutefois, l'OHI proposera des convertisseurs dans la phase de mise œuvre opérationnelle de la norme sur ses pages.
<figure><img src="image_139.png" /></figure>

Un corpus de test peut être alimenté par les cartes gratuites de la NOAA et de VNF.

## Usage ou présence dans les collections de la BnF

La BnF conserve plus de 300 ENC du Shom au format S-57 reçus sur cédéroms par dépôt légal de 1999 à 2007. Ils ont été transférés dans le magasin numérique de la BnF. A partir de 2025 les dépôts vont reprendre sous forme dématérialisée pour préserver la production rétrospective et courante.
<figure><img src="image_140.png" /></figure>

## 4.35. SRT

### Description

Le format SRT (SubRip Text) est un format textuel qui fournit le contenu des sous-titres et leur positionnement temporel vis-à-vis d'une vidéo. C'est un standard de fait, produit à l'origine par le logiciel SubRip qui utilisait des techniques d'OCR pour reconnaître les sous-titres en mode image intégrés dans les vidéos et les DVD. Son histoire, hors des circuits officiels, explique l'absence de spécification formelle et une utilisation libertaire.

Il est extrêmement simple, lisible et éditable par un humain et a connu plusieurs variantes pour ajouter de l'expressivité (en particulier, les balises de formatage et le positionnement spatial).

Malgré son extrême simplicité qui permet une vérification visuelle et une compréhension immédiate pour un humain, son manque de spécification formelle qui autorise plusieurs extensions syntaxiques rend son usage pour une préservation à long terme incertain.

### Qualité et caractéristiques du flux

Le format permet d'encoder un seul flux de sous-titres dans une seule langue.

### Sociabilité

Le format SRT est largement répandu comme format d'échange de sous-titres sur Internet. Il est accepté par toutes les plateformes de streaming, notamment YouTube. De plus, il peut être ajouté à la plupart des logiciels de visualisation de vidéos, notamment VLC.

### Relations à d'autres formats

Ce format est à l'origine du format WebVTT, promu par le W3C.

### Versions

Depuis la version initiale, les seules évolutions ont concerné l'ajout de style sur le texte via des balises (par analogie avec le HTML), qui peuvent être ignorés par les lecteurs. Le format est donc paradoxalement très stable (CPO-STA).

### Conteneur

Le format SRT se présente soit dans un fichier dédié, séparé du contenu vidéo associé, soit embarqué dans un fichier conteneur, notamment MKV (voir cet Internet draft).

### Contenu

Un fichier SRT est une simple concatenation de blocs identiques :

numéro séquentiel du sous-titre
Temps de départ --> temps de fin
Texte du sous-titre (jusqu'à deux lignes)
[ligne vide]

Les temps de départ et de fin sont exprimés en respectant le format HH:MM:SS, sss (on notera l'utilisation de la virgule pour la séparation décimale, marque de l'origine française du format 😂)

Le texte des sous-titres est en Unicode soit, le plus souvent, en UTF-8 soit en UTF-16.

Une extension courante permet l'usage des balises <b>, <i>, 
, <u> pour formater le texte, ainsi que <font color=""> pour le coloriser.

### Organisme de maintenance et documentation de référence

Le format n'est pas maintenu par un organisme quelconque et il n'y a pas de documentation formelle.

La page Wikipédia de l'outil SubRip en français mais, de façon plus complète, en anglais peuvent servir de base de référence.

### Identifiants

Extension : .srt
<figure><img src="image_141.png" /></figure>

Type MIME : text/plain ou application/x-subrip (variante non officielle)

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q9332294<br/>Q105852434 variante en UTF-16</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000569</td></tr><tr><td>PRONOM</td><td>fmt/1218</td></tr><tr><td>Just Solve the File Format Problem</td><td>SubRip_text_file_format</td></tr></tbody></table>

## Caractéristiques techniques

Comme évoqué précédemment, le format est particulièrement simple (CPO-SIM), transparent (CPO-TRA) et indépendant (CPO-AUT).

Comme il s'agit d'un format textuel, il n'est pas très compact (CPO-COM) mais peut être très facilement et très efficacement compressé sans pertes par des algorithmes de type Deflate.

Il n'inclut pas de mécanismes de protection (CPO-PRO).

Comme tout format en clair, il est relativement robuste (CPO-ROB) puisqu'il est aisé d'ignorer les parties non interprétables ou de les réparer à la main avec un simple éditeur de texte.

## Métadonnées internes

Le format ne définit pas de métadonnées internes.

## Outils connus par la BnF

Le format est identifié par les outils DROID et Unix file.

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo.

Sa production est réalisable avec tous les outils de fabrication ou de manipulation de sous-titres textuels. En particulier, ffmpeg peut le prendre comme flux en entrée ou en sortie.

## Usage ou présence dans les collections de la BnF

Ce format est utilisé à la BnF comme format pivot lors des manipulations de fichiers vidéo avec des sous-titres.
<figure><img src="image_142.png" /></figure>

Les exigences BnF sur les images TIFF livrées à la BnF dans le cadre de ses marchés de numérisation sont décrites dans la section 4 du référentiel de numérisation des documents opaques.

## Identifiants

Extensions : `.tif` et `.tiff`, également régulièrement trouvées en majuscules.

Type MIME : `image/tiff`.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q215106</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000022</td></tr><tr><td>PRONOM</td><td>fmt/353</td></tr><tr><td>Just Solve the File Format Problem</td><td>TIFF</td></tr></tbody></table>

## Caractéristiques techniques

La spécification TIFF définit un ensemble de fonctionnalités minimales que tout lecteur doit gérer (baseline TIFF) ainsi que des extensions permettant de répondre à des besoins spécifiques (modèles couleurs autres que RGB, méthodes de compression, etc.). Le support logiciel de certaines extensions est inégal, en particulier

- **Diverses méthodes de compression** peuvent être utilisées pour le flux image contenu dans un conteneur TIFF. Les plus communes sont LZW, ZIP/Deflate, CCITT Group 3 et CCITT Group 4. Une liste exhaustive des méthodes de compression plus rarement employées est proposée sur la page Wikipédia en anglais. Les méthodes moins courantes peuvent occasionner des problèmes de restitution sur certains logiciels. Une étude de la British Library a déterminé que les méthodes de compression les plus efficaces sont CCITT Group 4 pour les images bitonales et ZIP/Deflate pour les images en niveaux de gris 8 bits ou en couleurs 24 bits. Le gain d'espace obtenu a pour contrepartie un risque légèrement supérieur puisque les méthodes de compression dans un TIFF sont définies dans des extensions qui ne sont pas nécessairement supportées par tous les outils logiciels. La BnF préfère de ce fait que le flux image contenu dans le fichier TIFF ne soit pas compressé.

Note : pour les images bitonales (noir et blanc), la BnF a utilisé dans les décennies passées la compression CCITT groupe 4, très efficace. La numérisation en noir et blanc n'étant plus d'actualité, on ne devrait rencontrer cette compression que dans des données anciennes.

- **La variante multi-pages** permettant d'embarquer plusieurs images (nommées « IFD » pour Image File Directory par le standard) dans le même fichier. Les outils logiciels prenant en charge uniquement la version baseline ne sont pas tenus de traiter les images suivant la première ; certains rencontrent des difficultés pour afficher les fichiers multi-pages. Ces données images successives peuvent avoir des contenus différents ou être des représentations alternatives d'un même contenu : ainsi la sortie TIFF de certains matériels de numérisation comprend-elle un second IFD qui était une version en basse définition du premier, destiné à être utilisé comme vignette.

La complexité (CPO-SIM) et la transparence (CPO-TRA) du format TIFF dépendent de la compression utilisée. Dans sa version non compressée, le format reste simple et ne nécessite donc pas un niveau de compétence et d'équipement matériel et logiciel élevé.

## Métadonnées internes

Outre le flux image, le format TIFF définit des tags décrivant à la fois la structure et les caractéristiques du flux image mais fournissant aussi quelques éléments de description du contenu (artiste, droits de propriété intellectuelle, date, etc.). Le site Aware Systems est la référence sur les tags TIFF, y compris sur ceux propriétaires.

La pratique BnF en matière d'intégration de métadonnées internes dans les images masters se limite aux tags TIFF et est décrite à l'annexe 1 du référentiel de numérisation des documents opaques.

En outre, TIFF est extensible et permet d'embarquer des métadonnées internes dans différents formats (EXIF, IPTC, XMP).
<figure><img src="image_143.png" /></figure>

## Outils connus par la BnF

- Pour la consultation, les principaux logiciels de traitement image le gèrent correctement (XnView, IrfanView, Photoshop, Gimp, ImageMagick, etc.).

- Pour la manipulation et la transformation, la bibliothèque logicielle open source LibTIFF est complète et maintenue.

- Pour la caractérisation, le module TIFF de l'outil JHOVE est utilisé à la BnF et prend en charge l'extraction du profil ICC à partir de sa version 1.18. Il fournit un rapport technique complet incluant des métadonnées techniques pour les images au format Metadata for Images in XML (MIX). On peut également citer d'autres outils permettant d'extraire certaines métadonnées : Apache Tika et Exiftool.

- Pour la validation, JHOVE dispose d'un module de validation TIFF. Celui-ci est en outre capable d'avertir de la présence de tags TIFF inconnus. Néanmoins, celui-ci ne s'avère pas capable de repérer des fichiers tronqués. Dans le cadre du projet européen PREFORMA, un profil d'application restreint aux fonctionnalités considérées comme durables a été développé : TI/A. L'outil DPF Manager, financé par le projet européen PREFORMA, permettait notamment de vérifier la conformité d'un fichier TIFF aux exigences TI/A. La maintenance de cet outil étant compromise, il est prévu de l'intégrer à l'outil JHOVE (information en date du 14 mars 2024).

- Pour la consultation des tags TIFF, il existe l'outil AsTIFFTagViewer. Une composante de la bibliothèque LibTIFF, TIFFINFO permet également de récupérer des informations sur un fichier TIFF ; elle fonctionne en ligne de commande.

## Usage ou présence dans les collections de la BnF

Le format TIFF a été utilisé depuis le début de la numérisation de conservation à la BnF, au début des années 1990. Il s'agit du format le plus représenté dans ses collections numériques. Depuis 2014, le format est progressivement remplacé par le format JPEG 2000 dans les nouveaux marchés de numérisation.
<figure><img src="image_144.png" /></figure>

## 4.37. Universal Disk Format (UDF)

### Description

UDF (Universal Disk Format) est un système de fichiers ouvert (CPO-LIB) utilisé pour porter les fichiers sur des supports optiques (CD, DVD, Blu-ray, etc.), qu'ils soient inscriptibles (CD-R par exemple), réinscriptibles, ou non (disques pressés). Il peut également être utilisé sur d'autres type de supports tels que les mémoires flash (clés USB) ou même disques durs.

Il est conçu un système interoperable et est de fait très bien supporté par la quasi-totalité des systèmes d'exploitation.

UDF est un sous-ensemble de la norme ISO/IEC 13346 (International Organization for Standardization), elle-même étant la forme internationale de la norme ECMA-167 (European Computer Manufacturers Association). UDF a été développé par l'OSTA (Optical Storage Technology Association) dans le but de minimiser les coûts et la complexité d'implémenter ISO/IEC 13346, et de faciliter l'échange de données. Depuis 2022, la propriété de la spécification UDF a été transférée de l'OSTA à l'ECMA.

### Sociabilité

UDF est notamment le système de fichiers officiel utilisé pour les DVD Vidéos et Audio.

UDF est un système de fichiers supporté par de nombreux systèmes d'exploitation : AIX, AmigaOS, BeOS/magnussoft/ZETA/Haiku, OS/2, FreeBSD, Linux kernel (2.6.0-2.6.25, 2.6.26 et suivants, Mac OS (8.1-8.5, 8.6, 9, X 10.0-10.3,10.5 et suivants), NetBSD, OpenBSD, Solaris, DOS, FreeDOS, Windows (3.11, 95, 98, Me, 2000, XP, Server 2003, Vista, 7 et suivants). Voir à ce propos le tableau des systèmes d'exploitation compatibles UDF sur la Wikipedia anglophone.

Concernant le support matériel, tous les lecteurs de DVD Vidéo savent utiliser UDF.

### Relations à d'autres formats

UDF partage une partie de sa structure avec le système de fichiers ISO-9660 (volume descriptor). Dans sa version 1.5, il définit le format UDF Bridge qui permet d'incorporer un système de fichiers ISO-9660 partageant ses données avec le système de fichiers UDF présent sur le même support. Concrètement cela permet d'utiliser le support à la fois en tant que système UDF et en tant que système ISO-9660 pour les systèmes qui ne le supportent pas.

Presque tous les disques DVD-Vidéo utilisent le format UDF Bridge, qui est une combinaison des systèmes de fichiers DVD MicroUDF (un sous-ensemble d'UDF 1.02) et ISO 9660. Le format UDF Bridge offre une compatibilité descendante pour les systèmes d'exploitation qui ne prennent en charge que la norme ISO 9660. Tous les lecteurs DVD lisent le système de fichiers UDF d'un disque DVD-Vidéo et ignorent le système de fichiers ISO 9660. Les DVD-Vidéos doivent respecter la version 1.02 de la spécification (qui n'est pas remise en cause par UDF Bridge).

### Versions

<table><thead><tr><td>Révision</td><td>Date</td><td>Fonctionnalités majeures</td></tr></thead><tbody><tr><td>1.00</td><td>24-10-1995</td><td>Version originale.</td></tr><tr><td>1.01</td><td>03-11-1995</td><td>Ajout de l'annexe DVD et quelques modifications mineures.</td></tr><tr><td>1.02</td><td>30-08-1996</td><td>Prend en compte les médias en lecture seulement et les disques durs. Ce format est utilisé par les disques DVD-Vidéo.</td></tr><tr><td>1.50</td><td>04-02-1997</td><td>L'ajout de la prise en charge de la réinscriptibilité (virtuelle) sur les supports CD-R/DVD-R par l'introduction de la structure VAT. Ajout de tables de compensation (sparing tables) pour la gestion des erreurs sur les supports réinscriptibles tels que les CD-RW, DVD-RW et DVD+RW. Ajout d'un pont UDF « UDF Bridge ».</td></tr><tr><td>2.00</td><td>03-04-1998</td><td>Ajout de la prise en charge des fichiers de flux (stream files) et des fichiers en temps réel (pour l'enregistrement de DVD) et simplification de la gestion des répertoires. Prise en charge du VTA (Virtual Allocation Table).</td></tr></tbody></table>
<figure><img src="image_145.png" /></figure>

<table><tr><td>2.01</td><td>15-03-2000</td><td>Principalement une version de correction de bogues de l'UDF 2.00.</td></tr><tr><td>2.50</td><td>30-04-2003</td><td>Ajout de la partition de métadonnées (Metadata Partition) facilitant la mise en cluster des métadonnées, la récupération en cas de panne et la duplication optionnelle des informations du système de fichiers. Ce format est utilisé par certaines versions de disques Blu-rays et par la plupart des disques HD-DVD.</td></tr><tr><td>2.60</td><td>01-03-2005</td><td>Ajout de la méthode Pseudo OverWrite pour les lecteurs prenant en charge la capacité de pseudo-écriture sur des supports enregistrables séquentiellement. Compatibilité en lecture seule avec les implémentations UDF 2.50. (Certains Blu-ray utilisent ce format).</td></tr><tr><td>Secure UDF</td><td>26-02-2002</td><td>Permet de garantir que les informations sensibles sont dissimulées aux utilisateurs.</td></tr></table>

Le format est stable (CPO-STA), n'ayant pas évolué depuis 2005.

## Contenu

En tant que système de fichiers, UDF ne restreint pas la nature du contenu. Pour un usage de type DVD-Vidéo, la spécification liste en revanche des répertoirs et fichiers obligatoires (répertoire VIDEO_TS et fichier VIDEO_TS.IFO). Il reste possible d'y ajouter toute sorte de fichiers (CPO-ADD).

La spécification UDF décrit le paramétrage du système de fichier et son organisation vis-à-vis des supports physiques, mais ne s'attarde pas sur le contenu lui-même, qui peut faire l'objet de sa propre spécification comme pour les DVD-Vidéo et Audio.

## Organisme de maintenance et documentation de référence

Depuis 2022, la spécification est devenue propriété de l'ECMA, qui en a republié les différentes versions en 2023 sous le nom de ECMA TR/112.

- ECMA : ECMA TR/112 - Universal Disk Format (UDF) specification - 1st edition, December 2023

<table><thead><tr><td>Partie</td><td>Spécification</td></tr></thead><tbody><tr><td>ECMA TR/112 Part 1</td><td>General</td></tr><tr><td>ECMA TR/112 Part 2</td><td>UDF specification revision 2.60</td></tr><tr><td>ECMA TR/112 Part 3</td><td>UDF specification revision 2.50</td></tr><tr><td>ECMA TR/112 Part 4</td><td>UDF specification revision 2.01</td></tr><tr><td>ECMA TR/112 Part 5</td><td>UDF specification revision 2.00</td></tr><tr><td>ECMA TR/112 Part 6</td><td>UDF specification revision 1.50</td></tr><tr><td>ECMA TR/112 Part 7</td><td>UDF specification revision 1.02</td></tr><tr><td>ECMA TR/112 Part 8</td><td>Secure UDF specification revision 1.00</td></tr></tbody></table>

Voici une traduction de l'introduction d'ECMA TR/112 qui retrace l'historique d'UDF :

« En 1992, l'Ecma a normalisé l'ECMA-167, qui spécifie les volumes et les structures de fichiers pour l'échange de fichiers, en considérant que les futures normes de volumes et de structures de fichiers se conformeraient à ce cadre, plutôt que de créer un autre format incompatible. L'Ecma a proposé l'ECMA-167 à l'ISO/IEC JTC 1 en vue d'une normalisation internationale selon la procédure accélérée. Au cours de cette normalisation internationale, l'ECMA-167 a fait l'objet d'une deuxième édition en 1994, et l'ISO/CEI 13346, équivalente à la deuxième édition, a été publiée en 1995. De 1992 à 2006, l'Optical Storage Technology Association (OSTA) a développé la spécification Universal Disk Format (UDF), qui est un sous-ensemble pratique de l'ECMA-167, afin de maximiser l'échange de données et de minimiser le coût et la complexité de la mise en œuvre de l'ECMA-167. En 1997, une troisième édition de l'ECMA-167 a été publiée en même
<figure><img src="image_146.png" /></figure>

temps que la révision de la spécification UDF. En 2022, l'OSTA a transféré les droits d'auteur à l'Ecma pour que la spécification UDF soit utilisable en permanence avec l'ECMA-167. »

- **ECMA-167 - 3rd Edition** Volume and file structure for write-once and rewritable media using non-sequential recording for information interchange (Juin 1997)

- **ISO/IEC 13346** Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange (1995)

<table><thead><tr><td>Partie</td><td>Spécification</td></tr></thead><tbody><tr><td>ISO/IEC 13346-1:1995</td><td>Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange (1995)</td></tr><tr><td>ISO/IEC 13346-2:1999</td><td>Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange - Part 2: Volume and boot block recognition</td></tr><tr><td>ISO/IEC 13346-3:1999</td><td>Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange - Part 3: Volume structure</td></tr><tr><td>ISO/IEC 13346-4:1999</td><td>Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange - Part 4: File structure</td></tr><tr><td>ISO/IEC 13346-5:1995</td><td>Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange - Part 5: Record structure</td></tr></tbody></table>

## Identifiants

Les images disques UDF (hybride ou non) portent généralement l'extension `.iso` (comme les images au format ISO9660). On trouve aussi parfois mention de l'extension `.udf` pour distinguer les 2 formats.

Nous n'avons pas trouvé de type MIME spécifique aux images UDF, mais l'outil d'identification **file** renvoie **application/x-iso9660-image** dans le cas d'une image hybride.

**Note:** On trouve une mention du type MIME **application/vnd.efi.iso** (https://www.iana.org/assignments/media-types/application/vnd.efi.iso) qui s'applique aux images ISO9660 préparées pour être supports de démarrage de systèmes **EFI**. Nous ne savons pas si cela s'applique ou non aux images UDF hybrides.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q853645</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000348</td></tr><tr><td>PRONOM</td><td>fmt/1738</td></tr><tr><td>Just Solve the File Format Problem</td><td>Universal_Disk_Format<br>ISO_image</td></tr></tbody></table>

## Caractéristiques techniques

Le système de fichiers UDF n'apporte aucune sorte de compression (**compacité**, **CPO-COM**).

Ce n'est pas non plus un format **simple** (**CPO-SIM**), de nombreuses spécifications étant nécessaires pour le décrire.

Il n'apporte aucune **mesure de protection particulière** (**CPO-PRO**), cette problématique étant déléguée à la couche *support* pour les CD ou DVD (tel que le système **CSS** par exemple).

Concernant les critères de **robustesse** (**CPO-ROB**) le format UDF impose le calcul d'un certain nombre de sommes de contrôle (CRC), mais nous ne savons pas si cela concerne l'intégralité des données ou non. Là encore, la couche *support* apporte de la robustesse en implémentant des algorithmes pour ajouter de la redondance (tel que le code de Reed-Solomon).

En tant que système de fichiers, le format n'est pas du tout **transparent** (**CPO-TRA**).
<figure><img src="image_147.png" /></figure>

Enfin on ne peut pas dire que le format est **indépendant ou autonome (CPO-AUT)** tant il est difficile de parler d'UDF sans également parler d'ISO9660. De plus il nécessite d'autres spécifications pour en préciser l'usage, notamment dans le contexte des DVD ou CD-ROM.

## Métadonnées internes

En tant que système de fichiers, les seules métadonnées descriptives sont éventuellement un libellé pour le volume (le nom du DVD typiquement) ainsi que les chemins de fichiers (si on les considère comme métadonnées descriptives).

## Outils connus par la BnF

La commande *mkisofs*, de la suite *schilytools* (anciennement connu sous le nom *cdrtools*) est préférée pour produire une image au format UDF par rapport à l'outil *genisoimage* car elle dispose d'options spécifiques pour les DVD Vidéos.

L'outil *isolyzer* est capable de vérifier l'intégrité d'images disques ISO ou UDF et d'extraire des métadonnées techniques de ces dernières.

L'outil *7zip* peut-être utilisé pour naviguer dans les images UDF.

## Usage ou présence dans les collections de la BnF

Le format ISO-UDF est massivement utilisé par la BnF comme format de copie de conservation et de diffusion pour la plupart des documents multimédias sur supports optiques, notamment pour les DVD-Vidéo et DVD-Audio.
<figure><img src="image_148.png" /></figure>

## 4.38. WARC

### Description

Le format WARC est un format conteneur, utilisé principalement pour stocker les fichiers collectés sur le web au fur et à mesure qu'ils sont capturés par un robot. Il combine plusieurs ressources numériques, quel que soit leur format, dans un fichier d'archivage agrégé avec des informations de contexte. Il est utilisé à la BnF depuis le 13 octobre 2014. Il a été créé par la California Digital Library et Internet Archive. Les bibliothèques nationales membres d'IIPC (Consortium pour la préservation d'internet) ont contribué à ce qu'il devienne un standard ISO (CPO-DOC). La première publication de la norme date de mai 2009.

### Sociabilité

Ce format est utilisé par les membres d'IIPC, réunissant une cinquantaine d'institutions et organismes autour de l'archivage du web. D'autres communautés utilisent également ce format tel que Rhizome, communauté consacrée aux arts numériques réunissant artistes et musées ou LOCKSS, sous les auspices de l'Université de Stanford, un réseau peer-to-peer qui développe et prend en charge un système open source permettant de collecter, de préserver et de fournir à leurs lecteurs un accès au matériel publié sur le web.

### Relations à d'autres formats

Le format WARC dérive de l'ancien format ARC et étend son usage pour mieux répondre aux besoins de collecte, de préservation, d'accès et d'échange des organisations d'archivage. Le format ARC a été créé par Internet Archive en 1996 pour archiver des copies de fichiers web. WARC permet de bien différencier les différents types d'enregistrement pour plus de structuration et de lisibilité, contrairement au format ARC.

### Versions

Le format WARC 1.0 a fait l'objet d'une révision en 2017 pour préciser l'utilisation de certaines informations. Outre le contenu principal actuellement enregistré, la révision prend en charge le contenu secondaire associé, comme les métadonnées attribuées, les événements de détection de doublons abrégés et les transformations ultérieures.

<table><thead><tr><td>Format</td><td>Date</td><td>Lien</td></tr></thead><tbody><tr><td>WARC 1.0</td><td>2009</td><td>ISO 28500:2009</td></tr><tr><td>WARC 1.1</td><td>2017</td><td>ISO 28500:2017</td></tr></tbody></table>

### Contenu

Un fichier WARC est la concatenation de plusieurs enregistrements WARC. Un enregistrement WARC se compose d'un en-tête (header) suivi d'un bloc de contenu (payload); l'en-tête comporte des champs nommés obligatoires qui documentent l'URI (identifiant de l'enregistrement), la date, le type et la longueur de l'enregistrement et qui renseignent les échanges client-serveur pour chaque ressource collectée (fichier). Il existe huit types d'enregistrement WARC : warcinfo, response (réponse), resource (ressource), request (requête), metadata (métadonnées), revisit, conversion et continuation. Chacun de ces types correspond à un résultat particulier du processus de collecte. Les blocs de contenu d'un fichier WARC peuvent contenir des ressources de n'importe quel format sous forme binaire, y compris les fichiers audio ou vidéo.

### Organisme de maintenance et documentation de référence

Le format WARC est maintenu par IIPC et normalisé par l'ISO depuis 2009, avec une révision en 2017 (ISO 28500:2017, Information et documentation - Format de fichier WARC). La BnF diffuse une version draft de la norme sur son site bibnum.bnf.fr.

IIPC propose de la documentation supplémentaire pour implémenter le WARC.

### Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q7978505</td></tr></tbody></table>
<figure><img src="image_149.png" /></figure>

<table><tr><td>Bibliothèque du Congrès</td><td>fdd000236</td></tr><tr><td>PRONOM</td><td>WARC 1.0 fmt/289<br/>WARC 1.1 fmt/1281</td></tr></table>

## Caractéristiques techniques

La distribution des fichiers collectés au sein des fichiers WARC ne correspond à aucune logique documentaire. Le robot enregistre les fichiers capturés selon sa logique propre (et non inhérente au format WARC) dans les différents fichiers WARC disponibles jusqu'à la taille limite atteinte (définie à 1 Go pour la BnF). Le WARC est conçu pour être produit et consommé en flux avec des enregistrements concatenés.

Le format WARC ne définit pas de compression interne. Cependant la compression au format GZIP avec la méthode Deflate est recommandée. Dans une logique de production et consommation en flux la norme nous indique :

> Comme spécifié à la section 2.2 de la spécification GZIP (voir [RFC 1952]), un fichier GZIP valide consiste en n'importe quel nombre de « membres » GZIP, chacun compressé indépendamment.

> Lorsque cela est possible, cette propriété devrait être exploitée pour compressor chaque enregistrement d'un fichier WARC indépendamment. Cela résulte en un fichier GZIP valide dont les sections (produites enregistrement par enregistrement) sont par elles-mêmes des fichiers GZIP valides.

> Les index externes au contenu du fichier WARC peuvent alors être utilisés pour enregistrer la position de départ de chaque enregistrement dans le fichier GZIP, permettant des accès aléatoires aux enregistrements individuels sans requérir la décompression de tous les enregistrements précédent.

> Notons que l'application d'une telle méthode ne produit aucun changement dans le contenu non compressé d'un enregistrement WARC individuel.

Annexe D.2, page 29

## Métadonnées internes

Le WARCinfo est un champ recommandé et à la BnF, le choix a été de le rendre obligatoire.

Les fichiers WARC étant des conteneurs capables de stocker n'importe quel type de fichier – qu'il s'agisse de fichiers archivés en ligne ou non – les métadonnées produites pour décrire la collection ou le déroulement de la collecte peuvent être empaquetées également dans un fichier WARC dit de métadonnées. Ainsi, un même format conteneur peut gérer les données collectées et celles documentant la collecte, et la collection de fichiers WARC peut être ainsi auto-décrite. La communauté utilisatrice de la suite logicielle NetarchiveSuite, qui réunit une dizaine de pays autour de l'archivage du web dont la BnF, a fait ce choix-là.

## Outils connus par la BnF

L'outil utilisé par la BnF pour générer des WARC est le robot de collecte Heritrix. Mais il existe d'autres outils, comme Webrecorder ou Wget qui sont également des robots de collecte, ou Warcreate (plugin de Chrome pour enregistrer une page sous forme de WARC).

Les fichiers WARC sont lus à la BnF par la Wayback machine. Mais il existe également d'autres outils de consultation comme la Python Wayback, WAIL et la replayweb.page.

La série d'outils JWat tools permet de lire, écrire, analyser et valider les fichiers WARC et est intégrée par le module de caractérisation et validation WARC de l'outil Jhove. La bibliothèque warcio, écrite en python, lit et écrit des fichiers WARC. Enfin, l'outil Apache Tika permet d'extraire tous les enregistrements d'un conteneur WARC à l'aide de l'option -z.

Une page wiki recense les outils autour du format WARC.

## Usage ou présence dans les collections de la BnF

Le format WARC est utilisé pour les données issues de l'archivage du web depuis 2014.
<figure><img src="image_150.png" /></figure>

## 4.39. WAVE / WAVE RF64

### Description

Le format WAVE (Waveform Audio File Format) dit également « WAV » en raison de son extension de fichier .wav est un format conteneur mis au point par Microsoft et IBM en 1991 afin de transporter des flux audio. Le format WAVE est construit conformément à la structure Resource Interchange File Format, c'est pourquoi on parle aussi parfois de « RIFF/WAVE ».

Le format WAVE est en théorie propriétaire car développé par des entreprises privées. En réalité, ce format et ses dérivés (WAVE RF64 et BWF notamment), eux totalement libres car maintenus par l'EBU (European Broadcast Union), ne connaissent aucune restriction d'utilisation : leurs spécifications sont publiées (CPO-DOC) et aucun brevet ne porte sur eux (CPO-LIB).

### Qualité et caractéristiques du flux

Les données audio PCM ont une profondeur d'échantillonnage de 4 à 32 bits. Les caractéristiques du flux PCM les plus courantes sont 16 bits / 44,1 kHz (qualité CD) et 24 bits / 88,2, 96 ou 192 kHz (haute qualité).

Jusqu'à Windows 2000, le format WAVE pouvait comprendre des données audio sur un ou deux canaux. À partir de Windows 2000 et sa version WAVE Format Extensible, le format supporte le multi-canal (et en particulier la présence de deux « pistes » audio alternatives, l'une stéréo, l'autre surround).

Le format WAVE peut également embarquer des flux PCM « très haute définition » avec une profondeur d'échantillonnage sur 24 bits et des fréquences d'échantillonnage de 352,8 kHz à 384 kHz. Ce type de flux audio, nommé DXD, est souvent utilisé dans les étapes intermédiaires de production de fichiers DSD.

### Sociabilité

Le format WAVE est très largement géré par les logiciels et matériels audiovisuels. Il est devenu un standard de facto et demeure aujourd'hui encore le format de prédilection pour la production musicale et audiovisuelle broadcast et l'archivage du son, qu'il soit nativement numérique ou numérisé (voir les Recommandations pour la production et la conservation des objets audionumériques produites par l'IASA TC-04).

L'emploi du format WAVE a été conçu pour le système d'exploitation Windows et est supporté par Linux ; son équivalent pour les systèmes d'exploitation Apple est l'AIFF (non compressé) / AIFC (compressé).

### Relations à d'autres formats

**BWF (Broadcast Wave Format) :** l'EBU a standardisé une extension du format WAVE qui lui ajoute un nouveau chunk (bloc) de données permettant de renseigner des métadonnées utiles à la production broadcast comme le timecode, la localisation, ou encore l'ajout de remarques sur la qualité de prise de son.

**WAVE RF64,** également nommé MBWF : le format WAVE (et le BWF) est limité à une taille de fichier de 4 Gio, ce qui peut être problématique dans certains domaines. Cette limite a été repoussée à 16 Eio avec le format WAVE RF64 (ou MBWF). Ce format, bien que reposant sur le format WAVE, n'est cependant pas rétro-compatible et nécessite par conséquent un lecteur adapté.

**Sony WAVE64 :** le nom parfois utilisé de « WAVE64 » désigne une variante propriétaire de WAVE développée par Sony.

### Contenu

Le plus souvent, le format WAVE embarque des flux audio LPCM (linear pulse-code modulation) sans perte, mais il peut aussi contenir des flux audio compressés (avec perte) de type MP3, AC-3, MQA, ATRAC ou ADPCM. L'utilisation d'un conteneur WAVE pour transporter un flux audio compressé est néanmoins déconseillée : outre que le conteneur n'est pas particulièrement adapté à cette utilisation, elle peut induire en erreur l'utilisateur sur la nature du flux contenu.

Le format WAVE reposant sur RIFF, a une structure extensible. Il peut donc être enrichi de chunks comportant des données ou des métadonnées de nature très différente, éventuellement propriétaires. Ces données ne sont pas supportées par tous les lecteurs et outils de manipulation, mais elles ne compromettent généralement pas la lecture du flux audio.

### Organisme de maintenance et documentation de référence

La documentation du format RIFF/WAVE est accessible via les documents suivants :
<figure><img src="image_151.png" /></figure>

- Multimedia Programming Interface and Data Specifications 1.0 (voir pages 56-65);

- New Multimedia Data Types and Data Techniques (voir pages 12-22);

- Multiple Channel Audio Data and WAVE Files;

- Sur le WAVE RF64 : MBWF/RF64: An extended File Format for Audio, spécification technique EBUTech 3306, Genève : EBU/UER, 2009;

- Sur le WAVE RF64 : Long-form file format for the international exchange of audio programme materials with metadata, recommandation ITU-R BS.2088, International Telecommunications Union, 2019.

La British Library a réalisé une évaluation de ce format pour la préservation à long terme.

## Identifiants

Extension : généralement .wav, parfois .wave. Pour la variante RF64, .rf64.

Type MIME : Microsoft n'ayant pas soumis officiellement de RFC à l'IANA, plusieurs types MIME non officiels ont été adoptés :

- audio/vnd.wave;

- audio/wav;

- audio/wave;

- audio/x-wav.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q217570 pour le format de fichier RIFF/WAVE<br>Q3241497 pour le codec LPCM<br>Q3928266 pour le format de fichier WAVE RF64</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000001 pour le format de fichier RIFF/WAVE<br>fdd000011 pour le codec LPCM</td></tr><tr><td>PRONOM</td><td>fmt/6 pour le format RIFF/WAVE<br>fmt/712 pour le format RF64</td></tr><tr><td>Just Solve the File Format Problem</td><td>WAVE</td></tr></tbody></table>

## Caractéristiques techniques

Le flux audio LPCM étant non compressé, les fichiers RIFF/WAVE sont d'une taille conséquente (CPO-COM). Le format est donc particulièrement adapté dans les cas où l'espace de stockage n'est pas contraint et où, pour des besoins d'édition audio par exemple, les processus de compression / décompression sont problématiques.

Le format WAVE contenant un flux non compressé LPCM est le format audio le plus simple (CPO-SIM), et un des plus stables (CPO-STA). Il est également assez robuste, la plupart des lecteurs étant capables de restituer un flux audio partiellement altéré. Néanmoins, contrairement aux formats destinés à être diffusés en streaming comme MP3 et FLAC, il ne permet pas d'embarquer des empreintes numériques internes (CPO-ROB).

## Métadonnées internes

Le format WAVE peut embarquer des métadonnées internes selon le formalisme RIFF tags.

La Federal Agencies Digitization Guidelines Initiative produit une recommandation visant à insérer des métadonnées minimales d'identification dans les fichiers WAVE issus d'une numérisation. Le sous-ensemble des RIFF tags défini par ces recommandations est éditable par l'outil BWF MetaEdit.

Le format étant extensible, il arrive parfois que l'on trouve également des chunks comportant des métadonnées internes aux formats ID3 ou XMP.

## Outils connus par la BnF

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo, qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7.
<figure><img src="image_152.png" /></figure>

Le module WAVE du logiciel JHOVE permet de valider la conformité de la structure des fichiers RIFF/WAVE au regard des spécifications du format. Il est conseillé d'utiliser des versions du logiciel postérieures à la version 1.20, version à partir de laquelle il est capable d'identifier des fichiers WAVE tronqués. Néanmoins, le module ne contrôle pas le flux audio ; si ce dernier a été corrompu, JHOVE ne le signalera pas.

Plusieurs initiatives comme *Lossless Audio Checker* visent à élaborer des outils capables d'analyser si un flux dans un codec audio sans perte n'a effectivement pas subi d'opérations de sur-échantillonnage (*upsampling*) d'interpolation ou de conversion depuis un flux compressé. Ces outils sont pour la plupart encore à un stade de développement bêta.

## Usage ou présence dans les collections de la BnF

La migration de supports opérée par la BnF ou par des prestataires sur les CD audio (pressés) et les CD-R reçus par dépôt légal est à l'origine d'un très grand nombre de fichiers WAVE conservés par la BnF. D'autres fichiers de ce type peuvent aussi avoir été reçus en dépôt légal sous forme nativement dématérialisée.

La première campagne de numérisation du plan de sauvegarde de la BnF débuté en 1997 était conservée sur CD-R (Gold). L'ensemble de ces documents numérisés au format « CD » (LPCM - 16 bits - 44,1 kHz) a été par la suite transféré au format WAVE et stocké sur cartouches LTO.

Des fonds originaux de la BnF d'enregistrements musicaux, collectes, conférences et entretiens ont été enregistrés au format WAVE. Ils peuvent être issus de numérisation ou de recopie de supports numériques, comme par exemple de cassettes R-DAT.

Depuis 2009, l'ensemble des fichiers audio de numérisation patrimoniale sont au format WAVE (LPCM - 24 bits - 96 kHz). Pour des enregistrements de longue durée, les fichiers sont au format WAVE RF64. Pour des enregistrements devant conserver des informations de synchronisation par *timecode*, le format de fichier BWF a été retenu.
<figure><img src="image_153.png" /></figure>

## 4.40. WebVTT

### Description

Le format WebVTT (Web Video Text Tracks) est un format textuel qui fournit le contenu des sous-titres et leur positionnement temporel vis-à-vis d'une vidéo. Il est très répandu sur Internet.

Ce format est une recommandation du W3C et sert du format de référence pour les sous-titres référencés par la balise `<track>` du HTML5.

Directement inspiré du format SRT, il est simple, lisible et éditable par un humain.

### Qualité et caractéristiques du flux

Le format permet d'encoder un flux de sous-titres multi-voix et multilingues. Les sous-titres peuvent être associés à une langue et à une voix particulières, notamment pour leur définir un style particulier.

### Sociabilité

Le format WebVTT est directement intégrable dans les pages Web et sa manipulation programmatique ou stylistique sur les navigateurs est complètement définie, ce qui autorise les interactions ou les effets de style (en particulier, par le sélecteur `::cue`). Il est de plus très facile de passer du format SRT au WebVTT et réciproquement.

Les principaux usages envisagés par le W3C et explicités dans l'attribut `kind` de la balise `<track>` sont :

- Les sous-titres de transcription ou de traduction, typés *subtitles*;

- Les sous-titres pour les sourds et malentendants, typés *captions*;

- Les descriptions, typés *descriptions*.

### Relations à d'autres formats

Ce format est directement inspiré du SRT.

### Versions

La seule version disponible ayant le statut de recommandation est la version 1.

### Conteneur

Le format WebVTT se présente soit dans un fichier dédié, séparé du contenu vidéo associé, soit embarqué dans un fichier conteneur, notamment MKV (voir cet Internet draft).

### Contenu

Un fichier WebVTT est un fichier texte encodé en UTF-8.

Il possède un en-tête obligatoire (WEBVTT) suivi d'une zone d'en-tête optionnelle (qui peut porter des styles ou des notes) et poursuivi par une concaténation de blocs identiques qui portent les sous-titres :

numéro séquentiel du sous-titre
Temps de départ --> temps de fin
Texte du sous-titre (peut être sur plusieurs lignes)
[ligne vide]

Les temps de départ et de fin sont exprimés en respectant le format `HH:MM:SS.sss` (attention, c'est la principale différence avec le SRT puisque la séparation décimale est ici un point).

Les textes peuvent être stylés avec des balises `<b>`, `<i>`, `
`, `<u>` pour formater le texte. Il est possible de définir un positionnement du texte en ajoutant des styles CSS de positionnement sur la ligne des temps.

La balise `<v>` permet de spécifier la voix et la balise `<lang>` la langue, notamment pour les besoins d'accessibilité.

### Organisme de maintenance et documentation de référence

Le format est maintenu par le W3C qui publie sa recommandation.
<figure><img src="image_154.png" /></figure>

## Identifiants

Extension: `.vtt`

Type MIME: `text/vtt`

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q3566973</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000567</td></tr><tr><td>PRONOM</td><td>fmt/1454</td></tr><tr><td>Just Solve the File Format Problem</td><td>WebVTT</td></tr></tbody></table>

## Caractéristiques techniques

Contrairement au SRT, le format WebVTT peut devenir complexe si l'on veut utiliser toutes ses possibilités mais un usage basique est possible (CPO-SIM). Il est par ailleurs plutôt transparent (CPO-TRA) et indépendant (CPO-AUT).

Comme il s'agit d'un format textuel, il n'est pas très compact (CPO-COM) mais peut être très facilement et très efficacement compressé sans perte par des algorithmes de type Deflate.

Il n'inclut pas de mécanismes de protection (CPO-PRO).

Comme tout format en clair, il est relativement robuste (CPO-ROB) puisqu'il est aisé d'ignorer les parties non conformes ou de les réparer à la main avec un simple éditeur de texte.

## Métadonnées internes

Il est possible d'embarquer des métadonnées puisque la balise `<v>` ou que des blocs spécifiques de métadonnées (au format JSON) peuvent être intégrés, par exemple pour embarquer une localisation ou un lien vers des informations complémentaires.

Par ailleurs, il est possible d'ajouter des commentaires libres dans des blocs `NOTE`.

## Outils connus par la BnF

Le format est identifié par les outils [DROID](https://www.droidapp.com/) et [Unix file](https://www.unixfile.org/).

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est [MediaInfo](https://www.mediainfo.org/).

L'outil [ffmpeg](https://www.omanetix.com/) peut le prendre comme flux en entrée ou en sortie.

## Usage ou présence dans les collections de la BnF

La BnF ne collecte pas spécifiquement ce type de fichiers mais il en existe dans ses collections de collecte du Web.
<figure><img src="image_155.png" /></figure>

## 4.41. XML-ALTO

### Description et sociabilité

ALTO (*Analyzed Layout and Text Object*) est un schéma XML standardisé, qui permet de stocker les informations relatives à la structure physique et au texte extrait par OCR (*Optical Character Recognition* : reconnaissance optique de caractères) d'une page d'un document numérisé (livre, revue ou journal).

Très adapté à la conservation à long terme de ces données, ALTO a été adopté par de nombreuses institutions dans leur processus de conversion en mode texte de documents numérisés ; institutions au rang desquelles on compte la Bibliothèque du Congrès, l'Université de Harvard, les Bibliothèques nationales du Danemark, Finlande, France, Nouvelle-Zélande, Pays-Bas, Singapour, etc. (liste complète ici).

ALTO est au demeurant très utile pour l'exploitation et la valorisation des collections numériques. Les coordonnées matricielles qu'il contient peuvent par exemple servir de support à la génération de PDF multicouches ou au développement d'applications web de surlignage d'occurrences.

### Relations à d'autres formats

Un fichier ALTO est un fichier XML.

Il est conçu pour être utilisé comme un complément de [METS](https://www.w3.org/TR/mets/) (*Metadata Encoding and Transmission Schema*) lorsque celui-ci est employé pour décrire la mise en page reconnue par OLR. METS renseigne alors sur la structure logique de la page (nature sémantique des blocs de texte, par exemple titre, partie d'article, légende d'illustration, etc.), tandis qu'ALTO localise des contenants (blocs, lignes, etc.) sur la matrice de l'image de la page.

Lorsqu'ils coexistent, METS intègre dans sa `<structMap>` des références directes à des éléments de l'ALTO, des `<TextBlock>` par exemple. Mais les instances ALTO peuvent exister en tant que documents autonomes, indépendamment de METS. Sur l'utilisation conjointe d'ALTO et METS, on consultera cette page.

### Versions

Les schémas ALTO sont mis à jour avec des nombres entiers quand leurs modifications interrompent la compatibilité descendante (version 1 à 2, par exemple), et des décimales quand elles ne l'interrompent pas (4.0 à 4.1, par exemple). Depuis juin 2022, le schéma est dans sa version 4.3.

#### Versions antérieures :

- 4.2 (juillet 2020) ;

- 4.1 (mai 2019) ;

- 4.0 (janvier 2018) ;

- 3.1 (janvier 2016) ;

- 3.0 (août 2014) ;

- 2.1 (février 2014) ;

- 2.0 (janvier 2010) ;

- 1.4 (août 2007).

### Contenu

Un fichier XML ALTO est composé de trois sections principales, sous la racine `<alto>` :

- `<Description>` (voir infra, Métadonnées internes)

- `<Styles>

- `<Layout>

La section `<Styles>` liste les polices de composition reconnues par le moteur OCR, avec certaines de leurs caractéristiques (taille, couleur, graisse...), et des informations sur la morphologie des paragraphes.

La section `<Layout>` expose le contenu lui-même, par page (élément `<Page>`). Chaque page se compose d'un `<PrintSpace>` encadré par des marges haute, droite, basse et gauche : cinq aires rectangulaires qui ne peuvent pas se chevaucher, où se répartissent les objets graphiques (`<Illustration>` et `<GraphicalElement>`) ou textuels identifiés par le moteur OCR lors de ses opérations de segmentation. Les `<TextBlock>` sont les unités essentielles de ces derniers. Ils sont divisés en lignes (`<TextLine>`) où le caractère espace (`<SP>`) sert à séparer les chaînes de caractères (`<String>`) et où les traits d'union (`<HYP>`) sont identifiés comme séparateurs de chaînes devant être fusionnées.
<figure><img src="image_156.png" /></figure>

## Organisme de maintenance et documentation de référence

Depuis 2009, c'est un **Comité éditorial** mis en place par la Bibliothèque du Congrès qui est l'agent officiel de maintenance du schéma. Le Comité enrichit ce dernier et agit pour étendre son utilisation dans la communauté des bibliothèques numériques.

La documentation de référence est disponible sur le GitHub du Comité et les versions du schéma sont hébergées par la Bibliothèque du Congrès.

## Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q2819247</td></tr></tbody></table>

## Caractéristiques

Un fichier XML ALTO contient deux types d'informations géométriques sur les aires rectangulaires structurant la page océrisée : les coordonnées matricielles de leur coin supérieur gauche (attributs HPOS et VPOS) et leurs dimensions (attributs HEIGHT et WIDTH). L'exploitabilité de ces informations nécessite que l'ALTO soit accompagné, lors de son archivage, de l'image océrisée correspondante dans ses dimensions natives. Pour assurer a minima un lien avec cette dernière, il doit fournir dans sa section <sourceImageInformation> au sein de <Description> (voir infra, Métadonnées internes) un lien pérenne de récupération de cette image.

## Métadonnées internes

La section <Description> du fichier XML ALTO, enfant en première position de la racine <alto>, contient des métadonnées auto-descriptives ; entre autres : décompte d'éléments, logiciel OCR utilisé, et « taux OCR brut ». Ce taux exprime la confiance auto-évaluée du moteur à reconnaître les caractères et reconstituer les chaînes ; techniquement, il est la moyenne des valeurs des attributs WC (pour Word Confidence) de toutes les <String> et se renseigne dans une balise <processingStepDescription>.

## Outils connus par la BnF

ALTO étant un format XML, il est indispensable de disposer d'un éditeur XML complet pour le manipuler, le valider et l'éditer. La validation est réalisée à l'aide du **schéma XSD officiel**.

Comme outils de production, on citera ABBYY FineReader Engine®, qui équipe la chaîne interne d'océrisation de la BnF, et Tesseract (à partir de la version 4), libre et open source.

La caractérisation d'ALTO, comme celle des autres formats XML, est réalisée par le module XML de l'outil Jhove. L'option withTextMD permet de produire une sortie au format textMD.

## Usage ou présence dans les collections de la BnF

Le format ALTO est demandé par la BnF dans le cadre des prestations d'océrisation externes (cf. son référentiel OCR). C'est aussi le format produit par sa chaîne interne d'océrisation, active depuis avril 2019. Sa bibliothèque numérique Gallica l'exploite pour la recherche plein texte et la mise en surbrillance des mots recherchés.

La BnF a développé **son propre schéma**, dérivé de la version 2 d'ALTO et conforme à ce dernier. Documentation ici.
<figure><img src="image_157.png" /></figure>

## 4.42. XML-METS

### Description et sociabilité

Le format METS (pour Metadata Encoding and Transmission Standard) a été créé en 2001 par la Digital Library Federation afin de réunir dans un même fichier XML toutes les métadonnées nécessaires à la description d'un document numérisé. Depuis lors, son périmètre s'est étendu aux objets nativement numériques.

Pensé à l'origine dans une logique d'interopérabilité, son usage comme format d'échange entre bibliothèques numériques s'avère marginal. En revanche, il est massivement utilisé par les bibliothèques et les archives comme format conteneur de métadonnées pour décrire les paquets d'informations conservés dans un système de préservation numérique. La *liste des profils d'application METS officiels* fait état d'une cinquantaine d'implémentations, chiffre très en dessous de la réalité car de nombreuses institutions utilisatrices n'ont pas fait la démarche d'enregistrer leur profil. Parmi les principales implémentations METS comme fichier conteneur de métadonnées pour la préservation à long terme, on peut citer

- *Archivematica*, logiciel *open source* de préservation numérique ;

- *SPAR*, le magasin numérique de la BnF ;

- le projet européen *e-Ark* qui vise à définir des spécifications communes pour les paquets d'informations et à développer sur ce socle des outils de préservation numérique.

Enfin, il a été adopté par Europeana dans le cadre du projet *Europeana Newspapers* et par la BnF à sa suite pour encoder la disposition des contenus détectée grâce à des méthodes de reconnaissance optique de la mise en page (OLR).

### Relations à d'autres formats

Les fichiers METS sont des fichiers XML.

Dans son usage d'encodage de l'OLR, les spécifications d'Europeana et de la BnF ont fait le choix d'articuler METS et XML-ALTO : le fichier METS décrit dans sa carte de structure (élément `<structMap>`) des contenus intellectuels et fait référence à des éléments XML de l'ALTO qui décrivent des zones d'une page et donnent leur localisation dans les fichiers images.

### Versions

Depuis sa création en 2001, le format METS n'a pas subi de révision majeure. Les évolutions successives (au 13 mai 2020, la version en cours est la version 1.12.1) ont été mineures et rétrocompatibles (tous les fichiers METS produits depuis la naissance du format sont donc valides au regard de la version actuelle).

Le 18 novembre 2022, le *METS Editorial Board* annonce une version 2 et sollicite les retours de sa communauté d'utilisateur ice s sur les évolutions proposées et le schéma XML révisé. Le groupe annonce continuer à maintenir la version 1.

### Contenu

Les sections de métadonnées du format METS (métadonnées descriptives `<dmdSec>`, de provenance `<digiprovMD>`, de droits `<rightsMD>`, techniques `<techMD>` et de source `<sourceMD>`) sont extensibles : on peut y placer des métadonnées dans n'importe quel format XML, voire dans un format non XML comme du MARC ISO 2709. En particulier, il a été pensé en complémentarité directe avec d'autres standards développés par la communauté des bibliothèques numériques :

- pour les métadonnées de description du contenu intellectuel : *Dublin Core*, *EAD*, *MODS* ;

- pour les métadonnées de préservation (techniques et de provenance) : *PREMIS* ;

- pour les métadonnées techniques de caractérisation :

- *MIX* (images),

- *audioMD* et *videoMD* (contenus audiovisuels),

- *textMD* (contenus textuels).

Concernant le lien avec les fichiers de contenu (images, texte, contenus audiovisuels, etc.) décrits par le fichier METS, deux options existent, bien que la première option soit très majoritaire :

- pointer, dans le fichier METS, vers les fichiers par le biais d'un URI,

- encapsuler du contenu en XML ou en base64 directement dans les éléments `<file>`.

Via des éléments `<mptr>` (*METS pointer*), des fichiers METS peuvent également pointer sur d'autres fichiers METS. Cette fonctionnalité permet de décrire des collections référençant les documents numériques qui les composent.
<figure><img src="image_158.png" /></figure>

Le format METS pouvant référencer de nombreux contenus externes (CPO-AUT), il est nécessaire de veiller à la pérennité des liens et à la préservation de ces contenus. La solution la plus couramment adoptée est d'empaqueter dans un fichier conteneur le fichier METS et ses contenus référencés.

## Organisme de maintenance et documentation de référence

Le format METS est maintenu par un groupe international d'experts, le *METS Editorial Board*. Son [site web](https://www.mets.org/) et tous les contenus liés à METS sont hébergés par la Bibliothèque du Congrès.

La documentation de référence du format METS est constituée par le *METS Primer (manuel)*, fondé sur la version 1.6. Une [introduction en français aux principales caractéristiques du format](https://www.mets.org/) est également disponible.

Les deux usages principaux de METS à la BnF sont décrits par les référentiels de numérisation : le *référentiel d'enrichissement des métadonnées METS* pour les fichiers de métadonnées de numérisation (« manifestes ») et le *référentiel d'enrichissement du texte* pour l'encodage de l'OLR.

## Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q1640667</td></tr><tr><td>Just Solve the File Format Problem</td><td>METS</td></tr></tbody></table>

## Caractéristiques

L'unique format de sérialisation disponible pour METS est XML, bien qu'une expression en RDF soit à l'étude depuis 2011.

Comme pour tout autre format de métadonnées, chaque organisation productrice est fortement encouragée à définir et à documenter son utilisation à travers un profil d'application. Cette bonne pratique est si pertinente pour METS en raison de sa flexibilité que le comité éditorial METS a proposé [un formalisme de description en XML des profils d'application du format](https://www.mets.org/) . La version 2 de ce formalisme propose d'embarquer dans la description du profil des contrôles exécutables par machine.

Bien que théoriquement transparent pour un utilisateur humain (CPO-TRA), le format METS est considérablement compliqué par l'usage d'identifiants internes au fichier pour faire le lien entre les composantes de la structure du document numérique décrites dans la section `<structMap>`, leurs métadonnées dans les sections `<dmdSec>`, `<rightsMD>`, `<techMD>`, `<digiprovMD>` et `<sourceMD>` et leurs représentations numériques dans la section `<fileSec>`. Cette particularité rend la lecture et le contrôle manuel des fichiers METS laborieux.

## Métadonnées internes

Le format METS peut embarquer des métadonnées auto-descriptives (date de création, de dernière modification, agents ayant contribué à l'élaboration du fichier) dans son élément initial `<metsHdr>` (en-tête).

## Outils connus par la BnF

METS étant un format XML, il est indispensable de disposer d'un éditeur XML complet pour le manipuler, le valider et l'éditer.

## Fichiers METS manifestes de Paquets d'informations

Certains utilisateurs ont développé des outils spécifiquement pour METS, mais en raison de la flexibilité du format, ces derniers restent généralement très liés au profil d'application pour lequel ils ont été conçus. On peut cependant citer pour la visualisation l'outil *METS Flask* développé par la société Artefactual dans son produit Archivematica. Un fork de cet outil a été fait pour l'adapter au profil BnF : *METS Viewer*.

## Fichiers METS d'OLR

L'outil *Structify*, développé par l'université d'Innsbruck et utilisé par Europeana dans le cadre du projet Europeana Newspapers, permet de réaliser la correction des contenus identifiés par OLR, d'y ajouter des métadonnées et d'exporter le résultat au format METS. La plateforme de transcription et d'annotation *Transkribus* permet également d'importer et d'exporter des documents METS.

## Caractérisation
<figure><img src="image_159.png" /></figure>

La caractérisation de METS, comme celle des autres formats XML, est réalisée par le module XML de l'outil Jhove. L'option withTextMD permet de produire une sortie au format textMD.

## Validation

La validation est réalisée à l'aide du schéma XSD officiel et de tous autres schémas de métadonnées contenues dans le fichier METS. Un profil d'application METS complète généralement ces exigences ; les contraintes qu'il édicte peuvent être encodées dans le langage schematron et embarquées dans un profil METS « actionnable » (c'est la méthode adoptée par la BnF, voir les profils METS BnF pour la numérisation).

## Usage ou présence dans les collections de la BnF

Depuis la mise en production de son magasin numérique SPAR en 2010, la BnF utilise METS comme format pivot de métadonnées pour enregistrer toutes les métadonnées techniques, de structure et de provenance utiles à la préservation à long terme au sein d'un paquet d'informations.

Depuis 2015, l'utilisation de METS s'est étendue :

- pour les nouveaux marchés de numérisation, en remplacement de l'ancien format maison « refnum », comme format conteneur de métadonnées de numérisation ;

- pour l'encodage de l'OLR appliqué à ses périodiques numérisés.
<figure><img src="image_160.png" /></figure>

## 4.43. XML-tdmNum

### Description

Le format tdmNum est développé et utilisé par la BnF pour la transcription des tables et index présents dans les ouvrages numérisés. Cette transcription reproduit la structure logique des contenus, identifie les intitulés des entrées ainsi que leurs liens vers le corps des ouvrages. Elle permet également de repérer les entités (personne, toponyme, organisation) éventuellement nommées dans les intitulés.

### Sociabilité

Ce format n'est utilisé que dans le contexte des activités de numérisation de la BnF et de ses partenaires. Pour ces derniers, le respect de ce format garantit que leurs tables et index seront intégrés dans la chaîne d'entrée des documents numériques de la BnF et valorisés dans Gallica.

### Relations à d'autres formats

Le format tdmNum est une restriction du format TEI, lui-même schéma de données structurées en XML. La sémantique du jeu de balises utilisé est décrite dans le référentiel de numérisation (voir ci-après).

### Versions

Seule la version 1.1 du format tdmNum est utilisée.

### Organisme de maintenance et documentation de référence

Le format est maintenu par la BnF, diffusé sur le site bibnum.bnf et décrit dans un des référentiels de numérisation de la BnF, Traitement des tables.

### Identifiants

Ce format local n'a pas reçu d'identifiant international.

### Métadonnées internes

Le format tdmNum n'embarque pas de métadonnées internes, si ce n'est l'identifiant du document numérique dont il décrit la table des matières ou l'index.

### Outils connus par la BnF

La validation du format est réalisée par le moyen d'un schéma XSD.

La caractérisation de tdmNum, comme celle des autres formats XML, est réalisée par le module XML de l'outil Jhove. L'option withTextMD permet de produire une sortie au format textMD.

### Usage ou présence dans les collections de la BnF

Ce format est en usage dans le cadre des marchés et programmes de numérisation de la BnF. Il sert à transcrire les tables et index des ouvrages numérisés ainsi que les plages des enregistrements sonores.

La fonctionnalité de navigation au sein des documents de Gallica (exemple sur un ouvrage imprimé, exemple sur un document sonore) utilise les transcriptions produites selon ce format.
<figure><img src="image_161.png" /></figure>

## 4.44. ZIP (conteneur générique)

### Description

ZIP est un format de fichier conteneur générique permettant d'empaqueter et, éventuellement, de compressor **sans perte** un ensemble de fichiers. Le format utilise, dans la grande majorité des cas, l'algorithme de compression sans perte Deflate, méthode de compression simple et générique qui agit sur la redondance des données.

Le format a été créé en 1989 par Phil Katz pour son logiciel PKZIP. Dès sa création, sa spécification a été publiée (CPO-DOC) et son utilisation a été laissée libre (CPO-LIB).

### Sociabilité

L'utilisation du format ZIP est massive dans tous les secteurs. Ce format a longtemps été majoritairement employé par les systèmes Windows - par un *add-on* à Windows 98, puis nativement à partir de Windows ME -, tandis que ceux fondés sur Unix (GNU/Linux et Mac OS) lui préféraient des paquets TAR compressés avec les algorithmes GZIP et BZIP2. Désormais, même les systèmes d'exploitation fondés sur Unix gèrent nativement le format ZIP.

### Relations à d'autres formats

ZIP a été utilisé comme format conteneur pour de nombreux formats spécialisés : OpenDocument Format, EPUB, Office Open XML, programmes Java, APK, MUSX etc.

### Versions

Le format, introduit en 1989, est relativement **stable** (CPO-STA). Des évolutions se sont succédées jusqu'à la version 6.3.9 (juillet 2020). On peut citer les évolutions majeures suivantes :

- Version 4.5 (2001) : documentation d'une version 64 bits (parfois appelée « Zip64 »);

- Version 5.2 (2003) : gestion du chiffrement AES;

- Version 6.3.0 (2006) : gestion d'UTF-8 pour l'encodage des noms de fichiers.

Dans l'en-tête du fichier, on trouve deux éléments de métadonnées indiquant la version du logiciel qui a créé le fichier (*version made by*) et celle minimale pour en réaliser l'extraction (*version needed to extract*).

### Contenu

Le format ZIP peut empaqueter des fichiers de n'importe quel format (*on notera que la commande Unix unzip -l monfichier.zip permet de lister tous les fichiers contenus dans un conteneur ZIP*). Une particularité du format ZIP est qu'il peut embarquer des fichiers ayant strictement le même chemin, ce qui peut poser des problèmes à l'extraction.

La structure du format, qui spécifie à la fin du ZIP un répertoire central listant les noms de fichiers contenus, est dictée par les contingences de la fin des années 1980, où des contenus volumineux devaient être stockés sur plusieurs disquettes. Ce répertoire permettait d'indiquer sur quelles disquettes le fichier désiré par l'utilisateur ice était stocké. Cette structure a en outre l'avantage de permettre l'ajout de nouveaux fichiers à un ZIP existant par l'écriture à la suite des enregistrements précédents et la réécriture du répertoire central.

Chaque enregistrement étant compressé séparément, il peut avoir sa propre méthode de compression.

Pour plus de détails sur la structure du format et les algorithmes de compression utilisés, on pourra se reporter au billet suivant :

Wennborg, Hans. « Zip Files: History, Explanation and Implementation » WWW.Hanshq.Net, 26 février 2020, disponible sur [https://www.hanshq.net/zip.html](https://www.hanshq.net/zip.html).

### Organisme de maintenance et documentation de référence

Le format ZIP est toujours maintenu par la société PKWARE qui publie une *Application note* régulièrement révisée comme spécification de ce format.

Une restriction du format ZIP, basée sur la version 6.3.3, limitant la méthode de compression à Deflate et interdisant le chiffrement, a été normalisée à l'ISO sous l'identifiant ISO/IEC 21320-1 en 2015. Cette norme est diffusée gratuitement.
<figure><img src="image_162.png" /></figure>

## Identifiants

Extensions: `.zip`, `.ZIP`

Type MIME: `application/zip`

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q136218 et Q26211840 pour le profil ISO</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000354, fdd000355 version 6.2.0, fdd000362 version 6.3.3, et fdd000361 pour le profil ISO</td></tr><tr><td>PRONOM</td><td>x-fmt/263</td></tr><tr><td>Just Solve the File Format Problem</td><td>ZIP et Zipx</td></tr></tbody></table>

## Caractéristiques techniques

**Compacité (CPO-COM)**: le format est compatible avec un nombre important de méthodes de compression, mais la méthode Deflate est la plus utilisée. Il est possible de n'utiliser que la fonctionnalité d'empaquetage, sans mettre en œuvre de compression. Cette option est recommandée si les données contenues ont déjà fait l'objet d'une compression. Ainsi est-il inutile de réappliquer une compression Deflate sur des fichiers MPEG-1/2 layer 3 qui ont déjà subi une compression mieux adaptée à leur type de contenu audio. En revanche, la volumétrie d'un fichier ZIP contenant des données non compressées (par exemple, fichiers TIFF sans compression, fichiers XML, etc.) sera fortement réduite. Les outils de manipulation ZIP ont pour habitude d'indiquer par l'extension `.zipx` que la méthode de compression est autre que Deflate.

**Robustesse (CPO-ROB)**: le format ZIP embarque une empreinte numérique CRC-32 des fichiers contenus. Cette fonctionnalité permet d'identifier des altérations sur tout ou partie du contenu. Si une méthode de compression a été appliquée, l'empreinte correspond à la version non compressée. Il est donc nécessaire de décompresser les contenus pour contrôler l'intégrité, ce que font généralement les logiciels qui manipulent ZIP. L'option `-T` de la commande zip permet de tester l'intégrité du contenu du fichier ZIP. En outre, en cas d'altération du conteneur, une option `-F / --fix` permet d'ignorer les enregistrements corrompus et produit un ZIP valide, donc à nouveau lisible (et une option `-FF` si la précédente ne fonctionne pas).

**Mécanismes de protection (CPO-PRO)**: la spécification définit une simple protection par mot de passe (ZipCrypto), connue pour être aisément contournable, puis, à partir de sa version 5.2, elle ajoute la norme AES. La protection est réalisée unitairement sur chaque fichier embarqué, ce qui implique qu'un fichier ZIP peut contenir des fichiers protégés et d'autres qui ne le sont pas. En outre, si le contenu du fichier est protégé, le nom du fichier reste lisible.

On notera pour mémoire le risque de sécurité introduit par des fichiers ZIP malveillants : des **bombes de décompression** dont la volumétrie est très réduite mais qui, une fois décompressées, occupent un espace considérable, ce qui peut geler les systèmes.

## Métadonnées internes

Le répertoire central permet de conserver l'ensemble des métadonnées associés aux fichiers contenus (nom, longueur, date de modification, CRC32, poids compressé et décompressé, etc.). Il est également possible d'ajouter un commentaire (champ *comment*) à un niveau global et au niveau de chaque fichier contenu.

Enfin, un mécanisme d'extension (*extra field*) permet d'ajouter des informations mais rend leur utilisation tributaire d'un logiciel particulier. À titre d'exemple, on peut citer l'extension FWKCS (code `0x4b46`) qui ajoute l'empreinte MD5 des fichiers.

## Outils connus par la BnF

Bien que l'outil WinZip ait été longtemps hégémonique, il existe désormais de multiples outils qui gèrent le format ZIP, dont des outils libres comme PeaZIP ou 7-ZIP. Un ensemble d'utilitaires pour manipuler les fichiers ZIP, **Info-ZIP** est également disponible sur les principaux systèmes d'exploitation. Enfin, la plupart des langages, notamment Java (java.util.zip) et Python (zipfile), disposent de bibliothèques de base dédiées pour le traitement de ce format.
<figure><img src="image_163.png" /></figure>

La commande Unix *zip* permet de créer, d'extraire, d'éditer, de tester (option -T) et de corriger (-F ou -FF) des fichiers ZIP.

## Usage ou présence dans les collections de la BnF

Des fichiers ZIP sont présents dans les collections de la BnF - ne serait-ce que parce que ce format est la base de très nombreux autres (EPUB, DOCX, ODS, APK, etc.). En outre, tous les Paquets d'informations produits par des prestataires de numérisation et livrés à la BnF le sont sous forme de conteneurs ZIP.
<figure><img src="image_164.png" /></figure>

## 4.45. Fichiers système

On décrit ici brièvement un ensemble de fichiers produits par les systèmes d'exploitation (par opposition aux utilisateurs) pour leur usage interne. Ces fichiers ont un statut ou une fonction particulière vis-à-vis du système. Bien que certains d'entre eux puissent être reconnus par les outils d'identification comme **DROID** grâce à une signature numérique, et que d'autres disposent d'un type MIME et d'une documentation, la plupart doivent être identifiés par leur nom. En effet, les systèmes d'exploitation peuvent être amenés à en changer le format entre deux versions tout en en conservant le nom et la fonction. Dans une perspective de préservation numérique, on se contentera en général d'ignorer ces fichiers, bien qu'une analyse inspirée de la **criminalistique numérique (digital forensics)** puisse y trouver des indices utiles à la compréhension du contexte de création des données.

Cette fiche décrit uniquement les fichiers produits par les systèmes d'exploitation ; on consultera la fiche **Fichiers spécifiques à une application** pour les fichiers techniques dits **sidecar** produits par les applications pour leur bon fonctionnement.

Les fichiers et répertoires sont identifiés par leur nom ; il arrive que le nom intègre des parties variables, qui sont marquées dans les noms ci-dessous par le caractère joker "*", qui vaut 0 à n occurrences de n'importe quels caractères.

**Note :** comme les autres systèmes basés sur Unix (GNU/Linux, BSD, etc.), les systèmes macOS utilisent le caractère . en début de nom de fichier pour identifier un fichier ou un répertoire caché. Ces derniers sont donc invisibles par défaut pour les utilisateurs de ces systèmes mais apparaissent sur les systèmes de fichiers Windows à la suite d'une copie. Il s'agit souvent, mais pas toujours, de fichiers générés par le système ou les applications.

### Fichiers de bases de données de vignettes ( thumbnails )

Sous Windows, le plus courant de ces fichiers est nommé **Thumbs.db** (QID : **Q930281**, PUID : **fmt/682**). Il s'agit d'un fichier de base de données stockant les vignettes des images d'un répertoire, permettant ainsi à l'explorateur Windows d'afficher plus rapidement un aperçu sous forme de mosaïque.

Il est souvent plus aisé de les supprimer en passant par l' invite de commande plutôt que par l' interface graphique. On pourra utiliser la ligne de commande DOS suivante pour ce faire : **del /A:H Thumbs.db**.

On notera également que, sous la variante du système d'exploitation **Windows XP Édition Media Center**, des fichiers **ehthumbs.db** sont créés pour stocker des vignettes de vidéos. Dans le même but, Windows Vista crée des fichiers **ehthumbs_vista.db**.

### Fichiers de configuration de l'affichage des répertoirs

Il s'agit d'un fichier texte de configuration d'un répertoire, localisé à sa racine, permettant notamment de lui associer une icône ou une info-bulle, de configurer l'affichage des fichiers, etc. Ce fichier peut être ignoré/exclu.

- `[dD]esktop.ini` (Windows) (QID : **Q4037242**);

- `.DS_Store` (Desktop Services Store) (macOS) (QID : **Q307271**, PUID : **fmt/394**);

- `.directory` (KDE/Dolphin).

En outre, on peut trouver, dans les données issues de systèmes macOS, un fichier caché à la racine du répertoire, nommé **Icon\r** (r représentant le caractère **carriage return**) et contenant l'icône personnalisée d'un répertoire. Un fichier caché ayant la même fonction, mais pour les volumes (c.-à-d. les disques et partitions), porte le nom **.VolumeIcon.icns** à partir de Mac OS X.

### Répertoirs de corbeille

Ces répertoirs contiennent des fichiers supprimés par l'utilisateur ice, qui n'a donc généralement pas conscience de les avoir transmis. Si leur conservation peut être utile aux chercheurs se s, elle pose des questions éthiques qu'il n'est pas évident de résoudre.

- `$Recycle.bin/RECYCLER` (Windows);

- `.Trash/ .Trashes` (macOS);

- `.Trash-*` (GNU/Linux) - où la partie qui suit le tiret correspond à l'identifiant de l'utilisateur ice qui a supprimé le(s) fichier(s).
<figure><img src="image_165.png" /></figure>

## Fichiers temporaires liés à un fichier en cours de suppression

Ces fichiers sont créés lorsqu'on supprime un fichier en cours d'utilisation par une application. Cela permet à l'application (ignorante du caractère distant du fichier) de le maintenir ouvert alors qu'il n'existe déjà plus à distance. Lorsque l'outil termine sa tâche, ce fichier temporaire est normalement supprimé, mais il peut arriver qu'il subsiste.

- `.fuse_hidden*` (GNU/Linux et macOS);

- `.nfs` [numéro en hexadécimal] (système de fichiers NFS).

On peut a priori les supprimer.

## Fichiers d'attributs étendus

Outre les attributs normaux (poids du fichier, date de création, de dernière modification, etc.), certains systèmes d'exploitation utilisent, par défaut ou sous réserve d'activation, des attributs étendus permettant de stocker des métadonnées supplémentaires ne faisant pas partie du fichier lui-même (outil de création, somme de contrôle, etc.). Lorsque des fichiers disposant d'attributs étendus sont copiés sur un système de fichiers différent, il arrive que ces attributs soient inscrits dans un fichier *sidecar*, généralement nommé selon le nom du fichier de données.

Les systèmes d'exploitation natifs suppriment ces fichiers lorsque leur fichier de données est supprimé, mais ils peuvent subsister sans ce dernier si sa suppression a été faite sous un autre système d'exploitation.

Le plus souvent, on peut les ignorer, mais une analyse forensique pourra y trouver des informations intéressantes (par exemple, pour un fichier téléchargé depuis le web, URL, date et outil de téléchargement - voir à ce sujet *ce billet*). Ils sont consultables à l'aide de l'utilitaire Unix `xattr` ou, pour macOS, avec la commande `ls -l@`.

- Resource forks (macOS)

Les systèmes macOS stockent les données dans deux *forks*, l'une contenant les données du fichier proprement dites (*data fork*), l'autre (*resource fork*) embarquant un certain nombre d'éléments dont des attributs utiles au gestionnaire de fichiers Finder mais aussi, dans les systèmes macOS des années 1980-90, le format de fichier et l'outil de création (*type/creator codes*), voir à ce propos *cet article*) et éventuellement toutes sortes de contenus graphiques ou audiovisuels nécessaires à l'utilisation du contenu. Ainsi, *l'atome moov* de certains anciens fichiers Quicktime était stocké dans la *resource fork* et, si cette dernière n'est pas récupérée, le contenu peut s'avérer illisible - voir à ce propos *cet article*.

Lorsque ces données devaient être transférées sur d'autres systèmes de fichiers, il était nécessaire de transmettre les deux *forks* ensemble. Plusieurs formats ont été créés pour cela : *MacBinary*, *BinHex* et *AppleSingle* (type MIME : *application applefile*, PUID : *fmt/967* et *fmt/968*) qui réunissent en un seul fichier les deux *forks*.

En complément, le format *AppleDouble* (type MIME : *multipart/appledouble*, PUID : *fmt/966* et *fmt/503*) enregistre la *resource fork* et les attributs du fichier dans un fichier distinct, caché, dont le nom commence par « `._` » suivi par le nom du fichier de données auquel il est associé. Les fichiers *AppleDouble* sont parfois créés dans un répertoire caché, situé dans le répertoire contenant les fichiers de données, nommé `.AppleDouble` ou `_MACOSX`. L'utilitaire macOS `dot_clean` permet de fusionner les fichiers contenant la *data fork* et la *resource fork*.

À partir de Mac OS X, la pratique de placer des ressources nécessaires au fonctionnement des contenus dans la *resource fork* est déconseillée, cette dernière n'étant plus utilisée que pour les attributs étendus.

- Flux de données alternatifs (Alternate Data Streams) (Windows)

Le système de fichiers *NTFS* permet de créer des *flux alternatifs* à des fichiers. L'usage attendu était le même que celui des *resource forks* mis en place sur les systèmes macOS antérieurs à OS X, mais, du fait du caractère presque invisible des données dans l'explorateur de fichiers, ces flux alternatifs ont été utilisés pour produire des logiciels malveillants. On peut néanmoins les afficher à l'aide de la commande `dir /R` dans l' invite de commande. Lors d'une copie vers un autre système de fichiers, ces données peuvent apparaître comme un fichier à part, nommé de la façon suivante : `[nom du fichier maître]:[attribut]`. De ce fait, il arrive que des fichiers `Thumbs.db:encryptable` apparaissent sur certains supports.
<figure><img src="image_166.png" /></figure>

## Raccourcis / liens

Ces fichiers d'un type particulier ne sont pas à proprement parler des fichiers système - ils peuvent avoir été créés volontairement par l'utilisateur ice. Il s'agit de pointeurs vers un fichier ou un répertoire accessible à un autre emplacement (mais ils peuvent également contenir des paramètres à passer à l'application cible). Il est possible d'en lire le contenu pour extraire le chemin du fichier cible sur le système de fichiers d'origine, en particulier si ce fichier cible n'est plus accessible à la suite d'une copie. Leur nom et leur identification dépendent du système d'exploitation qui les a créés.

- Sous Windows ils sont appelés « raccourcis », ils sont repérables à leur extension `.lnk` (PUID : [x-fmt/428](https://www.microsoft.com/en-us/Windows/Tools/x-fmt/428), type MIME non officiel `application/x-ms-shortcut`).

- Leurs équivalents sous GNU/Linux sont les **liens symboliques** et les **liens physiques**. Leur identification est actuellement complexe puisque leur nommage est totalement libre et qu'ils ne disposent pas actuellement (janvier 2025) d'entrée dans le registre PRONOM.

## Autres fichiers et répertoires Windows

### System Volume Information

Ce répertoire contient des informations utiles à l'outil de restauration du système. Il n'y a pas, à notre connaissance, d'information utile à en tirer.

## Autres fichiers et répertoires Mac

- `.Spotlight-V100`

Ce fichier est créé afin d'accélérer des recherches dans les répertoires avec le gestionnaire de fichiers Finder. Sa suppression ne pose pas de problème et il ne contient pas d'information significative.

- `.LSOverride`

Ce fichier est créé par le gestionnaire de fichiers Finder (macOS) pour conserver le chemin vers une application devant ouvrir par défaut le répertoire.

- **Fichiers et répertoires générés par le protocole AFP**

Le protocole AFP est utilisé par les systèmes macOS pour partager des fichiers sur le réseau. Il peut générer les fichiers ou répertoires suivants :

- Fichier `.apDisk` (informations liées aux répertoires partagés) ;

- Répertoire `.TemporaryItems / Temporary Items / _Temporary Items` (données temporaires créées au moment de la copie / du déplacement de fichiers) ;

- Répertoire `Network Trash Folder` (corbeille).
<figure><img src="image_167.png" /></figure>

5. Pour aller plus loin

Une liste de ressources a été produite par la Bibliothèque du Congrès : *Related Resources for Digital Format Sustainability*, disponible sur [https://www.loc.gov/preservation/digital/formats/intro/resources.shtml](https://www.loc.gov/preservation/digital/formats/intro/resources.shtml).

5.1. Sources d'information sur les formats de données dans une perspective de préservation

- Bibliothèque du Congrès, *Format Descriptions* :
[https://www.loc.gov/preservation/digital/formats/fdd/descriptions.shtml](https://www.loc.gov/preservation/digital/formats/fdd/descriptions.shtml)

- Wiki, *Solve the file format problem* : [http://fileformats.archiveteam.org/wiki/Main_Page](http://fileformats.archiveteam.org/wiki/Main_Page)

- Digital Preservation Coalition, *Endangered Species* : [https://www.dpconline.org/our-work/bit-list](https://www.dpconline.org/our-work/bit-list)

- Harvard University Libraries, *Format Assessments* :
[https://wiki.harvard.edu/confluence/display/digitalpreservation/Format+Assessments](https://wiki.harvard.edu/confluence/display/digitalpreservation/Format+Assessments)

- British Library, *File Formats Assessments* :
[http://wiki.dpconline.org/index.php?title=File Formats Assessments](http://wiki.dpconline.org/index.php?title=File Formats Assessments)

- *National Archives and Records Administration (États-Unis)* : [https://github.com/usnationalarchives/digital-preservation](https://github.com/usnationalarchives/digital-preservation)

- *File-extensions.org* (liste d'extensions associées à des outils logiciels pour lire, écrire, convertir, etc. les fichiers) : [https://www.file-extensions.org/](https://www.file-extensions.org/)

**5.2. Documents de politique formats publiés par les institutions de conservation**

- Archives nationales (France) : [https://www.archives-nationales.culture.gouv.fr/strategie-de-perennisation-des-archives-nationales](https://www.archives-nationales.culture.gouv.fr/strategie-de-perennisation-des-archives-nationales)

- Bibliothèque et archives nationales du Québec : [https://numerique.banq.qc.ca/patrimoine/details/52327/4076856](https://numerique.banq.qc.ca/patrimoine/details/52327/4076856)

- Centre de coordination pour l'archivage à long terme de documents électroniques (CECO, Suisse) : [https://kost-ceco.ch/cms/kad_main_fr.html](https://kost-ceco.ch/cms/kad_main_fr.html)

- *Libraries and Archives Canada* : [https://library-archives.canada.ca/eng/services/government-canada/information-disposition/managing-government-records/guidelines-information-management/Pages/guidelines-file-formats-enduring-value.aspx?wbdisable=true](https://library-archives.canada.ca/eng/services/government-canada/information-disposition/managing-government-records/guidelines-information-management/Pages/guidelines-file-formats-enduring-value.aspx?wbdisable=true)
- **Bibliothèque du Congrès** : [https://www.loc.gov/preservation/resources/rfs/](https://www.loc.gov/preservation/resources/rfs/)

- *National Digital Library (Finlande)* : [http://digitalpreservation.fi/files/File-Formats-1.6.1-en.pdf](http://digitalpreservation.fi/files/File-Formats-1.6.1-en.pdf)

- *National Archives and Records Administration (États-Unis)* : [https://www.archives.gov/records-mgmt/policy/transfer-guidance-tables.html](https://www.archives.gov/records-mgmt/policy/transfer-guidance-tables.html)

- *National archives of the Netherlands*, version 1.0, novembre 2016. : [https://www.nationaalarchief.nl/sites/default/files/field-file/National%20Archives%20of%20the%20Netherlands%20preferred%20and%20acceptable%20formats.pdf](https://www.nationaalarchief.nl/sites/default/files/field-file/National%20Archives%20of%20the%20Netherlands%20preferred%20and%20acceptable%20formats.pdf)

- Référentiel général d'interopérabilité version 2 (bien qu'orienté vers l'interopérabilité et la diffusion) : [https://www.numerique.gouv.fr/publications/interoperabilite/](https://www.numerique.gouv.fr/publications/interoperabilite/)

- *Smithsonian Institution Archives, Recommended Preservation Formats for Electronic Records* : [https://siarchives.si.edu/what-we-do/digital-curation/recommended-preservation-formats-electronic-records](https://siarchives.si.edu/what-we-do/digital-curation/recommended-preservation-formats-electronic-records)