FTP 語系, 編碼, unicode

Tommy 碎碎念 : FTP 語系, 編碼, unicode

post by tommy @ 11 八月, 2006 10:42

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

以我們所使用的繁體中文來說. 在一開始發展時, 就存在不同的編碼. 這些編碼都是用 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 來查吧.

Tags: utf8

[@more@]V