FreeToGenerate.com

Un fichier dit ce qu’il est dans ses premiers octets. Certains formats les fixent dans une norme ; d’autres ne les ont jamais écrits. Rien n’est envoyé.

Identifier un fichier

Déposez un fichier ici, ou choisissez-en un.

Seuls les premiers octets sont lus, et ils le sont dans votre navigateur. Le fichier n’est pas envoyé et ne quitte pas votre machine.

norme
15
informatif
1
doc. de l’éditeur
14
convention seule
3
33 / 33
PNGnorme.pngimage/png
89 50 4E 47 0D 0A 1A 0A·PNG····À l’octet 0 (le début)

Écrit dans: ISO/IEC 15948 §5.2

La norme actuelle énonce ces huit octets sans dire pourquoi. L’explication — un premier octet non ASCII pour attraper un transfert qui efface le bit de poids fort, un CR-LF pour attraper la conversion des fins de ligne, un control-Z pour empêcher MS-DOS de déverser le fichier, et un saut de ligne final pour le problème inverse — ne survit que dans le RFC informatif que la norme a remplacé.

JPEGnorme.jpg .jpegimage/jpeg
FF D8 FF···À l’octet 0 (le début)

Écrit dans: ITU-T T.81 §B.1 (SOI marker)

Seuls les premiers octets sont fixes. La suite varie selon l’encodeur, d’où une signature plus courte que la plupart.

GIF 87adoc. de l’éditeur.gifimage/gif
47 49 46 38 37 61GIF87aÀ l’octet 0 (le début)

Écrit dans: GIF 87a, Header block

Deux versions du format partagent un préfixe : la version fait donc partie de la signature au lieu d’être lue après.

GIF 89adoc. de l’éditeur.gifimage/gif
47 49 46 38 39 61GIF89aÀ l’octet 0 (le début)

Écrit dans: GIF 89a §17 (Header)

Deux versions du format partagent un préfixe : la version fait donc partie de la signature au lieu d’être lue après.

BMPdoc. de l’éditeur.bmp .dibimage/bmp
42 4DBMÀ l’octet 0 (le début)

Écrit dans: Microsoft BITMAPFILEHEADER (bfType)

WebPnorme.webpimage/webp
52 49 46 46RIFFÀ l’octet 0 (le début)

Écrit dans: RFC 9649 §2 (RIFF container)

RIFF est un conteneur, pas un format. WebP, WAV et AVI sont identiques octet pour octet ici ; les quatre octets qui les séparent viennent ensuite.

TIFF (little-endian)doc. de l’éditeur.tif .tiffimage/tiff
49 49 2A 00II*·À l’octet 0 (le début)

Écrit dans: TIFF 6.0 §2 (Image File Header)

TIFF (big-endian)doc. de l’éditeur.tif .tiffimage/tiff
4D 4D 00 2AMM·*À l’octet 0 (le début)

Écrit dans: TIFF 6.0 §2 (Image File Header)

ICOconvention seule.icoimage/vnd.microsoft.icon
00 00 01 00····À l’octet 0 (le début)

Écrit dans: rien de normatif

Photoshopdoc. de l’éditeur.psdimage/vnd.adobe.photoshop
38 42 50 538BPSÀ l’octet 0 (le début)

Écrit dans: Adobe Photoshop File Formats, File Header

PDFnorme.pdfapplication/pdf
25 50 44 46 2D%PDF-À l’octet 0 (le début)

Écrit dans: ISO 32000-2 §7.5.2 (File header)

La signature est du texte lisible et non du binaire, ce qui explique que ces fichiers survivent souvent à une ouverture dans un éditeur de texte.

RTFdoc. de l’éditeur.rtfapplication/rtf
7B 5C 72 74 66{\rtfÀ l’octet 0 (le début)

Écrit dans: Microsoft RTF Specification

La signature est du texte lisible et non du binaire, ce qui explique que ces fichiers survivent souvent à une ouverture dans un éditeur de texte.

ZIPdoc. de l’éditeur.zipapplication/zip
50 4B 03 04PK··À l’octet 0 (le début)

Écrit dans: PKWARE APPNOTE §4.3.7 (local file header)

Un .docx, un .xlsx, un .jar, un .apk et un .epub sont tous des archives ZIP et portent tous ces octets. Les distinguer suppose d’ouvrir l’archive et de regarder ce qu’elle contient.

gzipnorme.gzapplication/gzip
1F 8B··À l’octet 0 (le début)

Écrit dans: RFC 1952 §2.3.1 (ID1, ID2)

bzip2convention seule.bz2application/x-bzip2
42 5A 68BZhÀ l’octet 0 (le début)

Écrit dans: rien de normatif

XZdoc. de l’éditeur.xzapplication/x-xz
FD 37 7A 58 5A 00·7zXZ·À l’octet 0 (le début)

Écrit dans: The .xz File Format §2.1.1.1 (Header Magic Bytes)

7-Zipconvention seule.7zapplication/x-7z-compressed
37 7A BC AF 27 1C7z··'·À l’octet 0 (le début)

Écrit dans: rien de normatif

RAR 5doc. de l’éditeur.rarapplication/vnd.rar
52 61 72 21 1A 07 01 00Rar!····À l’octet 0 (le début)

Écrit dans: RAR archive format documentation

tar (ustar)norme.tarapplication/x-tar
75 73 74 61 72ustarÀ l’octet 257

Écrit dans: POSIX.1-2017 (ustar Interchange Format)

Celle-ci ne commence pas au début du fichier : tout ce qui ne lit que les premiers octets la manque complètement.

ISO 9660norme.isoapplication/x-iso9660-image
43 44 30 30 31CD001À l’octet 32769

Écrit dans: ECMA-119 §8.4.1 (Standard Identifier)

Celle-ci ne commence pas au début du fichier : tout ce qui ne lit que les premiers octets la manque complètement.

WAVdoc. de l’éditeur.wavaudio/vnd.wave
52 49 46 46RIFFÀ l’octet 0 (le début)

Écrit dans: RFC 2361 / Microsoft RIFF

RIFF est un conteneur, pas un format. WebP, WAV et AVI sont identiques octet pour octet ici ; les quatre octets qui les séparent viennent ensuite.

AVIdoc. de l’éditeur.avivideo/vnd.avi
52 49 46 46RIFFÀ l’octet 0 (le début)

Écrit dans: Microsoft RIFF (AVI form)

RIFF est un conteneur, pas un format. WebP, WAV et AVI sont identiques octet pour octet ici ; les quatre octets qui les séparent viennent ensuite.

MP4 / ISO base medianorme.mp4 .m4a .movvideo/mp4
66 74 79 70ftypÀ l’octet 4

Écrit dans: ISO/IEC 14496-12 §4.3 (File Type Box)

Celle-ci ne commence pas au début du fichier : tout ce qui ne lit que les premiers octets la manque complètement.

Oggnorme.ogg .oga .ogvapplication/ogg
4F 67 67 53OggSÀ l’octet 0 (le début)

Écrit dans: RFC 3533 §6 (capture_pattern)

FLACnorme.flacaudio/flac
66 4C 61 43fLaCÀ l’octet 0 (le début)

Écrit dans: RFC 9639 §8.1 (stream marker)

MP3 with ID3v2informatif.mp3audio/mpeg
49 44 33ID3À l’octet 0 (le début)

Écrit dans: ID3v2 informal standard §3.1

Matroska / WebMnorme.mkv .webmvideo/x-matroska
1A 45 DF A3·E··À l’octet 0 (le début)

Écrit dans: RFC 8794 §4 (EBML magic)

Deux versions du format partagent un préfixe : la version fait donc partie de la signature au lieu d’être lue après.

ELFnormeapplication/x-executable
7F 45 4C 46·ELFÀ l’octet 0 (le début)

Écrit dans: System V ABI, ELF header (EI_MAG0..3)

DOS / Windows executabledoc. de l’éditeur.exe .dllapplication/vnd.microsoft.portable-executable
4D 5AMZÀ l’octet 0 (le début)

Écrit dans: Microsoft PE Format (IMAGE_DOS_HEADER)

Java classnorme.classapplication/java-vm
CA FE BA BE····À l’octet 0 (le début)

Écrit dans: Java Virtual Machine Specification §4.1 (magic)

SQLite databasedoc. de l’éditeur.sqlite .dbapplication/vnd.sqlite3
53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00SQLite format 3·À l’octet 0 (le début)

Écrit dans: SQLite Database File Format §1.3 (header string)

WOFFnorme.wofffont/woff
77 4F 46 46wOFFÀ l’octet 0 (le début)

Écrit dans: WOFF File Format 1.0 §3 (signature)

WOFF2norme.woff2font/woff2
77 4F 46 32wOF2À l’octet 0 (le début)

Écrit dans: WOFF File Format 2.0 §3 (signature)

Où elles sont spécifiées

normeFixé dans le texte normatif d’une norme publiée. Le changer, c’est rendre le fichier non conforme.

informatifC’est écrit, mais dans un document qui n’impose rien : un RFC informatif, ou une spécification depuis remplacée.

doc. de l’éditeurDocumenté par le propriétaire du format et non par un organisme de normalisation. Fiable en pratique, et révisable sans l’accord de personne.

convention seuleTous les outils l’implémentent et aucun document ne l’exige. Ces octets ne tiennent que parce que tout le monde est d’accord.

Chaque ligne est vérifiée contre un fichier produit par un vrai encodeur : ces octets ne sont donc pas recopiés d’une autre table.

Aussi disponible en : English · Español · Português · العربية

Signatures de fichier et nombres magiques

Les nombres magiques de 33 formats, chacun avec le document qui le définit vraiment, et un identificateur qui ne lit que l’en-tête, dans votre navigateur.

Qu’est-ce qu’une signature de fichier ?

Une signature de fichier, ou nombre magique, est une courte suite fixe d’octets au début d’un fichier qui indique de quel type il s’agit. Tous les PNG commencent par les mêmes huit octets ; toutes les archives gzip par les mêmes deux. Les programmes les lisent parce que le nom ne prouve rien : renommer un tableur en .png ne change rien à ce qu’il contient, et un fichier venu d’internet porte le nom que son expéditeur a bien voulu lui donner.

La liste ci-dessous réunit 33 formats avec leurs octets, l’endroit du fichier où ces octets se trouvent, et le type de média lorsqu’il en existe un d’enregistré. Ce qu’elle apporte en plus, et que les tableaux recopiés les uns sur les autres laissent tomber, c’est le document qui définit chaque signature. Cette colonne se révèle être la plus intéressante.

Car la réponse n’a rien d’uniforme. Certaines signatures sont fixées dans le texte normatif d’une norme publiée. D’autres seulement dans la documentation de l’éditeur. D’autres encore dans un document qui ne fait plus autorité. Et quelques-unes — ICO, bzip2, 7-Zip — sont implémentées à l’identique par tous les outils de la terre sans avoir jamais été écrites nulle part comme une exigence.

Comment s’en servir

  1. Déposez un fichier, ou choisissez-en un. Seul l’en-tête est lu, et c’est votre navigateur qui le lit. Rien n’est envoyé. Si une signature correspond, vous obtenez le format, les octets qui ont correspondu et l’endroit où ils sont définis.
  2. Ou collez les octets que vous avez déjà. Si vous regardez un vidage hexadécimal, collez les premiers octets. Espaces, préfixes 0x et minuscules sont acceptés ; il faut simplement un nombre pair de chiffres.
  3. Cherchez dans la liste par n’importe quel élément de la ligne. Le nom du format, une extension, un type de média, un préfixe hexadécimal ou le nom d’une spécification fonctionnent tous. Taper png place PNG en tête au lieu de l’enfouir sous tout ce qui contient ces lettres.

La signature du PNG, et l’explication que la norme a laissée tomber

Le PNG mérite qu’on s’y arrête, parce que ses huit octets sont les mieux conçus de la liste et que leur histoire n’est pas celle qu’on attendrait. Ce sont 137, 80, 78, 71, 13, 10, 26, 10 — en texte, un octet dont le bit de poids fort est mis, puis PNG, puis un retour chariot, un saut de ligne, un control-Z et un dernier saut de ligne.

Chacun fait son travail. Le premier octet n’est délibérément pas un caractère ASCII, pour qu’un fichier texte ne soit guère pris pour un PNG et surtout pour attraper un transfert qui effacerait le bit de poids fort de chaque octet. Le retour chariot et le saut de ligne attrapent le problème inverse : un transfert qui convertit obligeamment les fins de ligne d’une plateforme à l’autre abîme cette paire, et le fichier échoue au cinquième octet plutôt qu’au fin fond de l’image. Le control-Z empêche MS-DOS de déverser la suite d’un binaire dans le terminal quand on en fait un type. Le saut de ligne final attrape l’inverse de la conversion CR-LF.

Et voici ce qui nous a surpris. Cette explication ne figure pas dans la norme actuelle. L’ISO/IEC 15948, qui normalise le PNG aujourd’hui, énonce les huit octets et passe à autre chose, ne gardant qu’une phrase dans sa clause de justification pour dire que la signature détecte les erreurs de transmission courantes. Le raisonnement octet par octet ne survit que dans le RFC 2083 de 1997 — un document marqué Informatif, que la norme a depuis remplacé. Les octets sont normatifs. Les raisons pour lesquelles ce sont ces octets-là ne le sont pas.

Limites assumées

Une signature dit ce qu’un fichier prétend être, et c’est précisément pourquoi on la vérifie — mais c’est aussi sa limite. Les octets de tête sont faciles à falsifier. Si vous cherchez à savoir si quelque chose est sûr à ouvrir, une signature qui correspond vous apprend que le fichier est assez bien formé pour avoir un en-tête plausible, et rien de plus.

Toutes les signatures ne commencent pas au début. Le marqueur ustar qui identifie une archive tar se trouve à l’octet 257, et le CD001 de l’ISO 9660 à l’octet 32769, soit plus de 32 kilooctets à l’intérieur. Tout ce qui ne lit que les quatre premiers octets rate complètement les deux formats d’archive et d’image disque les plus répandus, d’où la lecture plus profonde de cet outil.

Plusieurs formats sont indiscernables en tête, et l’outil le dit au lieu de deviner. WebP, WAV et AVI commencent par les mêmes quatre octets, parce que tous trois sont des conteneurs RIFF et que les octets qui les séparent viennent ensuite. Un .docx, un .xlsx, un .jar, un .apk et un .epub sont tous des archives ZIP et portent la signature du ZIP ; les distinguer suppose de décompresser et de regarder à l’intérieur, ce qui est un autre travail. Dans les deux cas, toutes les correspondances sont affichées plutôt qu’une seule choisie.

Beaucoup de formats n’ont aucune signature. CSV, texte brut, la plupart du code source et le SVG ne sont que des caractères, sans rien de fixe en tête à comparer — le SVG en particulier est du XML, qui peut commencer ou non par une déclaration. Un fichier qui ne correspond à rien ici ne vous a pas dit grand-chose.

Enfin, 33 formats sont une sélection et non un recensement, et la liste est bornée exprès. La réponse complète de fait, c’est la base magique livrée avec la commande file d’Unix, qui compte des milliers de règles avec logique conditionnelle et arithmétique sur les octets. Cette page présente le sous-ensemble dont les octets peuvent être vérifiés contre un vrai fichier que ses propres tests construisent : chaque ligne y est donc vérifiée et non recopiée.

Pourquoi est-ce gratuit ?

Parce que cela ne coûte rien à faire tourner. La liste fait partie de la page et l’identification a lieu dans votre navigateur : quand vous déposez un fichier, seuls ses premiers octets sont lus, et ils le sont localement. Rien n’est envoyé, aucun serveur ne voit votre fichier, et il n’y a pas de compte.

Le tableau n’est pas recopié d’un autre tableau. Chaque ligne constructible est vérifiée contre un fichier produit par un véritable encodeur, et recoupée avec l’identification de la commande file elle-même : un chiffre interverti casse la compilation au lieu d’atteindre la page. Là où un format n’a pas pu être construit ici, la page le dit plutôt que de le laisser silencieusement non vérifié.