Linux n'identifie pas nécessairement les types de fichiers sans extension. Et Windows ne's'appuie pas non plus sur les extensions comme on pourrait le croire. Commençons par le noyau. (J'utilise le mot Linux et Unix de manière interchangeable parce que beaucoup de choses que vous voyez dans Linux proviennent de l'héritage BSD des Bell Labs.)
À un niveau fondamental, Unix a pris une décision il y a TRÈS LONG temps, pour fournir une représentation de fichier pour autant de "trucs" qu'ils peuvent. La liste des processus en cours d'exécution ? Fichier. Pipes ? Fichier. Sockets du noyau ? Fichier. Infos mémoire ? Fichier. Blocs périphériques ? Fichier. Répertoires ? Fichier. Périphériques Usb ? Fichier. Port série ? Fichier.
Cela signifiait que pour beaucoup de situations, les *nix commençaient avec beaucoup plus de métadonnées attribuables à un fichier (beaucoup plus que ce que Windows supportait à l'origine - NT a corrigé beaucoup de cela.)
Cela combiné avec le fait qu'aux premiers jours du développement de Linux, ils n'avaient pas't le temps d'écrire des outils complexes/fantaisistes, et la philosophie unix de réutiliser de petits outils à plusieurs reprises, signifiait que la PLUPART des fichiers étaient lisibles par la machine (aka, texte ASCII).) Le fait qu'il n'y avait rien de "propriétaire" à cacher et qu'il n'y avait pas de promotions à gagner en inventant de nouveaux formats de fichiers dans leurs propres "orgs" incitait encore plus à cela.
Cela signifiait qu'un GRAND nombre de fichiers dans Linux sont simplement basés sur du texte. Cela ne'signifie pas que vous pouvez "dire" un type de fichier magiquement tout le temps. Ce n'est pas parce que quelque chose est en ASCII que c'est le même "type". Par exemple, si vous allez sous /etc/, il y a beaucoup de fichiers de configuration qui sont de "type" fichier de configuration. Mais qu'est-ce que cela signifie ? Chaque fichier a un format différent, une syntaxe différente. Un grand nombre de fichiers sont simplement déduits intuitivement de leur emplacement ou de leur nom (le programme foo, lira /etc/foo.d/*.conf - il n'a vraiment aucune idée de la façon de détecter que les fichiers sont appropriés ou destinés à lui.)
Au delà de cela, certains programmes peuvent utiliser un nombre magique dans l'en-tête d'un fichier. En particulier pour distinguer entre différents types de fichiers exécutables - fichiers ELF vs scripts shell, bibliothèques dynamiques (même elles'utiliseront l'extension .so pour aider cependant et seront situées sous une certaine forme de répertoire /lib - voir les deux méthodes intuitives ci-dessus.), etc.
Cependant, pour en faire une véritable comparaison de pommes à pommes, linux peut-il simplement regarder une et différencier si elle a besoin du programme de documents LibreOffice ? Et des journaux de plongée de Subsurface's ? Ou des fichiers de paie de votre programme de comptabilité personnalisé'png, jpeg, mpeg, avi, gif, etc...
Vous voyez, les nombres magiques sont à la fois coûteux (vous devez OUVRIR le fichier pour le déterminer - ce qui rend la recherche/pars/filtrage difficile.), et peu fiables (rien n'empêche un mauvais citoyen d'injecter un numéro magique en haut de son fichier - tout comme n'importe qui peut définir une extension.)
Donc la réponse courte est - Linux a effectivement beaucoup plus de métadonnées/intuition sur lesquelles se baser. Cependant, lorsque vous comparez les types d'applications que vous exécutez sur Windows et les types d'applications que vous'exécuteriez sur un bureau Linux - vous égalisez le terrain de jeu et avez les mêmes problèmes. Linux ne peut pas mieux différencier les formats hautement spécifiques aux apps que ne peut le faire windows (et certainement pas de manière aussi bon marché) - et les extensions (ou les nombres magiques) ne font qu'indiquer aux deux OS dans quels programmes les charger (PAS quel TYPE de fichier il s'agit.)