shared-mime-info 中文本/普通模式“*，v”的原因？

freedesktop.org 媒體類型數據庫shared-mime-info有一個與 MIME type 相關聯的文件名模式*,vtext/plain，我不知道為什麼 - 如果只是因為,v並且*,v基本上作為搜尋詞無用！

添加該模式的 2008 年送出沒有解釋它，儘管測試案例確實指出了 RedHat 的 Bugzilla 上的一個錯誤。在那裡，有人擁有文件名以 結尾的“RCS 文件” ,v，而錯誤是它們被辨識為音頻文件。沒有進一步的上下文，我只能猜測“RCS 文件”指的是修訂控制系統，而不是雷達橫截面數據或 Autodesk ReCap 掃描文件……

為什麼這個使用者的奇怪體驗會導致shared-mime-info每個人都發生變化？這是一個普遍存在的問題，也許是因為已知 RCS 會生成具有該結尾的文件？為什麼將其添加shared-mime-info到對錯誤的適當響應†中，而不是（比如說）找出為什麼這些隨機文件被視為音頻？

---

† 我說的是“響應”，而不是“修復”，因為我不清楚它是否確實解決了使用者的問題。該錯誤已關閉，因為它不再出現在該軟體的更高版本中，而這並未明確歸功於shared-mime-info.

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
@

它似乎也能夠處理至少一些二進制數據，儘管是以基於行的方式進行的。

為什麼它們會被特別辨識為音頻文件，我不知道。

問題中有足夠的資訊供您自己回答。’*,v’ 的存在是為了防止檢入 RCS 的音頻文件被解釋為音頻文件（因為文件格式不同，如果嘗試播放它們會產生錯誤）。

RCS 文件可以包含二進制數據，因為它只是將其視為另一個“字元串”。手冊頁提到了這一點，但沒有提供太多細節：

字元串由 . 括起來**@**。如果字元串包含 a @，則必須加倍；否則，字元串可以包含任意二進制數據。

file有幾種音頻/影片格式可以通過檢查文件內容的程序（例如 ）來區分。然而，MIME 傾向於通過文件名（特別是它們的“後綴”）來辨識文件，一些系統會嘗試僅使用文件名來自動推斷 MIME 類型。這本質上容易出錯，並且'*,v'是適應實現的一種解決方法。

引用自：https://unix.stackexchange.com/questions/666614