不出所料，父母從廣東搬到上海后，最不適應的就是方言：上海人聽不懂廣東話，他們也聽不懂上海話。幸好還有普通話可以說，要不就無法跟上海人交流了。

方言導致的問題很容易理解。但是在IT領域，類似問題卻困擾了很多人，尤其是當涉及到NAS共享的時候。這個類似問題就是字符編碼。比如說，不同的員工使用同一個NAS共享。員工甲存的文件名是用GBK編碼的，員工乙存的文件名是UTF-8編碼的。雙方都會覺得對方的文件名是亂碼，根本無法理解。為了解決這個問題，外企員工一般使用英文，因為每種編碼都能識別英文，就像上海人和廣東人都懂普通話一樣。但這方法并不現實，普及英文在很多單位難以做到。本文要介紹的，就是(EMC的)NAS是如何解決這個問題的。

這要從字符編碼的概念開始說起：

字符(character)：顧名思義，字符是文字與符號的總稱。英文字母，漢字和數學符號等都是字符。

編碼(encoding)：計算機只能先將字符用二進制碼來表示，然后再進行處理或者存儲。把字符和2進制碼對應起來就叫編碼。比如字母A的編碼就是1000001。

最早給字符編碼的是美國人，他們的編碼方案叫做ASCII。那時候計算機還是稀罕物，也沒人想到有一天它會在全球普及。所以ASCII編碼只包含了拉丁字母和符號，加起來也就100多個，用一個字節來編碼就足夠了(英文國家是不是文盲率很低?學好字母就差不多識字了)。

沒想到計算機普及得太快了。各國人民在學會說英文之前，已經先學會使用電腦。所以很多非英文國家為自己的文字制定了符合ANSI(美國國家標準協會)標準的編碼，比如中國的GB2312和日本的JIT。ANSI標準保留了所有ASCII編碼，所以無論是GB2312，JIT還是其他國家的ANSI編碼都支持拉丁字母。中文字符比拉丁字母多太多了，一個字節表示不完，所以GB2312用兩個字節表示一個漢字。

ANSI標準解決了拉丁字母和另一種文字共存的問題，比如中文和英文可以一起出現，日文和英文也可以。但是多種非拉丁文字卻無法共存，比如GB2312和JIT都不包含對方的字符，所以中文和日文就無法共存。有沒有辦法解決這個問題呢?還是以方言為例，我們把各地方言并在一起，看成一門語言，假如每個人都學會了這門語言，不就沒有交流問題了嗎?編碼也一樣，假如有一種編碼能把世界各地的字符都編進去，各國文字就能夠共存了。到了上世紀90年代，Unicode終于應運而生。它收錄了超過10萬個字符，包括了世界上大多數文字系統。就連不同寫法的同一個字都分別編碼，比如戶/戶/戸等等，比孔乙己還考究。

有了Unicode，字符世界是不是就和諧了呢?事實并非如此，因為Unicode只確定了編碼方式，沒規定實現方法。不同的平臺對Unicode有不同的實現，比較流行的有 UTF-8，UTF-16等。所以Unicode雖然保證了在同一平臺上多種非拉丁文字能共存，但跨平臺的時候就不一定了。比如說，用UTF-16編碼的客戶端在NAS上存了一個中文命名的文件，用UTF-8或者GBK編碼的客戶端看起來還是亂碼。

[page]

說完了這些背景，我們終于可以回到最初的話題：在(EMC的)NAS上是如何解決這個問題的?

答案就在下圖。NAS上只存UTF-8編碼。當UTF-8客戶端往NAS讀寫文件的時候，NAS不作任何轉換。當其他編碼的客戶端往NAS讀寫文件 的時候，NAS就將其轉換為UTF-8。有了這個轉換機制，所有的客戶端都感受不到編碼差異。想要了解這功能如何配置，請參考EMC公開的NAS配置手 冊。

當然，再好的設計也不是完美的。有哪位讀者能看出這個轉換機制有什么潛在問題嗎?請留言。

注：該圖片來自EMC公開的Celerra的技術文檔