mac和linux中mime插件文件的位置在哪里？

Posted 2023-03-15

【中文标题】mac和linux中mime插件文件的位置在哪里？

【英文标题】：Where is the location of the mime plugin files in mac and linux?

【发布时间】：2018-02-23 08:38:42

【问题描述】：

我只是好奇本地应用程序（包括浏览器）如何读取/解释 mime 类型。用于读取 mime 类型的插件是否内置于每个应用程序中，或者在解释 mime 类型时应用程序引用的操作系统中是否有一个特殊的系统文件夹？

RFC 在定义 MIME 类型时使用字符图作为参考：

(1) 字符集以外的文本消息体 US-ASCII

虽然MDN 听起来像是使用了content-type，但你会在html 之类的东西中找到

content-type=image/jpeg 或 content-type=application/javascript 之类的东西是否使用 UTF-8 字符图表来确定它们的字符集（字形），而其他东西是否使用逻辑来确定这些字符字形应该被解释成什么？

这是否意味着每种内容类型都有自己的特殊字符图（如 utf-8 -> js-8????），既可以进行字符字形转换，也可以将 char 字形逻辑解释为二进制？

为什么听起来 charcharts 和 content-type 都意味着 MIME？ 包含内容类型图表/解释逻辑的 Mac 和 Linux 系统的文件夹路径在哪里？

【问题讨论】：

AFAIK Linux 或 Max 不依赖于文件扩展名，它依赖于内容

【参考方案1】：

那些大多位于 /usr/share/mime 和 /usr/share/mime-info ，linux和mac（几乎整个unix树）也不遵循扩展名，只是扩展名的内容只是为了方便用户。

注意：具体应用在“/usr/share/mimelnk”（感谢 David C. Rankin）

（您也可以尝试在终端中执行locate mime 以获取更多信息）

【讨论】：

在/usr/share/mimelnk中有具体的应用链接。

感谢您的回复，抱歉回复晚了。我做了你的命令，它已经生成了很多文件，我对最后的扩展有点困惑，以找出哪个文件做什么工作。 .js 文件是否负责解释 javascript？你知道我可以阅读任何资料来分解这个吗？哪些文件将用于评估 javascript，哪些文件负责使 utf-8 发生？

一个程序检查mime信息并查看一个文件并认为：这对我来说看起来像一个JS文件，让我们检查一下如何打开它。完全忽略文件名。但是我不知道一个JS文件用什么文件，因为我自己不使用JS作为编程。

此文件路径在 Mac OS 11.2 Big Sur 上不存在

【参考方案2】：

在 macOS 上，您可以使用 file --mime "/path/to/filename" 报告文件的 mime 类型。

file 的手册页（请参阅 here）揭示了在 mime 类型查找之前发生的事情：

 file tests each argument in an attempt to classify it.  There are three
 sets of tests, performed in this order: filesystem tests, magic tests,
 and language tests.  The first test that succeeds causes the file type to
 be printed.

 The filesystem tests are based on examining the return from a stat(2)
 system call.  The program checks to see if the file is empty, or if it's
 some sort of special file.  Any known file types appropriate to the sys-
 tem you are running on (sockets, symbolic links, or named pipes (FIFOs)
 on those systems that implement them) are intuited if they are defined in
 the system header file <sys/stat.h>.

 The magic tests are used to check for files with data in particular fixed
 formats.  The canonical example of this is a binary executable (compiled
 program) a.out file, whose format is defined in <elf.h>, <a.out.h> and
 possibly <exec.h> in the standard include directory.  These files have a
 ``magic number'' stored in a particular place near the beginning of the
 file that tells the UNIX operating system that the file is a binary exe-
 cutable, and which of several types thereof.  The concept of a ``magic''
 has been applied by extension to data files.  Any file with some invari-
 ant identifier at a small fixed offset into the file can usually be
 described in this way.  The information identifying these files is read
 from the compiled magic file /usr/share/file/magic.mgc, or the files in
 the directory /usr/share/file/magic if the compiled file does not exist.

 If a file does not match any of the entries in the magic file, it is
 examined to see if it seems to be a text file.  ASCII, ISO-8859-x, non-
 ISO 8-bit extended-ASCII character sets (such as those used on Macintosh
 and IBM PC systems), UTF-8-encoded Unicode, UTF-16-encoded Unicode, and
 EBCDIC character sets can be distinguished by the different ranges and
 sequences of bytes that constitute printable text in each set.  If a file
 passes any of these tests, its character set is reported.  ASCII,
 ISO-8859-x, UTF-8, and extended-ASCII files are identified as ``text''
 because they will be mostly readable on nearly any terminal; UTF-16 and
 EBCDIC are only ``character data'' because, while they contain text, it
 is text that will require translation before it can be read.  In addi-
 tion, file will attempt to determine other characteristics of text-type
 files.  If the lines of a file are terminated by CR, CRLF, or NEL,
 instead of the Unix-standard LF, this will be reported.  Files that con-
 tain embedded escape sequences or overstriking will also be identified.

 Once file has determined the character set used in a text-type file, it
 will attempt to determine in what language the file is written.  The lan-
 guage tests look for particular strings (cf.  <names.h>) that can appear
 anywhere in the first few blocks of a file.  For example, the keyword .br
 indicates that the file is most likely a troff(1) input file, just as the
 keyword struct indicates a C program.  These tests are less reliable than
 the previous two groups, so they are performed last.  The language test
 routines also test for some miscellany (such as tar(1) archives).

 Any file that cannot be identified as having been written in any of the
 character sets listed above is simply said to be ``data''.