伊蜜澤瑞

關於數位資料的永續議題，我在之前的文章有寫過 [1]，結果文章寫太長，沒什麼人看得下去…… 但即便是這樣，那篇文章對很多問題也只有點到為止，並未深談(沒錯，數位時代的困難和應對太多了)！ 所以這篇文章，我想要以更淺顯一點的方式，鎖定在資料備份的議題上，給一些實務層面的概念和實行方式。
另外，對於覺得資料備份很重要，但不習慣看長篇文章、也沒有興趣知道細節論述來龍去脈的人， 可以直接看最後面的結論，閱讀我建議大眾對備份這件事所建議的簡短總結即可！

當數位的資料需要「交換」的時候，就自然的產生了資料到底該如何儲存、解析等與「格式」有關的問題。 當資料格式第一次定下後，隨著程式的被使用，往往無法避免的需要變更舊有的資料格式， 因為沒有人能夠在一開始就知道未來新增的各種資料需求。 這個時候，資料格式的版本控制就成為一個非常重要的議題，也是傳統上許多的程式在其生命發展中期以後會面臨的棘手問題！
對於一支程式內部所儲存的資料我們一般無需擔心， 因為這類資料不對外公開，生命週期也很短，其通常會在程式結束執行以前消逝， 因此只要程式自己能正確解析自己寫的資料就可以了； 但當資料的填寫者和接收解析者為兩個不同的程式時，一方能不能看懂另一方的資料就顯得格外重要！ 這樣的情境在平常其實很容易遇到， 比如說在網路的兩端有兩隻程式要互相交換資料、一支程式要解析由另一支程式所儲存的檔案等等。 這個時候就不能恣意變更原來的資料格式，因為另外一支程式並不隨時在自己的掌握之中； 甚至大部份的時候這所謂的另外一支程式並不是別人開發的程式，而是你自己所開發的程式， 也就是同一個程式的不同版本。 比如說你自己開發並發佈的一組 Client-Server 架構程式， 在後續的維護中你可能很難同時更新所有的伺服器和客戶端程式到最新版本， 此時就會產生不同版本 Client 和 Server 的溝通問題。 又比如說你自己開發的程式會儲存一些檔案， 那你又會面臨這個檔案能不能被新版程式辨識、或者檔案能不能被舊版程式正確解析的問題。

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

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