Les extensions de fichier ont-elles une utilité (pour le système d'exploitation)?

73

Linux détermine le type d'un fichier via un code dans l'en-tête du fichier. Cela ne dépend pas des extensions de fichier pour savoir quel logiciel utiliser pour ouvrir le fichier.

C'est ce que je me souviens de mon éducation. S'il vous plaît, corrigez-moi si je me trompe!

Travailler un peu avec les systèmes Ubuntu récemment: Je vois beaucoup de fichiers sur les systèmes qui ont des extensions comme .sh, .txt, .o,.c

Maintenant, je me demande: ces extensions sont-elles destinées uniquement aux humains? Alors qu’on devrait avoir une idée de quel type de fichier il s’agit?

Ou ont-ils également une utilité pour le système d'exploitation?

files file-format mime-type

— mizech
source

5

Si vous n'obtenez pas une bonne réponse ici, rappelez-vous qu'il y a aussi unix.stackexchange.com

— mchid le

Connexes, presque en double: askubuntu.com/questions/390015/…

— Zzzach ...

liés: unix.stackexchange.com/questions/207276/…

— chaos

5

Sous Windows , ils le font, sous Linux / Unix , ils la plupart du temps ne le font pas. La principale exception est la compression-programmes - gzip, bzip2, xz- et ainsi de suite. Ces programmes utilisent des suffixes pour séparer la version compressée d'un fichier de celle non compressée qu'ils remplacent. Les programmes de compression se plaignent souvent d'un suffixe incorrect, même si le fichier est en fait un fichier compressé du type qu'il devrait gérer.

— Baard Kopperud

6

Je pense qu'une partie du problème avec cette question est que "le système d'exploitation" n'est pas un concept bien défini. Qu'est-ce qui fait partie du système d'exploitation et qu'est-ce qu'une application par-dessus? Peu de parties du système d'exploitation (quel que soit le système d'exploitation dont nous parlons) se soucient du type de fichier: elles ne font que ce qu'on leur dit. Donc, les distinctions sur la façon dont ils savent sont sans importance; ils ne font ni l'un ni l'autre. Les applications, par contre, peuvent très bien faire l’une ou les deux choses.

— IMSoP

39

Linux détermine le type d'un fichier via un code dans l'en-tête du fichier. Cela ne dépend pas des extensions de fichier pour savoir avec le logiciel est d'utiliser pour ouvrir le fichier.

C'est ce que je me souviens de mon éducation. S'il vous plaît, corrigez-moi si je me trompe!

correctement rappelé.

Sont ces extensions sont destinées uniquement à l'homme?

Oui, avec un mais.

Lorsque vous interagissez avec d'autres systèmes d'exploitation qui dépendent des extensions, il est plus judicieux de les utiliser.

Sous Windows, le logiciel d’ouverture est associé aux extensions.

Ouvrir un fichier texte nommé "fichier" est plus difficile sous Windows que d'ouvrir le même fichier nommé "fichier.txt" (vous devrez changer la boîte de dialogue d'ouverture de fichier de *.txtà *.*chaque fois). Il en va de même pour les fichiers texte séparés par des tabulations et des tabulations. Il en va de même pour l'importation et l'exportation d'e-mails (extension .mbox).

En particulier lorsque vous codez un logiciel. Ouvrir un fichier nommé "software1" qui est un fichier HTML et "software2" qui est un fichier JavaScript devient plus difficile comparé à "software.html" et "software.js".

S'il existe un système sous Linux dans lequel les extensions de fichiers sont importantes, j'appellerais cela un bogue. Lorsque le logiciel dépend des extensions de fichier, cela est exploitable. Nous utilisons une directive interpréteur pour identifier ce qu'est un fichier ("les deux premiers octets d'un fichier peuvent être les caractères" #! ", Qui constituent un nombre magique (hexadécimal 23 et 21, les valeurs ASCII de" # "et"! ") souvent appelé shebang,").

Le problème le plus connu concernant les extensions de fichier était LOVE-LETTER-FOR-YOU.TXT.vbs sous Windows. Il s'agit d'un script visuel basique affiché dans l'explorateur de fichiers sous forme de fichier texte.

Dans Ubuntu, lorsque vous démarrez un fichier à partir de Nautilus, vous recevez un avertissement indiquant ce qu'il va faire. Exécuter un script de Nautilus où il veut démarrer un logiciel où il est supposé ouvrir gEdit est un problème évident et nous recevons un avertissement à ce sujet.

En ligne de commande, lorsque vous exécutez quelque chose, vous pouvez voir visuellement quelle est l'extension. Si cela finissait avec .vbs, je deviendrais méfiant (pas que .vbs soit exécutable sous Linux. Du moins sans un effort supplémentaire;)).

— Rinzwind
source

31

Je ne comprends absolument pas ce que vous vouliez dire dans votre dernière phrase. Premièrement, il s’agit de cacher l’extension plutôt que de l’avoir, deuxièmement, l’exploit fonctionnerait de la même manière sous Linux: vous nommez un fichier binaire readme.txtet le rendez exécutable. Si l'utilisateur l'exécute, il n'ouvre pas l'éditeur, mais exécute le code. À cet égard, rendre les extensions importantes (sans les cacher) est plus sûr et plus facile à expliquer pour les utilisateurs non avertis. Il existe d'autres différences (notamment ne pas exécuter les fichiers du répertoire actuel), mais elles n'ont rien à voir avec des extensions.

— Techraf

4

@techraf En réalité, le gestionnaire de fichiers tentera probablement d'ouvrir le readme.txtfichier avec un éditeur de texte. Je viens d’essayer avec dolphin dans KDE, de créer un script shell en ajoutant une autorisation exécutable, de l’enregistrer en tant que .txtet en cliquant dessus, ce qui l’ouvrira dans Kate. Si je le renomme en .shcliquant dessus, il s'exécute.

— Bakuriu

9

linux: depuis que make est construit autour de règles qui dépendent de l’extension de fichier, cela ne rend-il pas (sans jeu de mots) les extensions destinées à plus que des humains?

— bolov

15

Ceci est une réponse monumentalement fausse. Certaines parties de Linux utilisent des nombres magiques pour déterminer les types de fichiers. Exécuter des fichiers en ligne de commande. Mais d’autres parties énormes du système utilisent les extensions de fichiers pour savoir quoi regarder, qu’il s’agisse de l’éditeur de liens dynamique (qui veut des fichiers .so), de modprobe, de systèmes de compilation, de plugins, de bibliothèques pour python, ruby, etc. t ont des nombres magiques, fileest heuristique, non définie.

— Alan Shutko

3

"Linux détermine le type d'un fichier via un code dans l'en-tête du fichier" "correct" WTF? Quel "code dans l'en-tête du fichier"? Il n'y a pas de tel code, et il n'y a pas un tel "en-tête de fichier" générique dans Linux.

— leonbloy

68

Il n'y a pas de réponse à 100% en noir ou blanc ici.

Habituellement, Linux ne s'appuie pas sur les noms de fichiers (ni sur les extensions de fichier, c’est-à-dire la partie du nom de fichier après la dernière période), mais détermine le type de fichier en examinant les premiers octets de son contenu et en les comparant à une liste de nombres magiques connus . .

Par exemple, tous les fichiers image Bitmap (généralement avec l'extension de nom .bmp) doivent commencer par les lettres BMde leurs deux premiers octets. Les scripts dans la plupart des langages de script tels que Bash, Python, Perl, AWK, etc. (essentiellement tout ce qui traite les lignes commençant par un #commentaire) peuvent contenir un shebang comme #!/bin/bashla première ligne. Ce commentaire spécial indique au système avec quelle application ouvrir le fichier.

Donc, normalement, le système d’exploitation s’appuie sur le contenu du fichier et non sur son nom pour déterminer le type de fichier, mais le fait de déclarer que les extensions de fichier ne sont jamais nécessaires sous Linux n’est que la moitié de la vérité.

Les applications peuvent bien sûr implémenter leurs contrôles de fichiers comme bon leur semble, ce qui inclut la vérification du nom du fichier et de son extension. Un exemple est Eye of Gnome ( eog, visualiseur d'images standard), qui détermine le format de l'image à l'aide de l'extension de fichier et génère une erreur s'il ne correspond pas au contenu. Que ce soit un bug ou une fonctionnalité peut être discuté ...

Cependant, même certaines parties du système d'exploitation dépendent des extensions de nom de fichier, par exemple, lors de l'analyse syntaxique des fichiers sources du logiciel /etc/apt/sources.list.d/: seuls les fichiers dont l' *.listextension est analysée sont ignorés. Ce n'est peut-être pas principalement utilisé pour déterminer le type de fichier ici, mais plutôt pour activer / désactiver l'analyse de certains fichiers, mais c'est toujours une extension de fichier qui affecte la façon dont le système traite un fichier.

Et bien sûr , les bénéfices des utilisateurs humains les plus de extensions de fichier comme qui fait le type d'un fichier évident et permet également plusieurs fichiers avec le même nom de base et extensions différentes comme site.html, site.php, site.js, site.cssetc. L'inconvénient est bien sûr que l' extension du fichier et le réel type de fichier / contenu ne doivent pas nécessairement correspondre.

De plus, il est nécessaire pour l’interopérabilité multi-plateformes, comme par exemple Windows ne saura pas quoi faire avec un readmefichier, mais seulement un fichier readme.txt.

— Byte Commander
source

Vous vous contredisez légèrement ici: si la visionneuse d'images standard nécessite un nom de fichier se terminant par .bmp, quelle partie de l'OS dites-vous, s'appuie-t-elle sur le contenu du fichier commençant par "BM"? Autant que je sache, les seuls "nombres magiques dont le noyau s'intéresse" sont des types exécutables, y compris le cas spécial de #!. Tout le reste dépend de la décision de certaines applications.

— IMSoP

@IMSoP Je ne connais pas l'implémentation exacte de eoget je ne sais pas pourquoi ils s'intéressent au nom de fichier. Ceci est un bug à mon avis. Et bien sûr, si le fichier s'appelle "bmp" mais que son format de contenu ne correspond pas, il y aura aussi une erreur, bien sûr. Bien sûr, chaque application décide comment vérifier les fichiers, mais en général, les applications Linux ne doivent pas compter sur le nom. Btw, vous pouvez utiliser la filerecommandation pour examiner les types de fichiers en fonction de leur contenu.

— Byte Commander

1

La phrase que je conteste est la suivante: "Linux ... détermine le type de fichier en examinant les premiers octets". Quelle définition de "Linux" utilisez-vous dans cette phrase? L'existence de l' fileutilitaire ne prouve vraiment rien; c'est un outil utile, qui pourrait exister sur n'importe quel système d'exploitation. Quelle partie fondamentale du système d'exploitation rend l'exécution fileplus "correcte" que l'annulation du nom de fichier?

— IMSoP

Notez que les fichiers sans extension peuvent être associés à un programme.

— Isanae

24

Comme mentionné par d’autres, sous Linux, une méthode de directive interpréteur est utilisée (stockant certaines métadonnées dans un fichier sous la forme d’un en-tête ou d’un nombre magique afin que l’interprète correct puisse le lire) plutôt que la méthode d’association d’extension de nom de fichier utilisée par Windows.

Cela signifie que vous pouvez créer un fichier avec presque n'importe quel nom ... à quelques exceptions près.

pourtant

Je voudrais ajouter un mot de prudence.

Si votre système contient des fichiers provenant d'un système utilisant l'association de nom de fichier, il est possible que ces fichiers ne possèdent pas ces numéros ou en-têtes magiques. Les extensions de nom de fichier sont utilisées pour identifier ces fichiers par les applications capables de les lire, et vous pouvez rencontrer des effets inattendus si vous renommez ces fichiers. Par exemple:

Si vous renommez un fichier My Novel.docà My-Novel, LibreOffice sera toujours en mesure de l' ouvrir, mais elle ouvrira « Sans titre » et vous devrez le nommer à nouveau pour enregistrer (LibreOffice ajoute une extension par défaut, alors que vous auriez deux fichiers My-Novelet My-Novel.odt, ce qui peut être gênant)

Plus sérieusement, si vous renommez un fichier My Spreadsheet.xlsx en My-Spreadsheet, essayez de l'ouvrir avec xdg-open My-Spreadsheetvous pour obtenir ceci (car il s'agit en fait d'un fichier compressé):

Et si vous renommez un fichier My Spreadsheet.xlsen My-Spreadsheet, lorsque xdg-open My-Spreadsheetvous obtenez une erreur disant

erreur d'ouverture du site: aucune application n'est enregistrée pour gérer ce fichier

(Bien que dans les deux cas cela fonctionne bien si vous le faites soffice My-Spreadsheet)

Si vous renommez le fichier à sans extension My-Spreadsheet.odsavec mvet essayer de l' ouvrir , vous obtiendrez ceci:

(la réparation échoue)

Et vous devrez remettre l'extension d'origine pour ouvrir le fichier correctement (vous pouvez ensuite convertir le format si vous le souhaitez)

TL; DR:

Si vous avez des fichiers non natifs avec des extensions de nom, ne supprimez pas les extensions en supposant que tout ira bien!

— Zanna
source

4

Un document MS Office de nouveau style (docx, xlsx, pptx, etc.) sans extension de fichier s'ouvre dans le gestionnaire d'archives, car ces types de fichiers sont en réalité des fichiers compressés ZIP ordinaires contenant tous les documents XML et les fichiers multimédias nécessaires pour définir le contenu du document. Le format de fichier d’un répertoire compressé au format ZIP est assez courant de nos jours.

— Byte Commander

1

Déjà beaucoup de bonnes réponses, mais juste une de plus spécifique à libreoffice que j'ai remarquée. Vous créez un fichier de valeurs séparées par des virgules (CSV) et vous l'enregistrez sous le nom "test.csv". Une fenêtre s'ouvrira vous demandant quel type de séparateur utilisez-vous (par exemple, libreoffice Calc). Si vous renommez ce fichier en "test.cs", par exemple, Writer de libreoffice l'ouvre. Ainsi, outre l'exemple ZIP ci-dessus, il semble que libreoffice utilise l'extension de fichier.

— Ray

3

Le système de fichiers Linux ne fait rien en ce qui concerne les types de fichiers. Tout cela est dû aux programmes en cours d'exécution.

— Peter Green

@PeterGreen Oui, mais le fait que les programmes lui attribuent une signification signifie que ce n'est pas "juste pour les humains" comme c'est le cas, par exemple, MacOS classique l'avait [il y avait des champs "type de fichier" à quatre octets et "application du créateur" qui n'étaient pas " t une partie du nom de fichier, de sorte que le système d'exploitation et les applications disposent de toutes les informations dont ils ont besoin sans consulter les extensions de fichier]

— Random832

3

@ Peter Green Le système de fichiers Windows ne fait rien non plus concernant les types de fichiers. Le shell graphique (Explorateur Windows) utilise l’extension de fichier pour choisir une action à double-cliquer, mais techniquement, il s’agit d’un programme exécuté au-dessus du système d’exploitation, tout comme Nautilus. Il serait parfaitement possible d'écrire un gestionnaire de fichiers Linux avec ce comportement, ou un gestionnaire Windows examinant le contenu du fichier.

— IMSoP

20

J'aimerais aborder cette question d'une manière différente des autres réponses et contester la notion selon laquelle "Linux" ou "Windows" a tout à voir avec cela (supportez-moi).

Le concept d'extension de fichier peut être simplement exprimé comme "une convention permettant d'identifier le type d'un fichier en fonction d'une partie de son nom". Les autres conventions courantes pour identifier le type d'un fichier comparent son contenu à une base de données de signatures connues (approche du "nombre magique") et le stockent en tant qu'attribut supplémentaire sur le système de fichiers (approche utilisée dans le MacOS d'origine). .

Comme chaque fichier sur un système Windows ou Linux a à la fois un nom et un contenu, les processus qui souhaitent connaître le type de fichier peuvent utiliser l'approche "extension" ou "nombre magique" comme bon leur semble. L’approche par métadonnées n’est généralement pas disponible, car il n’existe pas d’emplacement standard pour cet attribut sur la plupart des systèmes de fichiers.

Sous Windows, il est de tradition d'utiliser l'extension de fichier comme principal moyen d'identification d'un fichier. de manière très visible, le navigateur de fichiers graphique (Gestionnaire de fichiers sous Windows 3.1 et Explorateur sous Windows moderne) l’utilise lorsque vous double-cliquez sur un fichier pour déterminer l’application à lancer. Sur Linux (et plus généralement sur les systèmes Unix), il est de plus en plus courant d’inspecter le contenu; en particulier, le noyau examine le début d'un fichier exécuté directement pour déterminer comment l'exécuter. Les fichiers de script peuvent indiquer un interpréteur à utiliser en commençant par #!suivi du chemin d'accès à l'interpréteur.

Ces traditions influencent la conception des programmes écrits pour chaque système par l'interface utilisateur, mais il existe de nombreuses exceptions, car chaque approche présente des avantages et des inconvénients dans des situations différentes. Les raisons d'utiliser les extensions de fichier plutôt que d'examiner le contenu incluent:

L’examen du contenu des fichiers est assez coûteux par rapport à l’examen des noms de fichiers; Ainsi, par exemple, "rechercher tous les fichiers nommés * .conf" sera beaucoup plus rapide que "rechercher tous les fichiers dont la première ligne correspond à cette signature".
le contenu du fichier peut être ambigu; de nombreux formats de fichiers ne sont en réalité que des fichiers texte traités de manière spéciale, de nombreux autres sont des fichiers zip spécialement structurés, et la définition de signatures précises peut être délicate
un fichier peut véritablement être valide en plusieurs types; un fichier HTML peut également être un fichier XML valide, un fichier zip et un fichier GIF concaténés restent valables pour les deux formats
la correspondance du nombre magique pourrait conduire à de faux positifs; un format de fichier sans en-tête peut commencer par les octets "GIF89a" et être identifié à tort comme une image GIF
renommer un fichier peut être un moyen pratique de le marquer comme "désactivé"; Par exemple, remplacer "foo.conf" par "foo.conf ~" pour indiquer qu'une sauvegarde est plus facile que de modifier le fichier pour mettre en commentaire toutes ses directives, et plus pratique que de le sortir d'un répertoire chargé automatiquement. De même, renommer un fichier .php en .txt indiquera à Apache de servir sa source sous forme de texte brut, plutôt que de le transmettre au moteur PHP.

Exemples de programmes Linux qui utilisent les noms de fichiers par défaut (mais peuvent avoir d’autres modes):

gzip et gunzip ont une gestion spéciale de tout fichier se terminant par ".gz"
gcc gérera les fichiers ".c" en C, et ".cc" ou ".C" en C ++

— IMSoP
source

Windows a également une longue tradition de masquer l’extension si elle est "bien connue" et même le DOS a autorisé une commande à omettre .COM, .BAT et .EXE, en recherchant automatiquement celles-ci pour déterminer le programme à exécuter. Une telle tradition n'existe pas dans * nix.

— Monty Harder

C'est une bien meilleure réponse, mais il y a une erreur factuelle ... un script ne peut pas être rendu exécutable en le plaçant #!au début. Tout fichier dont le ou les bits exécutables sont définis peut être exécuté de différentes manières. #!/bin/bashet des signatures similaires spécifient simplement quel interprète utiliser. Si aucune signature de ce type n'est fournie, l'interpréteur de shell par défaut est utilisé. Un fichier ne contenant que les deux mots "Hello World", mais avec son bit d'exécution défini, tentera de trouver une commande "Hello" lors de son exécution.

— DocSalvager

1

@DocSalvager Bonne prise, c'était une formulation maladroite autant que tout autre chose. Je l' ai reformulé un peu de préciser que le tralala n'a pas fait le script exécutable, il change juste la façon dont il est exécuté.

— IMSoP

15

En fait, certaines technologies ne compter sur les extensions de fichiers, donc si vous utilisez ces technologies dans Ubuntu, vous devrez compter sur les extensions aussi. Quelques exemples:

gccutilise des extensions pour faire la distinction entre les fichiers C et C ++. Sans l'extension, il est pratiquement impossible de les différencier (imaginez un fichier C ++ sans classes).
de nombreux fichiers ( docx, jar, apk) sont tout particulièrement structurés archives ZIP. Bien que vous puissiez généralement déduire le type à partir du contenu, il se peut que cela ne soit pas toujours possible (par exemple, Manifest Java est facultatif dans les jarfichiers).

Ne pas utiliser d'extensions de fichier dans de tels cas ne sera possible qu'avec des solutions de contournement de hacky et sera probablement très sujet aux erreurs.

— Dmitry Grigoryev
source

Bien sur la mention de la programmation, mais la plupart des détails sont faux. gccest le frontal pour les fichiers C; pour les fichiers C ++, vous devez utiliser le g++commutateur frontal ou un commutateur de ligne de commande pour spécifier la langue. Plus important est le makeprogramme qui décide d'utiliser gccou g++de créer un fichier particulier - et qui makedépend entièrement des modèles de nom de fichier (principalement des extensions) pour sa correspondance avec les règles.

— Ben Voigt

@BenVoigt Lors de la compilation d'un fichier avec une .ccextension avec gcc, il sera vraiment compilé en C ++, et ceci est documenté dans man gcc: "Pour tout fichier d'entrée donné, le suffixe du nom de fichier détermine le type de compilation effectué:" suivi d'une liste de extensions et comment elles sont traitées.

— hvd

1

@hvd Ensuite, c'est peut-être le jeu de bibliothèques par défaut qui va terriblement mal si vous n'utilisez pas la bonne interface. Quoi qu'il en soit, make est l'exemple principal, car tout ce qu'il fait est basé sur une extension de fichier.

— Ben Voigt

1

@BenVoigt makeest un bon exemple également, mais gccrepose tout autant sur les noms de fichiers. Voici un exemple plus clair que .cvs .cc: pour C, gccutilise des suffixes pour indiquer si sa première étape consiste à prétraiter ( .c), compiler ( .i), assemble ( .s) ou link ( .o). Ici, j’utilise -E, -Set -cpour dire gccoù arrêter , mais il utilise des noms de fichiers pour savoir par où commencer . gcc something.ccne sera pas lié aux bonnes bibliothèques pour C ++, mais le fichier sera traité comme C ++, ce qui explique pourquoi de nombreux utilisateurs sont désorientés par les messages d'erreur qu'ils obtiennent lorsqu'ils commettent cette erreur.

— Eliah Kagan

7

Votre première hypothèse est correcte: les extensions sous Linux n’importent pas et ne sont utiles que pour les humains (et les autres systèmes d’exploitation non apparentés à Unix qui s’occupent des extensions). Le type d'un fichier est déterminé par les 32 premiers bits de données qu'il contient, ce que l'on appelle un nombre magique. C'est pourquoi les scripts shell ont besoin d'une #!ligne pour indiquer au système d'exploitation quel interpréteur appeler. Sans cela, le script shell n'est qu'un fichier texte.

En ce qui concerne les gestionnaires de fichiers, ils souhaitent connaître les extensions de certains fichiers, tels que les .desktopfichiers, qui sont fondamentalement les mêmes que la version Windows des raccourcis mais avec davantage de fonctionnalités. Mais en ce qui concerne le système d'exploitation, il doit savoir ce qu'il y a dans le fichier, pas ce qu'il y a dans son nom.

— Sergiy Kolodyazhnyy
source

3

Ce n'est pas tout à fait vrai. Il existe des programmes qui attendent une extension spécifique. L'exemple le plus couramment utilisé est probablement celui gunzipqui ne décompresse pas un fichier s'il n'est pas appelé foo.gz.

— terdon

C'est une implémentation de logiciels spécifiques. Pour la plupart, les utilitaires sur les systèmes de type Unix n'attendent pas une extension.

— Sergiy Kolodyazhnyy

7

Pour la plupart, ils ne le font pas, non. Votre première phrase, cependant, affirme qu'elles ne sont jamais utilisées et ne concernent que les humains. Ce n'est pas tout à fait vrai. gunzipest un exemple, eogest un autre. En outre, de nombreux outils ne pourront pas compléter automatiquement les noms sans la bonne extension. Tout ce que je dis, c'est que c'est un peu plus compliqué que "les extensions sont toujours sans importance".

— terdon

1

1 petit problème: OP a posé des questions sur le système d'exploitation. 'gunzip' et 'eog' ne sont pas le système d'exploitation, mais ont décidé de créer leurs propres restrictions (en cas de gunzip) ou leur méthode (eog). "types de mime" cependant.

— Rinzwind

1

@Serg Bien sûr, vous pouvez définir le système d'exploitation de manière étroite et obtenir une réponse triviale à la question. Ce n'est cependant pas une réponse particulièrement utile, car la grande majorité de ce qu'un utilisateur fait avec un ordinateur implique des logiciels que vous avez exclus. Notez que la question oppose "uniquement pour les humains" au "système d'exploitation"; Je ne pense pas qu'ils voulaient dire "le noyau".

— IMSoP

6

C'est trop gros pour une réponse de commentaire.

Gardez à l'esprit que même "extension" a beaucoup si différentes significations.

Ce que vous parlez semble être les 3 lettres après le. DOS a rendu le format 8.3 très populaire et Windows utilise la partie .3 à ce jour.

Linux a beaucoup de fichiers comme .conf ou .list ou .d ou .c qui ont une signification, mais ne sont pas vraiment des extensions au sens 8.3. Par exemple, Apache examine /etc/apache2/sites-enabled/website.conf pour sa directive de configuration. Bien que le système utilise les types MIME et les en-têtes de contenu pour ne pas déterminer qu'il s'agit d'un fichier texte, Apache (par défaut) ne le charge toujours pas sans se terminer par .conf.

.c est un autre excellent. Oui, c'est un fichier texte, mais gcc dépend de main.c qui devient main.o et enfin principal (après avoir lié). À aucun moment, le système n’utilise l’extension .c, .o ou no pour donner un sens quelconque au contenu mais aux éléments suivants. a une signification. Vous devriez probablement configurer votre SCM pour ignorer main.o et main.

Voici le point: les extensions ne sont pas utilisées telles quelles dans les fenêtres. Le noyau n'exécutera pas de fichier .txt car vous supprimez la partie .txt du nom. Il est également très heureux d'exécuter un fichier .txt si l'autorisation d'exécution est définie. Cela étant dit, ils ont un sens et sont encore utilisés au "niveau informatique" pour beaucoup de choses.

— coteyr
source

1

Windows est également pas lié au x.3schéma de nommage plus, vous avez des extensions plus là, ainsi que .doxc, .torrent, .part, etc. Il est juste que de nombreux formats et extensions de fichier ont déjà été définies en arrière à l'époque où 8.3 nomination était encore une chose et plus tard la plupart du temps, les formats ont tout simplement adapté la convention consistant à utiliser jusqu'à 3 lettres.

— Byte Commander

Je ne vois pas comment ".conf", ".c", etc, sont "un sens différent" du "sens 8.3". Le concept d'extension de fichier peut être simplement exprimé comme "une convention permettant d'identifier le type d'un fichier en fonction d'une partie de son nom". Même DOS / Win3.1 n’avait pas besoin de l’extension appropriée (vous pouvez appeler un document Word "STUPIDN.AME" et l’ouvrir avec Ctrl-O dans WinWord). Il est juste que certains systèmes (par exemple un double-clic sur Windows, gzipvotre Makefile, etc.) peuvent être écrits pour utiliser cette convention afin de faire des suppositions sur l'action correcte à effectuer sur chaque fichier.

— IMSoP

@ByteCommander C'est vrai, mais l'extension détermine toujours l'application utilisée. Je ne suis pas sûr de savoir comment modifier la réponse pour refléter cela.

— coteyr

1

@coteyr Encore une fois, tout dépend de ce que nous entendons par "OS". Le gestionnaire de fichiers cherchera certainement une clé de registre pour "AME" et me dira que "foo.txt" est un fichier texte. Mais exécuter dirà une invite de commande ne me dira rien de tel; il s'en fiche tout simplement. L’exécution de fichiers est certainement une exception, sur les deux systèmes d’exploitation; si la question se limitait à celles-ci, la réponse serait que DOS / Windows ne se préoccupe que du nom, et Unix / Linux ne se soucie que de l'autorisation d'exécution et des premiers octets du fichier. En dehors de cela, il y a toujours une application qui choisit une convention à suivre.

— IMSoP

1

@coteyr Vous avez oublié * .scr (binaire d'écran de veille) dans Windows 3.1 et versions ultérieures. Cela dit, même dans les systèmes DOS / Windows, l’extension de fichier, même pour les exécutables, n’est encore que pratique. Les spécificités dépendent beaucoup de l'endroit où vous tracez la ligne de "système d'exploitation", mais vous pouvez toujours charger un binaire en mémoire et y accéder vous-même, en effectuant le travail que l'on demande normalement à l'OS. Sous MS-DOS, si vous parcourez command.com, je suis presque sûr qu'il existe une liste telle que EXE COM que vous pouvez modifier de manière à rechercher d'autres extensions si aucune n'est spécifiée (ce qui ne signifie pas que ce serait une bonne idée, Remarquez.

— un CVn