感謝　貴方快速回復，但對內容卻有些不同見解，說明如下。

電子書採用中文檔名是今年才正式提供，大德可能是記到其他事情了？

回復﹕

審核上述之回復，敝人回憶在撰寫對　貴方的指述內容之前，確認是在

下把某資料的年度時間忽略之後而發出錯誤指述，在此致歉！比較奇怪

的是，反省自己明明已看了二次，竟然還會出錯，只能說個人的業障之

不可思議了......

事實上，我們正是因為把使用者當成什麼都不會來對待，才會使用 zip 壓縮。

我們也知道 7z 有更好的壓縮比例，然而 7z 並非 Windows 系統預設支援的壓縮格式，而 Windows 的使用者又佔了大宗。...(恕刪)

回復﹕

對於所堅持採用zip 原因之說明，請恕在下無法認同！

個人認為所說類Windows用戶不知如何處理 7z 壓縮現象，應該是極

少數、極少數的使用者，大量不會的也許是10年前的事。問題更可能

出現在作業單位因循苟且的習氣所致！

7-zip是免費軟體，若在大藏經下載網頁有特別說明該軟體能解7z,

zip, rar 等絕大部份壓縮檔格式的優點，又是免費，採高標準的80%

信心水準來衡量，Windows用戶會樂意去下載該軟體來安裝，而不會有

煩惱。

若要再深入服務以免除例外少數者的埋怨，那就7z, zip二種壓縮格式

都同時採用，並在下載網頁上全部列出連結。

以前，在下遇到北美某功德會建議台灣大夥兒放棄自行做紙版大藏經

電子化，轉而全力支援該功德會的作業，理由是集中人力、物力以加

快進程。

這個建議也不能說錯了，但以佛的角度來看卻不必然是必須的，若其

為真，這豈不是在說﹕

您們十方宇宙所有的佛菩薩都捨棄自己的度眾誓願，

只採用我阿彌陀佛四十八願就行了！

顯然，佛菩薩的發願是沒有誰要捨棄來遷就誰的　「必須」　現象！

所以，佛菩薩的度眾生行為是﹕極細緻而普遍！

所以，想要令大藏經使用者沒煩惱嗎？.....那麼，建議　貴方多做各

種版本的準備吧！

我們並不是堅持採用 Big5，我們是在 Windows 系統中，使用 7z 的程式進行壓縮，它對檔名的處理似乎沒有選擇的功能。

回復﹕

為何　貴方在Windows 系統上使用7-zip軟體指定壓縮成zip 檔，在

Linux, 簡體Windows 上解壓縮會出現亂碼呢？

針對這個莫名的現象，敝人剛剛特別於Linux 及 Win7上做繁簡檔名

壓縮、解壓縮之交叉測試，結果都正常！並沒有所敘述現象，在下方

會呈現整個作業過程。

同時也對epub經文檔案內文之編碼格式的觀察，發現它是UTF-8 格

式。

經過這一系列的測試之後，判斷由手動製成檔名，無論繁簡於未壓縮

前都能在二個OS中正常閱讀，移至不同系統也能正常閱讀。

已壓縮檔名後，二個OS各自解壓縮後能正常閱讀，移至不同系統解壓

縮後也能正常閱讀。

綜合判斷﹕貴方製造檔名的方式，不是手動方式，最可能是使用程式

自動編寫，而程式在製成檔名時，並沒有採用UTF-8格式

，而是採用Big5格式。

最後，敝人認為　貴方的作業至少犯有一項的疏失﹕

完成中文檔名壓縮之後，沒有在各繁簡作業系統中，

做解壓縮的測試！或測試不足或不夠精細，以致於不

能提早發現亂碼問題。

*********************************************************

■ Linux (CentOS 7) 繁簡測試

０、CentOS 7 系統語言編碼格式﹕LANG=en_US.UTF-8

解壓縮軟體﹕PeaZip, Archive Manager

１、繁體文檔名

epub及pdf經文檔在Win7製成繁體文檔名，使用7-zip壓縮成

7z及zip二種格式，並都移到CentOS，然後對它們用二種解壓

縮軟體去解壓縮，全部呈現繁體文，全部正常可閱。

２、簡體文檔名

epub及pdf經文檔在Win7製成簡體文檔名，使用7-zip壓縮成

7z及zip二種格式，並都移到CentOS，然後對它們用二種解壓

縮軟體去解壓縮，全部呈現簡體文，全部正常可閱。

■ Windows 7 繁簡測試

０、Windows 7 非Unicode程式目前使用的語言﹕中文(繁體，台灣)

解壓縮軟體﹕7-zip, WinZip v22

１、繁體文檔名

epub及pdf經文檔在CentOS 7製成繁體文檔名，使用PeaZip壓

縮成7z及zip二種格式，並都移到Windows 7，然後對它們用

二種解壓縮軟體去解壓縮，全部呈現繁體文，全部正常可閱。

２、簡體文檔名

epub及pdf經文檔在CentOS 7製成簡體文檔名，使用PeaZip壓

縮成7z及zip二種格式，並都移到Windows 7，然後對它們用

二種解壓縮軟體去解壓縮，全部呈現簡體文，全部正常可閱。

在 2013 年，您還有留言，告知我們您在 SCIENTIFIC LINUX 6.2 測試失敗。

何來所謂 "在開發階段就建議採Java可通用各系統，結果被否決，致今日Linux 已成被遺棄者！" 以及 "為何只支援要收錢的作業系統？看不起沒有錢的法友嗎？" 這些莫須有的指控呢？

回復﹕

敝人對於　貴方開發閱讀器，共有二次有關程式上的明確建議。

第一次在　貴方要求我方協助時，我回函要求採用專案委託模式

，由我方負責全部開銷費用，並且定時作開發進度報告，結果

貴方在我方去函之後，就音訊全無......

第二次是在SCIENTIFIC LINUX 6.2幫　貴方測試，結果不能正

常執行。

敝人之前所說的　「在開發階段就建議採Java可通用各系統，結

果被否決」　，是指　貴方目前CBReader 並沒有採用Java，這

就是結果被否決之意思。若有採用在下的建議，用Java開發，目

前在Linux上就已經能使用CBReader，但結果則否！

當初在下特別去寫個簡單Java程式在Linux rpm系列, Winows

測試，結果並不是同樣Java程式完全不能在Windows, Linux(

rpm, deb系列) 上執行，差別在Java的開發架構上要設定正確

，並做某部份程式微調而已，沒有想像中的繁雜、無法執行的

下場。

不行，這二字通常是輪迴者的理由！

在實務上，有不少軟體是由Java開發，而在Linux, Windows,

macOS上皆能執行，例如很著名的 NetBeans IDE。

這一次我牢騷CBReader 不能在Linux執行，當然是指　貴方已

放棄Java之後的現狀。我納悶的是，為何程式要放棄Linux執行

呢？

佛菩薩度化眾生是凡有緣則予以度化，像　CBReader 這樣要服

務全球閱大藏經者，架構必須採與佛菩薩不遺有緣的心態去做，

怎能遺忘現前興盛的開源系統使用眾生呢？

我後來思惟，可能　貴方不採用Java開發的新專案企畫時不夠周

延與詳盡，以致於犯上與放棄Java開發的同樣的錯誤，那就是採

用錯誤架構！！

若考量CMMI專案對軟體的九大品質要求，如下﹕

- 有效性　　(availability)　： 隨時可以進入操作的能力

- 適應性　　(flexibility )　： 需求變更時容易被改寫的能力

- 功能性　　(functionality)　： 執行所有必要功能的能力

- 維護性　　(maintainability)： 容易修正的能力

- 可移植性　(portability)　　： 在新的環境容易被修改的能力

- 可靠性　　(reliability)　　： 一致性與正確執行的能力

- 重複使用性(reusability)　　： 在不同的應用中可以重複使用的能力

- 可測試性　(testability)　　： 容易且完整地測試的能力

- 使用性　　(usability)　　　： 容易學習與使用的能力

那麼，並不會發生軟體只能在Windows, macOS執行，卻不能在

Linux執行的弊病。至少以下的架構是通用的、被人熟知的，就

能執行﹕

C/C++, wxWidgets

當然，我現在的發言有馬後跑的嫌疑，但CBReader今日不能在

Linux (rpm, deb系列)執行卻是事實。這麼大‧方‧廣服務全

球眾生的專案何以會出現這麼不可思議錯誤呢？......

請，不用再回復任何理由，自行思惟即可！

更重要的議題是﹕

如何在現今架構之下，使得CBReader 源碼重編譯之後，

其Native Code 能在Linux中執行？

嗯，在下說的是Native Code，而不是拐彎使用Wine or

VirtualBox 之類的虛擬器去達成目的，若硬要如此，mac OS

版本也不用開發了，同樣使用虛擬器就行了。

※上述發文有簡單校稿，若仍發生辭不達意時，敬請見聞者寬容並

自行腦補，謝謝！