☰

共享 mime-info 中文本/纯模式“*,v”的原因？

tag-icon • tag-icon mime-types freedesktop rcs
共享 mime-info 中文本/纯模式“*,v”的原因？

freedesktop.org 媒体类型数据库shared-mime-info有文件名模式*,v与 MIME type 相关联text/plain，我不明白为什么 - 如果只是因为,v和*,v作为搜索词基本上没用！

添加该模式的 2008 年提交没有解释它，尽管测试用例确实指出了RedHat Bugzilla 上的一个错误。在那里，有人有文件名以 结尾的“RCS 文件” ,v，错误是它们被识别为音频文件。如果没有进一步的上下文，我只能猜测“RCS 文件”指的是修订控制系统，而不是雷达截面数据或 Autodesk ReCap 扫描文件......

为什么这位用户的奇怪体验会导致每个人的改变shared-mime-info？这是一个普遍存在的问题吗？也许是因为 RCS 会生成具有该结尾​​的文件？为什么要将其添加到shared-mime-info对错误的适当响应†中，而不是（比如说）找出为什么这些随机文件被视为音频？

† 我说“响应”，而不是“修复”，因为我不清楚它是否做过解决用户的问题。该错误已被关闭，因为它在软件的更高版本中不再出现，这并没有明确归因于shared-mime-info.

答案1

RCS 确实创建了带有,v后缀的文件：

$ mkdir RCS
$ echo hello > hello.txt
$ ci hello.txt 
RCS/hello.txt,v  <--  hello.txt
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> test file
>> 
initial revision: 1.1
done
$ ls RCS
hello.txt,v

而且它们看起来并不完全像原始文件，因此将它们识别为不同的东西可能确实是谨慎的做法。

$ cat RCS/hello.txt,v 
head    1.1;
access;
symbols;
locks; strict;
comment @# @;


1.1
date    2021.08.28.14.44.57;    author ilkkachu; state Exp;
branches;
next    ;


desc
@test file
@


1.1
log
@Initial revision
@
text
@hello
@

它似乎还能够处理至少一些二进制数据，尽管是以基于行的方式进行的。

我不知道为什么它们会被特别识别为音频文件。

答案2

问题中有足够的信息供您自己回答。存在“*,v”是为了防止检入 RCS 的音频文件被解释为音频文件（因为文件格式不同，如果试图玩他们）。

RCS 文件可以包含二进制数据，因为它将其视为另一个“字符串”。这手册页提到这一点但没有提供太多细节：

字符串包含在@。如果一个字符串包含一个@，必须加倍；否则，字符串可以包含任意二进制数据。

有多种音频/视频格式可以通过程序来区分（例如file）它检查文件的内容。然而，MIME 旨在通过名称（特别是其名称）来识别文件“后缀”），并且某些系统将尝试仅使用文件名自动推断 MIME 类型。这本质上很容易出错，并且这'*,v'是适应实施的一种解决方法。

相关内容