關於數位資料的永續議題，我在之前的文章有寫過 ^[1]，結果文章寫太長，沒什麼人看得下去…… 但即便是這樣，那篇文章對很多問題也只有點到為止，並未深談(沒錯，數位時代的困難和應對太多了)！ 所以這篇文章，我想要以更淺顯一點的方式，鎖定在資料備份的議題上，給一些實務層面的概念和實行方式。

另外，對於覺得資料備份很重要，但不習慣看長篇文章、也沒有興趣知道細節論述來龍去脈的人， 可以直接看最後面的結論，閱讀我建議大眾對備份這件事所建議的簡短總結即可！

因為最近的需要，在折騰網路檔案分享相關的東西，於是上網搜尋了不少資料。 要讓多位使用者可以互相分享、交換檔案，就需要佈置網路檔案系統， 而網路檔案系統種類繁多，因此很自然的會產生一個問題：「我應該選擇哪一個檔案系統？」 看到網路上對這個問題的討論，絕大部分都集中在檔案傳輸效能上，讓我覺得頗為奇妙！ 因為不同的檔案系統存在不同的結構差異，在什麼場景下應該最適合什麼檔案系統這個問題 並不是一個效能屬性就能夠覆蓋的，在不適合的環境下選擇不適合的檔案系統， 甚至會讓你付出數倍的心力來處理這個檔案系統所引發的各種缺陷！ 因此接下來我就要分享一些這陣子折騰網路檔案系統的心得， 希望能夠幫助有需要的人在選擇網路檔案系統時能夠更全面的思考。

網路檔案系統就是能夠讓網路上某臺電腦的某個設為分享的資料匣， 把它模擬成使用者自己的電腦上的磁碟的機制。 這樣，使用者就可以用一般的方法讀寫這個看起來像自己電腦裡面的磁碟， 但實際上確是在存取遠端電腦上的檔案。 網路檔案系統種類非常多，這裡只會簡單介紹並分析三個比較知名、也是我這回嘗試過的網路檔案系統： CIFS、NFS、以及 SSHFS。

「自由軟體真是好東西！」 我就直接開門見山不賣關子了，這篇文章就是來說服大家使用自由軟體的！

你常使用盜版軟體嗎？沒有盜版軟體就不知如何使用電腦嗎？ 望著許多軟體高貴的價格讓你買不下手，不知學什麼好嗎？ 自己的數位檔案必須依賴特定軟體、甚至特定版本才能正常開啟使用， 害怕有一天這軟體不再能用時，一輩子的檔案就付諸東流嗎？ 想研究、學習、了解軟體到底是如何工作的，甚至喜歡寫軟體嗎？ 或者只是不知道什麼是自由軟體而想要了解嗎？ 如果你符合以上任一情況，你就是這篇文章的寫作對象， 我也誠摯的邀請你來了解，最好實際使用自由軟體，也許它會給你一些解答。

前言

這本是為了回答一位朋友的問題，寫著寫著就變成一篇文了！貼在這裡也能給有相同疑惑的人做個參考。

對使用電腦稍微熟悉的人應該都知道，多數的作業系統都有一個純文字的操作環境， 以主流的 Windows 為例，開啟「命令提示字元」這支程式就可以使用這樣的環境。 在這文字的環境下，使用者依然可以執行許多的系統操作， 使用者輸入文字命令給電腦，然後電腦可能也會以文字訊息回報給使用者； 在這裡一切都是文字，沒有圖片、也沒有按鈕。 許多人可能都會覺得這個介面不容易學習使用，也可能會覺得這個介面既不美觀也沒有現代感， 同時也產生了可能很多人都共同存在的一個疑問：為什麼這種落伍的操作環境仍然存在而沒有被淘汰？

當數位的資料需要「交換」的時候，就自然的產生了資料到底該如何儲存、解析等與「格式」有關的問題。 當資料格式第一次定下後，隨著程式的被使用，往往無法避免的需要變更舊有的資料格式， 因為沒有人能夠在一開始就知道未來新增的各種資料需求。 這個時候，資料格式的版本控制就成為一個非常重要的議題，也是傳統上許多的程式在其生命發展中期以後會面臨的棘手問題！

對於一支程式內部所儲存的資料我們一般無需擔心， 因為這類資料不對外公開，生命週期也很短，其通常會在程式結束執行以前消逝， 因此只要程式自己能正確解析自己寫的資料就可以了； 但當資料的填寫者和接收解析者為兩個不同的程式時，一方能不能看懂另一方的資料就顯得格外重要！ 這樣的情境在平常其實很容易遇到， 比如說在網路的兩端有兩隻程式要互相交換資料、一支程式要解析由另一支程式所儲存的檔案等等。 這個時候就不能恣意變更原來的資料格式，因為另外一支程式並不隨時在自己的掌握之中； 甚至大部份的時候這所謂的另外一支程式並不是別人開發的程式，而是你自己所開發的程式， 也就是同一個程式的不同版本。 比如說你自己開發並發佈的一組 Client-Server 架構程式， 在後續的維護中你可能很難同時更新所有的伺服器和客戶端程式到最新版本， 此時就會產生不同版本 Client 和 Server 的溝通問題。 又比如說你自己開發的程式會儲存一些檔案， 那你又會面臨這個檔案能不能被新版程式辨識、或者檔案能不能被舊版程式正確解析的問題。

不知各位在閱讀或交換純文字文件的時候是否曾有過這些困擾：

有些文件打開後發現換行錯亂，整份文件被縮在同一行？

終於進入最後一個主題了，對很多人來說這次的主題應該才是值得關注的重點吧！前面的主題都在告訴大家文字編碼的歷史以及規格，而這次的主題將是作者我在Unicode程式設計上對於文字編碼所遇到的問題、心得經驗、與對策；但也由於這次內容是以我的經驗與心得為主，因此難免較為主觀。

雖然Unicode在1991年就已問世，但由於一般人不能體會Unicode的重要性，加上習慣與惰性以及一大堆以傳統編碼為基礎的軟體已經存在，因此Unicode的推動並不順利。

Universal Character Set (UCS) and Unicode Transformation Format (UTF)

對於Unicode如何組成二進位資料這件事情，各方有不同的想法，因而發展出多套各有特色的Unicode編碼方式，其中最出名或最被廣泛使用的三大編碼機制為：UTF-32(UCS-4)、UTF-16(UCS-2)、與UTF-8。它們的編碼細節以及優劣分析將在下面說明。

Unicode誕生

從1980年代開始，人們漸漸受到世界各地混亂的編碼系統所苦，一個有效的解決方法便是重新制定一個全新的、廣納各國各語各文字的大型編碼系統，然後用力推廣它，用它來取代與統一各國各行其事的字碼表系統。

ASCII 的限制

ASCII 碼最大的缺點就是只能夠對應英文字母、數字、以及簡單的英文符號，沒有辦法處理歐洲諸國文字，至於亞洲諸國文字就更不用提了！在商用電腦乃至於個人電腦漸漸普及的時代，這些問題漸漸浮上檯面。

字碼表

首先先解釋字碼表是什麼東西。寫過程式的人都知道大部份電腦語言有兩種基本變數，即整數 ( 各種長度與有號無號 ) 與浮點數 ( 同樣也有不同長度 ) ，有些新人會說還有字元啊、邏輯值啊！但其實這些都被歸類為整數。探討邏輯值的部份就脫離主題了，因此我們只研究關於字元的部份。

從我開始研究Unicode編碼，從而想要寫這樣的一篇文章已經很久了。看到許多人都還在使用舊式的BIG-5編碼，有些人甚至不知道他正在使用一個充滿問題的舊式編碼系統，那時我就覺得應該要寫篇關於文字編碼的文章。

後來東西愈寫愈多，於是我將文章分拆為幾個主題。這一系列文章的寫作對象主要是新手程式設計人員，當然我會盡可能寫的淺顯易懂以至於一般人也有機會看得懂。不過再怎麼簡單，在看這一系列文章之前建議先俱備下列幾個條件：

氾濫的盜版、道德的淪喪