为何file --mime-type与mimetype命令对同一文件识别结果不同？

我有一个仅包含单个文本字符C的文件，文件内无换行符等其他内容，当前系统为Ubuntu 20.04.1。使用file --mime-type命令识别该文件时，结果显示为application/octet-stream；而使用mimetype命令识别时，结果为text/plain。以下是相关问题的解析：

为什么两个工具识别结果不同？ #

核心原因是file和mimetype依赖的识别逻辑、数据源完全不同：

• file命令以**幻数（magic number）**匹配为核心，依赖系统内置的幻数规则库（默认路径/usr/share/misc/magic），只有文件长度足够读取到匹配规则的字节数时，才能准确识别类型。对于仅1字节的文件，它无法触发任何文本文件的判定规则，只能返回默认的二进制流类型application/octet-stream。
• mimetype属于libfile-mimeinfo-perl包，遵循Freedesktop.org的MIME规范，优先检测内容的文本特征。对于单个可打印的ASCII字符，它直接判定为text/plain，逻辑更贴近“文本文件”的直观认知。

file无参数时的提示含义 #

very short file (no magic)这个提示并非识别错误，而是file的正常反馈：文件长度太短，无法读取足够字节来匹配幻数规则库中的任何条目。大多数文件类型的识别规则都需要至少几个字节的样本（比如文本文件的规则通常需要检测连续可打印字符或换行符），单个字符达不到这个阈值，因此file无法确定具体类型，给出此提示。

两个命令的实现差异 #

file命令 #

• 基于C语言实现，核心逻辑是匹配文件头部的特征字节（幻数）。
• 对于文本文件的判定，需要满足“足够多的可打印字符”或包含换行符等条件，单个字符无法触发这些规则。
• 当无任何规则匹配时，默认返回application/octet-stream。

mimetype命令 #

• 基于Perl的File::MimeInfo模块，依赖Freedesktop的MIME数据库（/usr/share/mime）。
• 识别逻辑更偏向文本优先，只要内容是可打印的ASCII字符，即使只有一个，也会归类为text/plain。

file --mime-type是不是bug？ #

这不是bug，是file的设计逻辑导致的。file的核心定位是识别二进制文件类型，文本文件的识别属于附加功能，且有长度限制。如果要让file正确识别短文本文件，可以使用-k参数强制尝试所有可能的规则：

file -k --mime-type yourfile

执行后通常会返回text/plain; charset=us-ascii，因为-k参数会让file忽略长度限制，尝试匹配更多规则。

内容的提问来源于stack exchange，提问作者Aleix Mariné