文件扩展名是否有任何用途（对于操作系统）？

Question

Linux 通过文件头中的代码确定文件的类型。它不依赖于文件扩展名来了解用于打开文件的软件。

这就是我从我的教育中记得的。如果我错了，请纠正我！

最近在 Ubuntu 系统上工作了一下：我在系统上看到很多文件都有像.sh, .txt, .o,等扩展名.c

现在我想知道：这些扩展是否仅适用于人类？所以人们应该知道它是什么类型的文件？

或者它们对操作系统也有某种用途吗？

Answer 1

这里没有 100% 非黑即白的答案。

通常Linux 不依赖文件名（和文件扩展名，即通常最后一个句点之后的文件名部分），而是通过检查其内容的前几个字节并将其与已知幻数列表进行比较来确定文件类型.

例如，所有位图图像文件（通常带有扩展名.bmp）必须以前BM两个字节中的字母开头。大多数脚本语言（如 Bash、Python、Perl、AWK 等）中的脚本（基本上所有#以注释开头的行）都可能包含像#!/bin/bash第一行这样的 shebang 。这个特殊的注释告诉系统用哪个应用程序打开文件。

所以通常操作系统依赖文件内容而不是文件名来确定文件类型，但声明在 Linux 上从不需要文件扩展名只是事实的一半。

应用程序当然可以按照自己的意愿执行文件检查，包括验证文件名和扩展名。一个例子是 Gnome 之眼（eog标准图片查看器），它通过文件扩展名确定图像格式，如果与内容不匹配，则会引发错误。可以讨论这是错误还是功能...

然而，即使是操作系统的某些部分也依赖于文件扩展名，例如在解析您的软件源文件时/etc/apt/sources.list.d/- 只有具有*.list扩展名的文件被解析，所有其他文件都被忽略。它可能不是在这里主要用于确定文件类型，而是用于启用/禁用某些文件的解析，但它仍然是影响系统如何处理文件的文件扩展名。

当然还有最从文件扩展名的人类用户利润，使明显的一个文件的类型，也可以用相同的基本名称的多个文件和不同的扩展名如site.html，site.php，site.js，site.css等缺点当然是文件扩展名，实际文件类型/内容不一定要匹配。

此外，跨平台互操作性也需要它，例如 Windows 不知道如何处理readme文件，而只知道readme.txt.

Answer 2

Linux 通过文件头中的代码确定文件的类型。它不依赖于文件扩展名来知道软件用于打开文件。

这就是我从我的教育中记得的。如果我错了，请纠正我！

• 没记错。

这些扩展是否仅适用于人类？

• 是的，但是。

当您与其他依赖于扩展的操作系统交互时，使用它们是更明智的想法。

在 Windows 中，打开软件附加到扩展。

打开一个名为文本文件“文件”是很难在Windows不是打开一个名为“file.txt的”（你将需要从切换打开文件对话框相同的文件*.txt，以*.*每次）。TAB 和分号分隔的文本文件也是如此。导入和导出电子邮件（.mbox 扩展名）也是如此。

尤其是当您编写软件时。与“software.html”和“software.js”相比，打开名为“software1”的HTML文件和名为“software2”的JavaScript文件变得更加困难。

如果 Linux 中存在一个文件扩展名很重要的系统，我会称其为错误。当软件依赖于文件扩展名时，这是可利用的。我们使用解释器指令来识别文件是什么（“文件的前两个字节可以是字符“#！”，它们构成一个幻数（十六进制23和21，“#”和“！”的ASCII值）。 ") 通常被称为shebang，")。

最著名的文件扩展问题是Windows 上的LOVE-LETTER-FOR-YOU.TXT.vbs。这是在文件资源管理器中显示为文本文件的可视化基本脚本。

在 Ubuntu 中，当您从 Nautilus 启动文件时，您会收到它将要执行的操作的警告。从 Nautilus 执行脚本，它想要启动一些应该打开 gEdit 的软件，这显然是一个问题，我们会收到有关它的警告。

在命令行中执行某些操作时，您可以直观地看到扩展名是什么。如果它以 .vbs 结尾，我会开始怀疑（不是 .vbs 在 Linux 上是可执行的。至少不是没有更多的努力;)）。

Answer 3

正如其他人提到的，在 Linux 中使用了解释器指令方法（将一些元数据存储在文件中作为标头或幻数，以便正确的解释器可以被告知读取它）而不是 Windows 使用的文件扩展名关联方法。

这意味着您几乎可以使用您喜欢的任何名称创建一个文件……但有一些例外

然而

我想补充一句警告。

如果您的系统上有一些来自使用文件名关联的系统的文件，则这些文件可能没有那些幻数或标题。文件扩展名用于通过能够读取这些文件的应用程序来识别这些文件，如果您重命名这些文件，您可能会遇到一些意想不到的效果。例如：

如果您将文件重命名My Novel.doc为My-Novel，Libreoffice 仍然可以打开它，但它会以“无标题”的形式打开，您必须重新命名才能保存它（Libreoffice 默认添加一个扩展名，因此您将拥有两个文件My-Novel和My-Novel.odt，这可能很烦人）

更严重的是，如果你将文件 My Spreadsheet.xlsx 重命名为 My-Spreadsheet，然后尝试打开它，xdg-open My-Spreadsheet你会得到这个（因为它实际上是一个压缩文件）：

如果您将文件重命名My Spreadsheet.xls为My-Spreadsheet，当xdg-open My-Spreadsheet您收到错误提示时

错误打开位置：没有应用程序注册为处理此文件

（尽管在这两种情况下它都可以正常工作soffice My-Spreadsheet）

如果您然后将无扩展名文件重命名为My-Spreadsheet.odswithmv并尝试打开它，您将得到以下信息：

（修复失败）

并且您必须重新打开原始扩展名才能正确打开文件（然后您可以根据需要转换格式）

特尔；博士：

如果您有带有扩展名的非本地文件，请不要在一切正常的情况下删除扩展名！

Answer 4

我想对此采取与其他答案不同的方法，并挑战“Linux”或“Windows”与此有关的概念（请耐心等待）。

文件扩展名的概念可以简单地表述为“根据文件名称的一部分来识别文件类型的约定”。识别文件类型的其他常见约定是将其内容与已知签名的数据库进行比较（“幻数”方法），并将其存储为文件系统上的额外属性（原始 MacOS 中使用的方法） .

由于 Windows 或 Linux 系统上的每个文件都有名称和内容，因此想要知道文件类型的进程可以使用他们认为合适的“扩展名”或“幻数”方法。元数据方法通常不可用，因为在大多数文件系统上没有此属性的标准位置。

在 Windows 上，使用文件扩展名作为识别文件的主要方式有着悠久的传统。最明显的是，当您双击文件以确定要启动哪个应用程序时，图形文件浏览器（Windows 3.1 上的文件管理器和现代 Windows 上的资源管理器）会使用它。在 Linux（以及更普遍的基于 Unix 的系统）上，检查内容有更多的传统；最值得注意的是，内核查看直接执行的文件的开头以确定如何运行它；脚本文件可以通过开头跟#!解释器的路径来指示要使用的解释器。

这些传统影响了为每个系统编写的程序的 UI 设计，但也有很多例外，因为每种方法在不同情况下都有优缺点。使用文件扩展名而不是检查内容的原因包括：

• 与检查文件名相比，检查文件内容的成本相当高；因此，例如“查找所有名为 *.conf 的文件”将比“查找第一行与此签名匹配的所有文件”快得多
• 文件内容可能不明确；许多文件格式实际上只是以特殊方式处理的文本文件，许多其他文件格式是特殊结构的 zip 文件，为这些文件定义准确的签名可能很棘手
• 一个文件可以真正作为多种类型有效；HTML 文件也可能是有效的 XML，连接在一起的 zip 文件和 GIF 对两种格式都有效
• 幻数匹配可能会导致误报；没有标题的文件格式可能会以字节“GIF89a”开头，并被误认为是 GIF 图像
• 重命名文件可以方便地将其标记为“已禁用”；例如，将“foo.conf”更改为“foo.conf~”以指示备份比编辑文件以注释掉其所有指令更容易，并且比将其从自动加载的目录中移出更方便；同样，将 .php 文件重命名为 .txt 将告诉 Apache 将其源作为纯文本提供，而不是将其传递给 PHP 引擎

默认情况下使用文件名的 Linux 程序示例（但可能有其他模式）：

• gzip 和 gunzip 对任何以“.gz”结尾的文件有特殊处理
• gcc 会将 ".c" 文件作为 C 处理，将 ".cc" 或 ".C" 作为 C++ 处理

Answer 5

实际上，有些技术确实依赖于文件扩展名，因此如果您在 Ubuntu 中使用这些技术，您也必须依赖于扩展名。几个例子：

• gcc使用扩展名来区分 C 和 C++ 文件。如果没有扩展名，几乎不可能区分它们（想象一个没有类的 C++ 文件）。
• 许多文件 ( docx, jar, apk) 只是特别结构化的 ZIP 档案。虽然您通常可以从内容推断类型，但并不总是可能的（例如，Java 清单在文件中是可选的jar）。

在这种情况下不使用文件扩展名只能使用 hacky 解决方法，并且可能非常容易出错。

Answer 6

您的第一个假设是正确的：Linux 上的扩展无关紧要，仅对人类有用（以及其他关心扩展的非类 Unix 操作系统）。文件的类型由文件中的前 32 位数据决定，这被称为幻数 这就是为什么 shell 脚本需要#!line - 来告诉操作系统要调用哪个解释器。没有它，shell 脚本只是文本文件。

就文件管理器而言，他们确实想知道某些文件的扩展名，例如.desktopfiles ，它与 Window 版本的快捷方式基本相同，但具有更多功能。但就操作系统而言，它需要知道文件中的内容，而不是其名称中的内容

Answer 7

这对于评论答案来说太大了。

请记住，即使“扩展名”也有很多不同的含义。

你所说的似乎是 . 后的 3 个字母。DOS 使 8.3 格式真正流行起来，直到今天 Windows 还在使用 .3 部分。

Linux 有很多文件，如 .conf 或 .list 或 .d 或 .c ，它们具有意义，但并不是 8.3 意义上的真正扩展。例如，Apache 在 /etc/apache2/sites-enabled/website.conf 中查看其配置指令。虽然系统使用 MIME 类型和内容标头以及什么不能确定它是文本文件，但 Apache（默认情况下）仍然不会加载它而不以 .conf 结尾。

.c 是另一个伟大的。是的，它是一个文本文件，但 gcc 依赖于 main.c 成为 main.o 并最终成为 main（链接后）。系统在任何时候都不会使用 .c、.o 或没有扩展名来表示内容的任何意义，而是 .c 之后的内容。确实有一定的意义。您可能会将 SCM 设置为忽略 main.o 和 main。

要点是这样的：扩展不像在 Windows 中那样使用。内核不会执行 .txt 文件，因为您删除了名称的 .txt 部分。如果设置了执行权限，执行 .txt 文件也很高兴。话虽如此，它们确实有意义，并且仍然在“计算机级别”上用于许多事情。