Comment les ordinateurs détectent les types de fichiers : les « magic bytes » expliqués
Pourquoi les extensions de fichiers ne disent pas tout
La plupart des gens pensent qu'un ordinateur sait qu'un fichier est un JPEG parce qu'il se termine par .jpg. C'est une supposition raisonnable, mais elle est fausse environ la moitié du temps. Les extensions de fichiers ne sont qu'une convention de nommage. C'est un indice pour le système d'exploitation, pas une garantie de ce qui se trouve à l'intérieur. Renomme un fichier PNG en .txt, et Windows essaiera volontiers de l'ouvrir dans le Bloc-notes, t'affichant un écran de charabia. Essaie d'ouvrir un document Word que tu as renommé en .pdf, et Adobe Acrobat refusera catégoriquement. Ceci est extrêmement important pour la conversion de fichiers. Lorsque tu télécharges un fichier sur un service comme CocoConvert, le système ne peut pas se fier uniquement à l'extension. Quelqu'un pourrait renommer un exécutable malveillant (.exe) en .jpg pour tromper un gestionnaire de fichiers naïf. Ou, plus fréquemment, un utilisateur peut simplement enregistrer un fichier avec la mauvaise extension par accident. On a tous déjà vu des téléchargements corrompus qui perdent complètement leurs métadonnées d'extension. La solution, adoptée il y a des décennies, consiste à ignorer le nom du fichier et à lire son contenu binaire réel. Plus précisément, un programme lit les tout premiers octets et les compare à une base de données de signatures connues. Ces signatures sont appelées « magic bytes », ou plus formellement, signatures de fichier. Elles sont la vérité absolue sur le contenu d'un fichier, quel que soit son nom.
Ce que sont réellement les « magic bytes »
Chaque format de fichier standardisé réserve ses premiers octets à un identifiant unique. Ces octets, écrits en hexadécimal, sont intégrés dans la spécification même du format ; ils ne sont pas ajoutés ultérieurement par le système d'exploitation. Tu peux les voir par toi-même avec un éditeur hexadécimal. Jetons un œil à quelques types de fichiers courants : - Les **images JPEG** commencent toujours par FF D8 FF. Les deux premiers octets (FF D8) marquent le début du flux de données, et le troisième (FF) commence le premier segment de marqueur. - Les **images PNG** commencent par une signature de 8 octets : 89 50 4E 47 0D 0A 1A 0A. Remarque que la partie 50 4E 47 correspond à 'PNG' en ASCII. - Les **fichiers PDF** commencent par 25 50 44 46, ce qui correspond à '%PDF' en ASCII. Tu peux ouvrir n'importe quel PDF dans un éditeur de texte brut et voir cela tout en haut. - Les **archives ZIP** commencent par 50 4B 03 04. C'est 'PK' en ASCII, pour Phil Katz, le créateur du format. Comme les fichiers DOCX, XLSX, PPTX et JAR sont tous basés sur le format ZIP, ils partagent cette signature. - Les **fichiers audio MP3** commencent souvent par FF FB ou FF F3, qui est le mot de synchronisation MPEG. - Les **fichiers EXE** sous Windows commencent par 4D 5A — 'MZ' en ASCII, pour Mark Zbikowski, l'un des architectes originaux de MS-DOS. Le nom « magic bytes » vient de l'utilitaire Unix `file`, qui utilise une base de données appelée `/etc/magic` (ou `/usr/share/misc/magic` sur les systèmes modernes) depuis les années 1970. Quand tu lances `file photo.jpg` dans un terminal, l'utilitaire lit les premiers octets, consulte sa base de données et te donne le vrai type de fichier, en ignorant complètement l'extension .jpg.
Comment les logiciels de détection lisent la signature
En principe, lire les « magic bytes » est simple. En pratique, les cas particuliers vont te poser problème. Le processus de base consiste à ouvrir le fichier en tant que flux binaire brut, à lire un petit tampon — souvent les 512 premiers octets — et à comparer ce tampon à une liste de signatures connues. Certains formats, cependant, nécessitent de lire bien plus loin. La comparaison n'est pas toujours une simple correspondance de préfixe. Certains formats placent leur signature à un décalage fixe. Le format d'image disque ISO, par exemple, a sa signature 'CD001' qui commence à l'octet 32 769. Les fichiers ZIP peuvent avoir leur répertoire central à la fin du fichier, forçant certains détecteurs à scanner depuis la fin plutôt que le début. Des bibliothèques modernes comme Apache Tika (Java), python-magic (Python) et libmagic (C) gèrent cette complexité. Apache Tika à lui seul connaît plus de 1 300 types de fichiers, détectant les types MIME, les encodages de caractères et même les métadonnées intégrées. Chez CocoConvert, nous utilisons la détection de signature côté serveur comme première ligne de défense. Si le type MIME que ton navigateur déclare ne correspond pas à ce que dit la signature binaire, le fichier est signalé pour un examen plus approfondi avant que toute conversion ne commence. Les formats conteneurs rendent les choses encore plus délicates. Un fichier DOCX et un fichier JAR commencent tous deux par 50 4B 03 04 car ce sont tous deux des archives ZIP. Pour les différencier, le logiciel doit regarder plus en profondeur dans l'archive pour des fichiers spécifiques, comme [Content_Types].xml pour un DOCX ou META-INF/MANIFEST.MF pour un JAR. Cette détection en deux passes est une pratique standard pour toute chaîne de traitement de fichiers sérieuse.
Quand les « magic bytes » échouent (et ça arrive)
Les « magic bytes » sont fiables, mais ils ne sont pas infaillibles. Plusieurs scénarios réels peuvent tromper la détection basée sur les signatures et te donner des réponses fausses ou ambiguës. Les **fichiers tronqués** sont un casse-tête constant. Si un téléchargement est interrompu, tu pourrais avoir un fichier avec un en-tête JPEG valide mais aucune donnée d'image réelle. La vérification de la signature réussit, mais la conversion échoue plus tard lorsque le décodeur s'attend à une image complète et ne trouve qu'un fragment. Les **fichiers intentionnellement malveillants** peuvent exploiter le fait que les « magic bytes » ne couvrent que l'en-tête. Un fichier peut avoir un en-tête PNG valide suivi d'une charge utile malveillante. C'est un vecteur d'attaque connu appelé fichier polyglotte — un seul binaire qui est simultanément valide en tant que deux types de fichiers différents. Des chercheurs ont créé des polyglottes JPEG/JavaScript qu'un navigateur exécutera comme un script tandis qu'une visionneuse d'images l'affichera comme une photo. La détection de signature seule ne les attrapera pas. Les **conflits de version de format** créent une autre couche d'ambiguïté. Avant 2007, les fichiers Microsoft Office (DOC, XLS, PPT) utilisaient le format binaire de document composé, qui commence par D0 CF 11 E0 A1 B1 1A E1. Les trois formats partagent exactement la même signature. Tu ne peux pas distinguer un .doc d'un .xls ou d'un .ppt en utilisant les « magic bytes » ; tu dois analyser la structure interne. Les **formats de texte brut** comme CSV, JSON, XML, HTML et Markdown n'ont aucun « magic bytes ». Ce sont juste des séquences de caractères. La détection repose ici sur une analyse heuristique : rechercher des motifs comme des chevrons (HTML/XML) ou des accolades (JSON). Ces heuristiques peuvent se tromper. Quiconque s'est déjà battu avec un « CSV » qui utilise des points-virgules au lieu de virgules connaît bien cette douleur. Si CocoConvert ne peut pas identifier un type de fichier avec certitude, il te le dit. Nous pensons que renvoyer une erreur claire est bien plus utile que de deviner et de produire un fichier corrompu.
Implications pratiques pour la conversion de fichiers
Alors, en quoi cela t'aide ? Ça change complètement la façon de dépanner les conversions qui ont échoué. Lorsqu'un service signale un « format de fichier non pris en charge ou non reconnu », le problème n'est presque jamais l'extension du fichier. C'est le contenu. Voici les coupables les plus courants et ce qu'il faut faire : **Le fichier est d'un format différent de ce que tu penses.** Cela arrive souvent avec les exports d'outils de design. Figma, par exemple, peut exporter un fichier étiqueté .jpg qui est en réalité un PNG. Le mieux est d'ouvrir le fichier dans un éditeur hexadécimal (comme HxD sous Windows ou Hex Fiend sous macOS) et de vérifier les premiers octets. Si tu vois 89 50 4E 47, c'est un PNG, quel que soit le nom. Renomme-le et réessaie. **Le fichier est protégé par un mot de passe ou un DRM.** Les documents Office chiffrés commencent toujours par D0 CF 11 E0, donc la vérification de la signature passe. Mais le contenu à l'intérieur est du texte chiffré. CocoConvert ne peut pas déchiffrer les fichiers protégés par mot de passe. Ne prends pas ça pour une limitation du service ; c'est une caractéristique de sécurité fondamentale du chiffrement lui-même. **Le fichier est un conteneur avec un contenu incorrect.** Un fichier créé en renommant un .zip générique en .docx aura la bonne signature (50 4B), mais il échouera à la conversion car il lui manque la structure XML de traitement de texte Word requise à l'intérieur. Le convertisseur ouvre l'archive, ne trouve rien à traiter et abandonne. **Incompatibilités de codecs dans les fichiers vidéo.** Un conteneur MKV (qui commence par 1A 45 DF A3) peut contenir de la vidéo encodée en H.264, H.265, AV1, VP9, ou des dizaines d'autres. Les « magic bytes » confirment le conteneur MKV, pas le codec du flux vidéo. Si CocoConvert prend en charge le MKV mais que ton fichier utilise un codec obscur comme RealVideo 4, la détection initiale passera mais l'étape de transcodage échouera.
Comment vérifier le vrai type d'un fichier sans logiciel spécialisé
Tu n'as pas besoin d'installer de logiciel spécialisé pour vérifier la véritable identité d'un fichier. Ces méthodes fonctionnent sur tous les principaux systèmes d'exploitation avec des outils que tu as déjà. **Sous Windows :** Ouvre PowerShell et exécute `Format-Hex -Path 'C:\chemin\vers\tonfichier.ext' | Select-Object -First 3`. Cette commande affiche les 48 premiers octets en hexadécimal. Compare la première ligne d'octets aux signatures listées plus haut dans cet article. **Sous macOS et Linux :** Ouvre le Terminal et exécute `xxd tonfichier | head -3`. Cela montre le décalage des octets, les valeurs hexadécimales et la représentation ASCII. Encore mieux, exécute simplement `file tonfichier`. L'utilitaire `file` est intégré et te donne une réponse claire et lisible immédiatement. **Dans un navigateur, sans aucun outil :** Si tu es sur une machine verrouillée où tu ne peux pas exécuter de commandes, va sur la page de détection de CocoConvert à cocoConvert.com/detect. Télécharge le fichier, et notre service te rapportera le type MIME détecté, les octets de signature correspondants, et son niveau de confiance. **En Python (pour les développeurs) :** Après `pip install python-magic`, tu peux exécuter `import magic; print(magic.from_file('tonfichier', mime=True))`. Cela donne un type MIME standard comme `image/jpeg`. Mon conseil pour le code Python en production, cependant, est d'utiliser plutôt la bibliothèque `filetype`. Elle n'a pas de dépendances système, ce qui la rend beaucoup plus facile à déployer sous Windows sans se battre avec les DLL de libmagic. Connaître le vrai type MIME avant de télécharger un fichier fait gagner beaucoup de temps. Si le type détecté d'un fichier ne figure pas sur la liste des formats d'entrée pris en charge par un service, tu sais tout de suite que la conversion échouera.
Les limites de ce que tout service de conversion peut promettre
La détection par « magic bytes » est un problème résolu pour les quelque 200 formats de fichiers qui couvrent 99 % de l'utilisation quotidienne. Mais pour la longue traîne des formats spécialisés, propriétaires ou anciens, aucun service — y compris CocoConvert — ne peut promettre une couverture complète. Des formats comme Autodesk DWG pour les dessins CAO, des variantes propriétaires d'imagerie médicale de marques de scanners spécifiques, ou des formats audio de niche de synthétiseurs vintage ont souvent une documentation médiocre ou inexistante. Même si les « magic bytes » sont connus, la structure interne peut être une boîte noire. Un convertisseur pourrait produire un résultat avec des données manquantes, des couleurs incorrectes ou des couches de métadonnées perdues. Au moment où j'écris ces lignes, CocoConvert prend en charge environ 300 formats d'entrée. Bien que cela semble beaucoup, le registre PRONOM de la Bibliothèque du Congrès documente plus de 2 000 formats de fichiers distincts. Cet écart représente des formats qui sont trop obscurs pour justifier l'effort d'ingénierie, sont légalement grevés par des brevets, ou sont si mal documentés que toute tentative de conversion serait un pari risqué. Ma recommandation est la suivante : si tu travailles dans des secteurs comme l'imagerie médicale, les données géospatiales ou la vidéo professionnelle, tu dois vérifier la prise en charge du format avant de t'engager dans un flux de travail de conversion. Consulte la page de support des formats de CocoConvert. Elle liste toutes les entrées et sorties prises en charge, ainsi que des notes sur les limitations connues. Il vaut mieux vérifier d'abord que de télécharger un fichier master de diffusion de 4 Go pour découvrir que sa saveur spécifique de MXF n'est pas prise en charge. Les « magic bytes » disent à un ordinateur ce qu'un fichier *est*. Ils ne lui disent pas si la conversion de ce fichier produira quelque chose d'*utile*. Cette deuxième question, plus importante, dépend d'une bonne documentation, de licences claires et d'un travail d'ingénierie dédié qu'aucune quantité de reniflage d'octets intelligent ne peut remplacer.