这里没有百分之百的黑与白的答案。
通常情况下，Linux不依赖文件名（和文件扩展名，即文件名中最后一个句点后的部分），而是通过检查其内容的前几个字节并将其与已知的魔数列表进行比较来确定文件类型。
例如，所有位图图像文件（通常以.bmp为扩展名）的前两个字节必须以字母BM开头。大多数脚本语言（如Bash、Python、Perl、AWK等）的脚本（基本上将以#开头的行视为注释）可以在第一行包含类似于#!/bin/bash的shebang。这个特殊的注释告诉系统使用哪个应用程序打开文件。
因此，通常操作系统依赖文件内容而不是文件名来确定文件类型，但声称在Linux上永远不需要文件扩展名只是事实的一半。
readme文件，但它可以处理readme.txt文件。#!。其他一切都取决于某个应用程序的决定。 - IMSoPeog的确切实现方式，也不知道为什么他们关心文件名。在我看来，这是一个bug。当然，如果文件名为“bmp”，但其内容格式不匹配，那么也会出现错误。当然，每个应用程序都决定如何验证文件，但通常情况下，Linux应用程序不应该依赖于文件名称。顺便说一下，您可以使用“file”命令通过内容检查文件类型。 - Byte Commanderfile实用工具的存在并不能真正证明任何事情；它只是一个有用的工具，可以存在于任何操作系统上。在运行file与使用通配符匹配文件名相比，有什么基本部分使得运行file更加“正确”呢？ - IMSoPreadme.txt并使其可执行。如果用户执行它，它不会打开编辑器，而是运行代码。从这个角度来看，让扩展名有意义（但不隐藏它们）更安全且更容易解释给非专业用户。还有其他差异（尤其是不从当前目录执行文件），但与扩展名无关。 - techrafreadme.txt 文件。我刚刚在KDE的海豚文件管理器中尝试过，创建一个添加了可执行权限并将其保存为.txt的shell脚本，然后单击它将使其在Kate中打开。如果我将其重命名为.sh，然后单击它将运行该脚本。 - Bakuriufile命令并决定将ILOVEYOU传递给一个存在漏洞的解释器运行并不更安全 - 攻击者可以确定名称和内容。 - IMSoPfile 不知道如何识别更奇特的文件格式之一，最好希望它有一个附加的扩展名，这样你就可以搜索它了，否则使用那个文件就祝你好运了。 - Thomasfile 命令基于启发式方法而非确定性方法。 - Alan Shutkocc的历史实践是一个漏洞吗？我相信C编译器一直依赖于文件扩展名来区分需要传递给cc1的.c参数和可以直接传递给ld的.o参数。 - Jonathan Castcp /bin/ls ~/readme.txt，然后启动Nautilus并打开这个新文件，它将在文本编辑器中打开。尝试编译一个没有.c扩展名的C程序代码，你会得到错误提示。你还觉得gcc有bug吗？ - Alex Jones#!/usr/bin/ipython也需要.ipy扩展名。 - Old Badman Greyxdg-open My-Spreadsheet打开它，你会得到以下结果（因为它实际上是一个压缩文件）：
My Spreadsheet.xls，然后再将其重命名为My-Spreadsheet，当你使用xdg-open My-Spreadsheet打开它时，会出现以下错误信息：
（尽管在这两种情况下，如果你使用打开位置时出错：没有注册应用程序来处理此文件
soffice My-Spreadsheet，它仍然可以正常工作）My-Spreadsheet.ods并尝试打开它，你将会得到以下结果：
#!开头，后跟解释器路径来指示要使用的解释器。默认情况下使用文件名的Linux程序示例（但可能有其他模式）：
gzip和gunzip对以".gz"结尾的文件有特殊处理。 gcc会将以".c"结尾的文件视为C语言，而将以".cc"或".C"结尾的文件视为C++。#!，无法使脚本可执行。任何设置了可执行位的文件都可以以多种方式执行。#!/bin/bash和类似的签名只是指定要使用的解释器。如果没有提供这样的签名，则假定使用默认的shell解释器。一个只包含两个单词“Hello World”的文件，但其执行位被设置，将在运行时尝试找到一个“Hello”命令。 - DocSalvagergcc 是用于 C 文件的前端，而对于 C++ 文件，你需要使用 g++ 前端或者通过命令行开关来指定语言。更重要的是 make 程序，它决定是否使用 gcc 或 g++ 来构建特定的文件 —— 而 make 完全依赖于文件名模式（主要是扩展名）来进行规则匹配。 - Ben Voigtgcc 编译一个扩展名为 .cc 的文件时，它实际上会被编译为 C++，这在 man gcc 中有记录：“对于任何给定的输入文件，文件名后缀决定了进行什么类型的编译:” 后跟一系列扩展名及其处理方式。 - hvdmake也是一个很好的例子，但是gcc同样严重依赖于文件名。这里有一个比.c和.cc更清晰的例子：对于C语言，gcc使用后缀来判断它的第一步是预处理（.c），编译（.i），汇编（.s）还是链接（.o）。在这个例子中，我使用了-E，-S和-c来告诉gcc在哪里停止，但它使用文件名来知道从哪里开始。 gcc something.cc不会链接到正确的C++库，但它会将文件视为C++，这就是为什么许多用户在犯下这个错误时会感到困惑的原因。 - Eliah Kagan#!行 - 告诉操作系统调用哪个解释器。没有它，shell脚本只是文本文件。.desktop文件，基本上相当于Windows版本的快捷方式，但具有更多功能。但就操作系统而言，它需要知道文件中的内容，而不是文件名中的内容。gunzip，如果文件不叫foo.gz，它就无法解压缩。 - terdon#! ，其处理程序开始读取以下字节直到新行，然后再决定如何继续。我找到了这篇文章（https://0xax.gitbooks.io/linux-insides/content/SysCall/syscall-4.html ），它详细介绍了当前Linux实现的情况，不再有2字节魔数的显式限制（它始终预先加载文件的128字节）。 - IMSoPgunzip <foo它会愉快地解压文件。 - Monty Hardergunzip是一种特定的软件，它接受特定的参数。楼主问的是扩展名对操作系统是否重要，而不是对任何软件是否重要。我们为什么还要讨论这个问题呢？ - Sergiy Kolodyazhnyygunzip和eog是软件，它们绝对不会影响系统的运行方式，而且系统明显可以很好地在没有它们的情况下正常运行。它们也不负责加载其他程序，例如Linux内核或程序加载器。 - Sergiy Kolodyazhnyyx.3的命名规则，您还可以使用更长的扩展名，例如.doxc, .torrent, .part等。只是在8.3命名仍然存在的时候，许多文件格式和扩展名已经被定义，后来的格式大多只是简单地采用了使用最多3个字母的约定。 - Byte Commanderdir却不会告诉我任何信息；它根本不关心。在两个操作系统中，执行文件肯定是个例外；如果问题只限于这些情况，答案将是DOS/Windows 仅仅关心名称，而Unix/Linux 仅仅关心执行权限和文件前几个字节。除此之外，总有一些应用程序选择遵循某种约定。 - IMSoP
gzip，bzip2，xz等等。这些程序使用后缀来区分文件的压缩版本和替换的未压缩版本。尽管文件实际上是应该处理的压缩文件类型，但压缩程序经常会抱怨后缀不正确。 - Baard Kopperudfoo.c（源代码）->foo.s（汇编器）->foo.o（单独编译的输出）->foo（链接输出）。在这种情况下，文件扩展名是必要的，以便不同的格式有不同的名称，满足内核级别的要求，即给定的文件名只与一个字节流相关联。 - Jonathan Cast