獵豹的瑣事

引用自：http://blog.teatime.com.tw/1/post/110

這個世界上, 有許多不同的文化, 所以也有許多不同的文字. 而在電腦的發展上頭, 對於這些文字的處理, 不同的人有不同的處理方式. 所以, 外表看起來是一樣的字, 因為採用的編碼不同, 在電腦上頭就會出現不同的數字來表示. 反之, 在電腦上頭, 同樣的一組數字, 因為所使用的編碼不同, 在不同的編碼系統上頭, 會代表不同的字.

以我們所使用的繁體中文來說. 在一開始發展時, 就存在不同的編碼. 這些編碼都是用 2 個 bytes 來代表一個中文字.  這時就出現了前面所說的, 同樣的兩個 bytes, 在不同的編碼系統上頭, 各自代表不同的字. 這個情形雖然在相互競爭下, 最後幾乎只剩下 BIG5 編碼這一種還在世上存活. 但是, 就算在繁體中文裡頭, BIG5 取得的最後的勝利, 之前所說的情形就消失了嗎?

可惜, 這世界上, 並不是只有繁體中文一種文字, 還有簡體中文, 日文, 韓文等等系統, 也都是使用 2 個 bytes 來表示它們的文字. 所以, 同樣的一個數字, 你把它當成是繁體中文的編碼來看時, 是某個中文字, 把它當成簡體中文來看時, 又是另一個字. 在目前這樣交流頻繁的國際社會中, 此類編碼不同所造成的問題, 仍然無法解決. 就算能解決所有雙位元組編碼的問題, 在雙位元組編碼與單位元組編碼的系統之間, 仍有類似的衝突發生.

UNICODE 的出現, 就是為了解決這種各國編碼不同所造成的問題, 想要透過一種大家都可以接受的編碼, 來包含各國的文字, 如此, 大家都只要使用一種編碼, 再也沒有這類編碼衝突的問題了.

不過... 這是一種全新的編碼, 所以... 等於要大家都放棄所有的編碼系統, 等到大家都使用 UNICODE 時, 才能真正的解決問題, 否則, 也不過就是多出一種編碼, 與舊有的一堆編碼仍然相互衝突著. 而且, 目前已經存在的各種文件, 仍有待轉換到新的編碼... 這個編碼系統的轉換, 並不是一個小事, 所以... 就算 UNICODE 已經出現了一段時間, 目前距離大一統的地步, 仍有很大的一段路要走.

這類的情形, 在 Web 介面上頭, 目前的 browser 都可以很簡單的切換到不同的語系, 使用不同的編碼來看對應的網頁, 且在網頁的規格上頭, 網頁的作者也可以標明這個頁面所使用的編碼系統, 讓 browser 可以使用正確的編碼來觀看網頁, 所以編碼所造成的衝突就少了很多. 所以, 除了有必要在同一個頁面同時出現不同地方的文字, 否則, 使用每個地方特有的編碼, 一樣不會造成問題. 如果有需要同時出現不同地方的文字時, 就必須使用同時包含那些文字的編碼系統就可以. 以目前來說, 就是使用 UTF-8 編碼 (UTF-8 就 UNICODE 編碼的一種.... UNICODE 一樣也有很多編碼, UTF-8, UTF-16... 等等).

但是, 在 FTP 上頭, 就不像 Web 那麼簡單了.

因為 FTP 的相關 RFC 上頭, 之前都沒有對編碼有所定義, 所以... 在 FTP Server 上頭使用 A 編碼, 那麼, 你的 FTP Client 也必須要使用 A 編碼才能看的懂那個檔名. 所以當你要連線到一個日文的 FTP server 時, 你就必須要在日文的環境下, 才能正常的看到並操作該 server 上頭相同編碼的日文檔名.

所以, 後來就有 RFC-2640 的出現, 提出了在 FTP 傳送檔名的過程中, 可以採用 UTF-8 編碼來傳送. 也就是不管 FTP server 原本用什麼編碼, 在傳送檔名到 FTP client 時, 要轉成 UTF-8, 來傳送. 所以 FTP client 收到的就是 UTF-8 編碼後的檔名. 同樣, 如果 FTP client 送指令給 server 時, 也要使用 UTF-8 編碼來傳送, server 收到後再轉成自己 local 使用的編碼, 來操作該檔案或路徑.

這樣子, 解決了 FTP 上頭編碼的問題了嗎? 可惜並沒有. 這個方法, 只有在 server/client 都使用 UNICODE 時, 才是完美的.

在沒有 RFC-2640 之前:

• 只有雙方使用相同的編碼時, 才能正常使用.

有了 RFC-2640 之後, 在雙方都支援 RFC-2640 時, 至少多出下列幾種:

• Server 不使用 UNICODE, Client 使用 UNICODE, 就能正常使用. (如果上傳檔名或目錄, 只能用可以轉換到 Server 所使用的編碼的文字)
• Server 使用 UNICODE, 但 Client 不使用 UNICODE, 至少可以正常使用 Client 端所使用的編碼可以接受的檔名.
• 雙方都使用 UNICODE, 則所有的操作都能正常使用.

舉例來說, 在沒有 RFC-2640 之前:

• Server 如果使用 BIG5, 則, client 也要是 BIG5, 才能看的懂 server 的檔名.

雙方都支援 RFC-2640 時:

• Server 使用 BIG5, Client 使用 UNICODE,  則 client 可以正常使用 server 上的檔案或路徑. 但是如果 client 上傳或建立一個有不存在於 BIG5 的文字的檔案或路徑時,  可能會造成 server 出現問題.
• Server 使用 UNICODE, Client 使用 BIG5, 則, Client 看不懂 server 上頭那些無法轉換成 BIG5 的檔名. 只能操作那些可以轉換到 BIG5 的檔案. 至於上傳檔案或建立目錄, 並不會有任何問題, 因為 BIG5 -> UNICODE 的轉換一定可以成功.
• 雙方都使用 UNICODE, 則不管檔名是那一國的文字, 都可以正常使用.

所以... 當你要抱怨你的 FTP 出現亂碼時, 先研究看看是那兒出現了問題了吧. 這並不是 server 或 client 單方面的問題, 這個問題, 雙方其實都有可能有問題.

PS1: 上述所謂在 Web 上的情形, 並非是完全沒有問題的. 沒有問題是指 Web 的內容而言, 如果是 URL 的路徑或檔案名稱來看, 同樣存在與 FTP 相同的問題. 也就是, 目前並沒有 (應該說我不知道) 一個規則, 用來傳送那些非英文的 URL. 如果 browser 是用 UTF-8 編碼來傳送那個 URL, 但是 Server 的環境並不是使用 UTF-8, 那麼就會發生找不到該檔案的問題. 反之亦同. 可以正常使用的情形下, 也只有在剛好 browser 與 server 都使用同來的編碼時, 才會正常. 所以... 如果沒有必要 (其實就算有必要, 也要想辦法避掉), 在 Web Server 上頭的路徑與檔名, 不要使用非英文的編碼. 以免造成找不到檔案的困擾.

PS2: 之前有在推 IDN (國際網域名稱), 也就是類似 下午茶.公司 之類的名稱, 我並沒有研究這個是要用那一種編碼才算. 猜測應該也是 UTF-8 吧. 不過... 目前看來, 似乎只有中國大陸那邊有在使用的樣子, 一般人.... 打中文在網址上頭, 會覺得麻煩吧. 如果要找某組織, 通常也習慣透過 search engine 來查吧.