大約在6月份，muchong上出現了本年度第一個關於國家自然科學基金申請書後綴問題的討論貼，自此宣告一年一度的預測大戲正式拉開帷幕。

各位蟲友紛紛發表自己的見解，有的貼出自己的申請書下載字尾讓別人幫忙解析，有的根據小道訊息拿字尾來驗證或推測，有的把往年的字尾翻出來討論，也有的勸大家洗洗睡吧別當真。即便版主一再封殺，奈何蟲友們興致太高，有段時間開啟muchong總看到清一色包含 “字尾”、“FS01”等字眼的帖子。連一向穩如泰山的我，都被撩撥得忍不住多看幾眼。儘管我在內心極力勸說自己這些都是娛樂不要當真，但還是抱有一絲憧憬。

這彷彿是“三人成虎”的現實版：一個人說不信，二個人說不信，三個人說就信了。

然而，冷靜下想想，從下載字尾名來判斷基金中沒中究竟有無合理性呢？這裡，我從計算機檔案儲存的角度來分析一下。

基金委每年受理的申請書有幾十萬份，這些申請書檔案以及申請者相關資訊都需要存放在計算機中。一般來說，和申請者有關的結構化資料可以存放在像mysql這樣的資料庫中，而申請書這樣的大檔案因為是非結構化資料，需要放在其它位置。為保證兩者能一一對應起來，申請書儲存時確實需要調整名稱。比如利用申請者的個人資訊生成一個md5值，然後申請者提交的申請書檔案就以該md5值命名（上傳檔案時，程式自動處理）。我們平時討論的申請書下載連結中的一堆亂碼和這樣的md5值有關。

此外，由於申請書檔案太多，一臺伺服器還真的不一定夠。

假設一個申請

書大小為2

M

，

本年度

共有3

0

萬份

申報書

，則申請書總

大小就是6

00G

，再加上專家評語等檔案

，

接近1

T

是

有

可能的

。

基金委用的伺服器應該比較老，

儲存時又不可能把硬碟全塞滿，

這樣算有

2-

4

臺

才能滿足儲存需要

。

下載字尾中的F

S01

,0

2

等大機率就是伺服器編號

（F

S

可看成File

S

erver的簡寫）

。

申請書發給專家審閱後，由專家在後臺給A、B、C等級和評語。這些ABC字元可以直接放在mysql資料中，而專家評語以檔案形式存放在其它位置。申請書是否獲批也就是新增像‘Y’或‘N’之類的字元，這也可以輸入到mysql中。因為只有幾十萬條資料，查詢某個申請者的本子是否得中其實非常快，掃一下mysql即可，完全不用修改申請書檔名稱，也不用把檔案從一個伺服器挪到另一個伺服器。

當然，如果這個程式設計師閒得無聊，非要在本子上會後修改檔名稱，那麼他也完全可以這麼幹，只是要多費點時間。但是這樣幹吃力不討好，還容易洩露機密，甚至丟掉飯碗，誰會蠢到此等地步呢？

所以，希望大家把關於字尾的討論當成一種消遣即可，莫當真。

個人觀點，如有不合理之處，還望多多包涵！

想了解更多精彩內容，快來關注

奔跑的青椒