一切都是 Windows 的錯:為甚麼 ArOZ Online 會出現 UM檔案 及 HEX資料夾 名命法
這甚麼爛東西,為甚麼要把一般的檔名全部編碼起來?那我用 Samba 的時候怎樣知道這個檔案是甚麼檔案?某 Beta 測試用家 沒錯,這一篇文章就是用來介紹到底為甚麼 ArOZ Online 要使用一個這麼麻煩的編碼方法來儲存檔案名稱及資料夾名稱。先由結論說起:這一切都是 Windows 的錯! 在這裡我先解釋一下甚麼是 UMFilename 跟 HexFoldername。這兩個是 ArOZ Online 用來給檔案及資料夾名稱編碼的方法,簡單來說就是把檔案名字使用 "inith" + bin2hex(原檔名) + "." + 原副檔名 和把資料夾使用 bin2hex(原資料夾名稱) 來編碼的一個神奇儲存方法。一般如果你在用 ArOZ Online 的檔案管理員你會看到有一些使用者自行上載的檔案會出現 綠色 或 藍色 底色的,那就是經編碼後的資料名稱。 HexFoldername 在 File Explorer 上顯示為綠色 UMFilename 在 File Explorer 上顯示為 藍色 故事起源: ArOZ Online Alpha ArOZ Online Alpha 是一套使用 PHP 5 編寫的影音串流系統,本來是用於 Windows + WAMP 的網頁伺服器架構上。而開發者我使用的 Windows 7 本身是 Big-5 編碼的,因此對中文的支援是完全 OK 的,但是我除了中文音樂之外也有聽日文的音樂,而問題就出在了這裡: PHP5 在讀取日文檔案名稱的時候出現亂碼。 ArOZ Online Alpha 的音樂播放界面 對於這個問題,基本上一般人想到的就只有這幾個解決方案: 把伺服器重灌,裝個 Unicode 版的 Windows 或者使用 Linux使用 Linux VM 並在 VM 裡面運行系統把檔案名稱全部放到 Database 裡,然後根據檔案路徑找到 Unicode 編碼的檔案名字。 然而,由於這套系統的無 DB 特性,第 3 點就不能用了;第 1, 2 點也太麻煩了完全不附合成本效益,所以最後的解決方法是:上載的時候使用 PHP 把檔名編碼成一個只使用 ASCII 的字串,然後以編碼字串來儲存,要讀取的時候從系統讀取檔名然後解碼出原本的檔名就好了。 可是,另一個問題就出現了。如果檔案名字本身就是以我編碼的方式儲存怎辦?例子: 音樂.mp3 -> abc.mp3 然後又剛好出現一個 abc.mp3?所以就乾脆直接在編碼後的檔案名字前加上 "inith" (Initiate with Hex Value),用以分辨是我方編碼的還是原本已經編碼的檔案,就是這樣,這種 UMFilename 的初型就出現了。 那為甚麼這種編碼方式叫做 UMFilename? 在剛開發 ArOZ Online Beta 的時候,最基礎的模組只有 Audio,Video 跟 Photo。基本上就是用以代替 ArOZ Online Alpha 的基本功能。 然而,這三個模組都需要上載功能,而由於 ArOZ Online Beta 的模組化設計原則,一個新的模塊被設計了出來: Upload Manager。 ArOZ Online Beta Audio 模組裡的 Upload Manager 界面 由於這個 Upload Manager 同樣遇上跟之前 Alpha 版本時的系統編碼問題,於是就直接把 Alpha 版的檔案名編碼方式搬過來了。而本來並沒有特別名稱的這種編碼方式也跟著這個模塊的名字改了起來,變成了 Upload Manager special File Naming Method,簡稱 UMFilename(或有人稱為 inith 命名法 或 inith filename)。 那 Hex Foldername 又是哪裡出來的? 在 ArOZ Online Beta 檔案管理員開發中的時候,一個 Bug 出現了。由於系統內的資料夾全部都是英文,直到桌面模組出現了之後才有機會因使用者新增資料夾的關系出現中文的資料夾名稱。到了中文的部分其實還是不大問題,因為中文還可以透過 PHP 的 mbstring 解決,然而日文的資料夾名稱就無法載入了。就結果而言,資料夾的命名需要另一個特別的編碼方法。 其實到發現這個問題的時候已經是滿後期的了,之前已經發生過不少因檔案名字過長而無法開啟的情況。(因為…