訊息自動轉碼的機制

雖然 LC_MESSAGES 仍然放在 /usr/share/locale 裡，但它的位置也與 過去不太一樣了。在 glibc-2.1.X 中，它是放在 zh_TW.Big5 的子目錄下， 而現在卻是放在 zh_TW 的子目錄中，這樣子的安排比起過去更為「標準」了。 正確一點來說，其實 glibc 從早期的版本到現在，原則上都是希望將 LC_MESSAGES 放在

/usr/share/locale/$<$語系名$>$_$<$地區名$>$

這樣的目錄下，也就是後頭將 .$\left<\right.$編碼系統$\left.\right>$ 名省去。其原因是 LC_MESSAGES 只是程式的訊息翻譯部分，它只和地區的用語、文化有關，而與 文字的編碼方式 (encoding) 無關。故在台灣地區的用語 (訊息翻譯)，我們叫它 zh_TW 即可。同樣的，在大陸的用語，就叫 zh_CN 即可。若非因為 兩岸地區的文化差異，導至不只是簡體與繁體的文字差別，連一些名詞與習慣用法都 有相當大的不同 (例如，我們這邊稱電腦「硬體」，對岸則稱為「硬件」；我們這邊 稱「硬碟」，對岸則稱為「硬盤」...等等)，GNU 總部甚至希望我們不要有 zh_TW 與 zh_CN 之分，直接統稱為 zh (即中文) 即可，這 樣他們更省事。然而，這在現實上是做不到的。

請注意，在這裡 LC_MESSAGES 必須要有 zh_TW 與 zh_CN 之 分，並非單純是繁體字與簡體字的問題，我們認為主要是上述的用語差別。就程 式設計的觀點來看，我們不容易做到一個完整的兩岸用語翻譯對照，因為不一樣的用語 太多，使得這樣的對照表可能會很大，也不可能做到完全精準無誤的翻譯。同時用 語也可能會隨著時間而變，這使得這樣的對照表在系統的基礎層面上變得不太實 際。就這一個角度，其實我們可以大膽一點來說，zh_TW 與 zh_CN 是 ``兩種'' 語言 (或者應該說，是同一種語文的兩種 ``地區方言'')，故它們應 該分開。因此，LC_MESSAGES 所在的位置是以語言或地區方言來做區分的。

然而，這樣的區分是與簡體或繁體的關係較小的，更精確一點來說，是與文字的編 碼方式無關的。原因是，就繁體常用的 Big5 編碼，以及簡體常用的 GB2312 編碼 而言，這兩種編碼的轉碼方式已經滿固定了，故可以靠程式來做轉換，也就是「繁 體字」與「簡體字」之間的轉換。因此，LC_MESSAGES 的內容實際上是用 什麼樣的文字編碼寫成的，並沒有關係，只要我們在翻譯 po 檔時 (請讀者回憶一 下我們在上一期的內容)，在開頭的

"Content-Type: text/plain; charset=$<$內碼名稱$>$$\backslash$n"

中，寫明這個翻譯檔是用什麼內碼寫成的即可。

事實上，比起過去的 glibc-2.1.X，現在的 glibc-2.2 還更進一步，它可以做到 LC_MESSAGES 的內容以任何它可以轉換的內碼來呈現。舉例來說，如果我 們要以 Big5 的內碼來呈現 zh_TW 的訊息翻譯，則我們只要設好 LC_MESSAGES 的環境變數即可：

export LC_MESSAGES=zh_TW.Big5

這和過去沒什麼不同。但是，我們也可以用 GB2312 的內碼來呈現 zh_TW 的訊息翻譯，就這樣子設定即可:

export LC_MESSAGES=zh_TW.GB2312

注意到這裡的訊息語文是 zh_TW，是台灣地區的用語，但呈現出來的文字 內碼是 GB2312，即簡體字，即使是當初這個訊息翻譯是用 Big5 寫成的也辦得 到。換句話說，glibc-2.2 的 LC_MESSAGES 中多了一層內碼轉換機制， 它會視目前的 locale 設定狀況而做適當轉換。如此我們可以更清楚見到 LC_MESSAGES 與文字內碼無關的本質。當然，也許讀者們會覺得用簡體字 來呈現我們台灣用語的訊息是件很奇怪的事，但同樣的原理也可以推展到 Unicode 編碼上。未來也許我們有機會、也有需要使用 Unicode 的編碼，而這時候我們仍 然只需要一份 Big5 的翻譯檔即可，而不需要再重寫一份 Unicode 的翻譯檔，因 為系統會自動幫我們轉換。

這樣的「標準」，在過去我們這邊的中文軟體開發者並沒有特別去留意，因此大家 在製作訊息翻譯檔時，都是直接放在

/usr/share/locale/zh_TW.Big5

的目錄下。當然，這樣放在 glibc-2.2 環境下也是可以運作。但就長遠來看，我們 建議大家可以慢慢將這一點改正過來，儘量朝標準來走比較好。

附帶一提，就 Big5 與 GB2312 的轉換而言，以上是理想的情況。但在實際情況， 就我們所知目前 glibc-2.2 的對這兩個內碼間的轉換仍有問題需要解決。也許有 些讀者已經可以猜到 glibc-2.2 是用什麼機制來做 LC_MESSAGES 的內碼 轉換的？沒錯，就是我們在前幾期中談到的 iconv() 介面，而我們那時也 談到，此介面用來轉這兩個內碼是有問題的，因為中間還透過了一層「基底字集」， 也就是 UCS4。我們曾私下向 glibc 的主要維護者之一 -- Ulrich Drepper 先生 徵詢過他對這個問題的看法，他認為有必要再為 glibc 加入一個 Big5 與 GB2312 之間專屬的內碼轉換模組 (即一個 gconv 模組)，他並且邀請我們加入這個模組的 開發工作。這是目前尚缺的臨門一腳，不久的將來我們將動手開發，當然也非常歡 迎有興趣的讀者一起加入開發的行列。