请问locale/字型设定中, 大小写是否重要?

[nksin]

在locale/字型设定中, 大小写是否重要? 如zh_CN.GBK zh_CN.gbk
*-*-.. --GB2312.1980-0 gb2312.1980 有区别么. 看了一些资料, 有的说没关系.

我的gtk程序总说GBK-0字型找不到.

另外如何同时显示简繁体啊, 象win2k/XP那样. 有关的locale/font如何设定?

thanx

[moto]

1.大小寫很重要囉...因為程式會依據大小寫判斷...至於有時候為甚麼大小寫沒差，那是因為相關程式有把大寫跟小寫都加入判斷..
2.簡體問題我不熟..可能得請高原兄協助...
3.目前 Linux 走 I18n 架構..要同時顯示簡繁就得看每個軟體自己的處理，Win2k/XP 是作業系統整個都走 Unicode 了，所以簡繁同時顯示都沒問題...

[nksin]

喔, 看来还要更用力研究,...
经历了N次的安装, 每次都要改这个那个, 打算将source package 重新改改,
安装上就是我想要的. xixi
moto兄对此有什么建议么?

1.大小寫很重要囉...因為程式會依據大小寫判斷...至於有時候為甚麼大小寫沒差，那是因為相關程式有把大寫跟小寫都加入判斷..
2.簡體問題我不熟..可能得請高原兄協助...
3.目前 Linux 走 I18n 架構..要同時顯示簡繁就得看每個軟體自己的處理，Win2k/XP 是作業系統整個都走 Unicode 了，所以簡繁同時顯示都沒問題...

[wctang]

OpenI18N locale name guideline:
http://www.li18nux.org/docs/text/LocNameGuide-V11.txt

重點節錄：
The Standard Locale Name shall be a character string consisting of
characters from the following character repertoire:

a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
- _ . @ , =

The LANGUAGE, TERRITORY, CODESET and MODIFIERS fields shall be
ordered as:

LANGUAGE_TERRITORY.CODESET@MODIFIERS

LANGUAGE:
If ISO 639-1 defines a two-letter language code for a language,
that value shall be used as the standard value for the language.
In this case, the standard value shall consist of two lowercase
letters.

If ISO 639-1 does not define a two-letter language code for
a language, a code defined by ISO 639-2 for the language
shall be used as the standard value. In this case, the standard value
shall consist of three lowercase letters.

In order to not conflict with future extensions to the ISO 639 series
standards, user/implementation-defined values for the LANGUAGE field
shall include uppercase LETTERS or consist of more than three letters.

TERRITORY:
If ISO 3166-1 defines a two-letter region/country code for
a territory, that value shall be used as the standard value
for the territory. In this case, the standard value shall consist of
two uppercase letters.

In order to not conflict with future extensions to ISO 3166-1,
user/implementation-defined values for the TERRITORY field shall
include lowercase letters or consist of more than two letters.

CODESET:
The syntax of the field in ABNF [RFC 2234] is:

CODESET = STRING1 *( "-" STRING2 )
STRING1 = 1*LETTERS
STRING2 = 1*(LETTERS / NUMBERS)

STRING1 shall consist of uppercase LETTERS only.
STRING2 shall consist of uppercase LETTERS, NUMBERS, or both.

In order not to conflict with the standard values for the CODESET
field, user/implementation defined values should include either
lowercase LETTERS or NUMBERS in STRING1.

小結：
依照上面來看，大小寫有差，而且應該要是 zh_TW.BIG-5，zh_CN.GBK
zh_CN.GB-2312。
可是依我的印象，不知道在哪看過，locale 應該要大小寫沒差。如果有人知道的話能不能補充一下

再來，大家可以看一下 browser 中的 language 的設定，裡面設定的方式好像都是 zh-tw, zh-cn, en-us, zh
之類的，好像不合於設定，有人知道這邊這個是什麼標準嗎?

[高原之狼]

2.簡體問題我不熟..可能得請高原兄協助...

既然被 moto 兄點了名，我就出來說兩句吧。

我對整個簡體中文環境架構也不熟悉，所以只說說我知道的，而且還不一定準確……

首先 locale 的名稱是大小寫敏感的，原因很簡單，因爲 locale 是 glibc 的一部分，而 C 是大小寫敏感的。但是現在的問題在於各處的用法不一致，不知是版本的問題還是 distribution 的問題。所以要解決這個問題首先要弄清自己環境的設定，在 Debian 裏面標準的寫法是全大寫，比如 zh_CN.GB2312，zh_TW.BIG5。但是這樣還不夠，因爲各個應用程序有可能又有自己的寫法，所以還要看應用程序的説明，我印象最深的就是老的（1.0.3）Abiword 居然用 zh-CN 這樣的寫法。

而簡繁共存是相當不同的另一個問題。首先你要知道你的應用程序的 encoding，然後你要確認這個 encoding 能夠同時支持簡體和繁體，也就是說要有簡體字和繁體字的編碼。以 zh_CN.GB2312 為例，這裡的 zh_CN 是 locale，而 GB2312 就是 encoding。GB2312 是一個只有簡體字的 encoding，而 GBK 就同時支持簡體字和繁體字了。UTF8 是 Unicode 的一種表示，自然同時支持簡體和繁體了。（如果有臺灣的朋友熟悉 BIG5 encoding 的歷史，還請不吝賜教。）如果你的 encoding 沒有問題，下一步就是找到相應的字體，一般來説比較新的 TrueType 字體都是支持 GBK 的（其實應該叫做 Windows codepage 936，但那就説來話長了），所以如果你能看到中文，應該就沒有問題，只要選擇合適的 encoding 就行了。

但是如果你不僅僅是要簡繁共存，還要 GB 和 BIG5 兩種 encoding 共存（比如你要打開別人的文件），那就基本不可能了。因爲 GB 和 BIG5 用同樣的一個編碼（實際就是一個正整數）表示不同的字符，這也就是我們經常遇到的亂碼的原因。

所以如果你有具體問題，請說清楚你的運行環境（Debian version, GNOME or KDE, application, etc.）。現在整個 i18n 支持的變化都比較大，是個轉型時期，所以可能要麻煩一些，具體情況具體分析。

拉拉雜雜地說了這麽多，不知能不能幫上一點忙，還是把你說得更糊塗了……

[nksin]

2.簡體問題我不熟..可能得請高原兄協助...

既然被 moto 兄點了名，我就出來說兩句吧。

我對整個簡體中文環境架構也不熟悉，所以只說說我知道的，而且還不一定準確……

首先 locale 的名稱是大小寫敏感的，原因很簡單，因爲 locale 是 glibc 的一部分，而 C 是大小寫敏感的。但是現在的問題在於各處的用法不一致，不知是版本的問題還是 distribution 的問題。所以要解決這個問題首先要弄清自己環境的設定，在 Debian 裏面標準的寫法是全大寫，比如 zh_CN.GB2312，zh_TW.BIG5。但是這樣還不夠，因爲各個應用程序有可能又有自己的寫法，所以還要看應用程序的説明，我印象最深的就是老的（1.0.3）Abiword 居然用 zh-CN 這樣的寫法。

而簡繁共存是相當不同的另一個問題。首先你要知道你的應用程序的 encoding，然後你要確認這個 encoding 能夠同時支持簡體和繁體，也就是說要有簡體字和繁體字的編碼。以 zh_CN.GB2312 為例，這裡的 zh_CN 是 locale，而 GB2312 就是 encoding。GB2312 是一個只有簡體字的 encoding，而 GBK 就同時支持簡體字和繁體字了。UTF8 是 Unicode 的一種表示，自然同時支持簡體和繁體了。（如果有臺灣的朋友熟悉 BIG5 encoding 的歷史，還請不吝賜教。）如果你的 encoding 沒有問題，下一步就是找到相應的字體，一般來説比較新的 TrueType 字體都是支持 GBK 的（其實應該叫做 Windows codepage 936，但那就説來話長了），所以如果你能看到中文，應該就沒有問題，只要選擇合適的 encoding 就行了。

但是如果你不僅僅是要簡繁共存，還要 GB 和 BIG5 兩種 encoding 共存（比如你要打開別人的文件），那就基本不可能了。因爲 GB 和 BIG5 用同樣的一個編碼（實際就是一個正整數）表示不同的字符，這也就是我們經常遇到的亂碼的原因。

所以如果你有具體問題，請說清楚你的運行環境（Debian version, GNOME or KDE, application, etc.）。現在整個 i18n 支持的變化都比較大，是個轉型時期，所以可能要麻煩一些，具體情況具體分析。

拉拉雜雜地說了這麽多，不知能不能幫上一點忙，還是把你說得更糊塗了……

先谢狼兄的详解, 我用的是woody, 汉字显示正常, ( wmaker OK的说)
LOCALE 是 zh_CN.GBK ;
那关于字型的描述, big5 和 BIG5 , gbk 和 GBK是否一样?
fonts.dir里的都是小写, 可 GDK的出错信息说GBK-0没有找到.

刚才也查了些资料, 我用zh_CN.UTF-8 , unifont可以简繁同显 , 当然是utf-8的文件啦, 不过好丑, 有 utf-8的TrueType字型么?
现在是big5, gb2312/gbk, utf-8 编码含义不同, 不知道gb18030如何?
我知道他兼容gb2312/gbk ,
我的理想的linux/X 是可以同时显示简, 繁, 可以输入简繁, 还要PP的字体,
hehe , 要求是否高了?
嗯, 以后不应该说linux中文汉化了, 应该说linux国际化

[wctang]

關於繁簡共存，提供一些我的經驗。

大致上的確是 locale 的 codeset 的問題。因為以目前 i18n 的架構下，文字的顯示標準上要
轉成 locale 的 codeset 設定，也就是要轉碼的意思。
這是什麼意思呢，如果你在讀一篇德文的文件，如果程式知道他是德文的話，他應該要能轉成
你 locale 儘可能能看到的情況，也就是說，如果你的 locale 是設成 utf-8 的話，就要先
轉成 utf-8 再給你看。程式如何知道一篇文件的語文呢，可由 mime 之類，或是一些設定值
來知道。

為什麼這麼做呢，因為你的 locale 本來就代表了你能看到的 codeset 了，而如果給你看不同
codeset 而且不相容的文字的話，只可能是亂碼了。這個運作可以由 email client 和 web browser
來看到他的運作方式。不過 browser 太強大了，不太準(什麼都可以讀…)。

至於如果不知道文件的 codeset 的話，那就沒辦法了，只好 raw 丟出來，能看就看，不能看拉倒。
這也是比較好的做法，像以前一些 news reader，以前的 bbs 文章沒有設定 charset，他就預設
全部轉成 iso8859-1(大西方主義 )，所以所以的 big5 和 gb 全變成亂碼。

所以這就有個好習慣了，網路上的文件一定要有設定編碼。如 email, news post, html, xml...
無一不把 charset 的問題考慮進來，而在產生這些文件時也一定要設定正確的 charset，還有
看過以前的中文 BSD FAQ 叫人家把 news client 的 charset 設定 iso8859-1，讓他們 post
的文件說是 iso8859-1，其實是 big5，結果看的時候全部亂碼，真是 @%^&*#...

至於 windows 的做法就有所不同，他是系統內部預設使用 unicode，這句話的說，因為 windows
所有的顯示都要經過 windows 系統(先不考慮例外… )，如果程式要顯示一段文字的話也要呼叫
windows 的 api 來顯示，而且要顯示的話要告訴 windows 要顯示的文字本身的 charset，而
windows 會全部先轉成 unicode 再說，不過這段文字是要用來顯示或是 output 或是幹嘛。
所以只要你的程式知道自已要顯示的文字是什麼編碼方式，windows 顯示就不會有問題，不用
考慮使用者設定的 locale 是什麼。所以我可以完全沒問題的在英文的 windows 來使用中文的
軟體。至於還是要設定 windows 的地區設定，這是因為當從系統內部要輸出 io，像是存檔，
網路輸出，或是...，不管什麼，也是預設先轉成你的 locale 設定的 charset(也先不考慮例外… )
(locale 不只代表你能讀什麼，也代表你能輸出什麼)。

windows 的作法其實是比較正確的。
因為 windows 是中央集權，只要 windows 哪一天說要變天，就變天了(在 win2000 出現是就真的
變天了，因為一般的 user 也使用了全 unicode 的系統)，
至於 Linux，是 kernel 根本不知道有 locale 這件事，這是 glibc 做的(當然 windows 也不是
kernerl 做的啦)。

而除了文字的 charset 的問題外，還有字型的問題，windows 也是中央集權，根本沒問題。而 linux
也是因為有太多解決方式，不過都無法統一天下，而且也有太多太多程式自己弄自己的，所以困難度
大增。
還有一點，就是 Linux 常使用 console 模式，可是個有點問題。因為 telnet protocol 是不設定
charset，他就只是傳送工作，可是 telnet 又是用來 login 遠端的，再加上 term 模式的影響(這
我就不熟了，只知道會有影響)，所以會變成遠端的 locale 可能和本地顯示的 locale 不同，問題
就又出現了。

啊，標題是繁簡的問題，我一直都在說編碼的問題了…@@
繁簡的問題基本上就是編碼的問題，不過還要再多一些，因為中文的字數太多，還有就是編碼
種類特多，又有很多都不相容，所以問題也特別多。

拉拉雜雜說這麼多，其實只是個開頭而已。中文問題真的是太多了，其實有個比較好的
方法來解決，就是 utf-8，我覺得這大概是目前比較看得到未來又較相容的解法了

[nksin]

小结一下, gb2312/gbk/big5 和 unicode一样是一种编码形式, 他们所能表达的字符的
范围, 数量,不同, 同样一个0xC2 0xA9 表示的字符都不同.
而UTF-8是unicode 的一种(外部) 存储形式, GB18030也是这样, 基本是和UTF-8并列.
gb2312/gbk/big5/gb18030/UTF-8 <---> UNICODE

对否.?

BTW: 我喜欢这儿的气氛, 大家畅谈, 今日获益良多.
舒畅啊.

[moto]

是啊是啊...聽得高原兄及 wctang 兄的精闢的解說 ...真是獲益非淺...

[高原之狼]

感謝 wctang 兄的講解。我以前一直以爲只有 Windows 2000 以後的版本才時使用 Unicode 的（從來沒有用過英文版的 Windows 98）。

[高原之狼]

小结一下, gb2312/gbk/big5 和 unicode一样是一种编码形式, 他们所能表达的字符的
范围, 数量,不同, 同样一个0xC2 0xA9 表示的字符都不同.
而UTF-8是unicode 的一种(外部) 存储形式, GB18030也是这样, 基本是和UTF-8并列.
gb2312/gbk/big5/gb18030/UTF-8 <---> UNICODE

对否.?

不盡然。

所有的這些都是編碼形式（encoding），UTF-8 並沒有什麽特殊之處，之所以會給你這樣的錯誤印象，是因爲使用 Unicode 的應用程序經常到輸入輸出時都會從 Unicode （嚴格説來應叫做 UCS-2）轉換成 UTF-8，因此你會以爲 UTF-8 是 Unicode 的存儲形式。其實它們是不同的編碼，只不過一個適合程序内部使用，一個適合程序閒的通訊而已。

既然你有興趣，我就再多說幾句。

所謂 encoding，就是建立各個正整數序列和字符圖形（glyph）之間的一一對應關係，這樣計算機在存儲文字的時候，只要存儲一些整數就行了。

首先要區分的是定長 encoding 和變長 encoding。因爲選來表示 glyph 的整數都是一樣大的（不然怎麽知道下一個整數多長？），所以勢必有兩個選擇：用比較長的整數，每個 glyph 用一個整數代表；或者用比較短的整數，用一個長度不定的整數序列表示一個 glyph。

另外要分清的可以轉換和兼容。有些 encoding 之間是可以轉換為另外的 encoding 的，就是說 encoding A 中的每一個 glyph 都可以用 encoding B 中的編碼表示。這個表示可以和 A 中的表示相同，也可以不同，關鍵在於所有的 A 中的字符都包括在 B 中。而兼容是指 A 中代表一個 glyph 的一個或一串整數，在 B 中也代表同樣的 glyph，稱作 B 兼容 A。（這裡的兩個名詞是我自己用來方便的，並不是什麽官方的標準。）

大家最熟悉的基本 encoding 應該就是 ASCII 了。嚴格説來 ASCII 是 7-bit 的 encoding，有 128 以上的整數的應該叫做擴展 ASCII。後來計算機發展中，各國有自己的 encoding，差不多每個 encoding 都兼容 ASCII ，但是彼此之間都不兼容。這些 encoding 絕大多數都是 8-bit 的，包括 ISO-8859 的一系列，Big5，GB2312，都在此列。

後來終于有人發現這是個大問題，於是就有了 Unicode。嚴格説來 Unicode 並不是一種 encoding，而是一個 glyph 大集合，匯集了全世界使用的所有字符，並且任何現有的 encoding 包括的 glyph 都能在這個大表中有一席之地。

爲了表示 Unicode 這個大表裏面的 glyph，有不同的 encoding 可以選擇。最常用的是一種 16-bit 的定長 encoding，叫做 UCS-2，一般人們就把它簡稱為 Unicode。實際上現在 UCS-2 已經不能表示所有的 Unicode glyph 了，只不過不能表示的那一部分我們很少用到而已。

但是 16-bit 的 UCS-2 顯然不兼容 8-bit 的 ASCII，所以 UTF-8 就被發明出來，它是 8-bit 的變長 encoding，兼容 ASCII，可以和 UCS-2 相互轉換。由於一般的應用程序也都習慣於處理 8-bit 的字符，所以 UTF-8 是數據傳輸中的常用編碼。

大陸使用的 GB（國標）系列 encoding 是另一個故事。最早的 GB2312 是只有簡體字的 8-bit 變長 encoding，兼容 ASCII。後來 Windows 發現繁體字也要支持，就發明了一個兼容 GB2312 的 encoding，標準叫法是 Windows codepage 936，也叫做 GBK（國標擴展），它也是 8-bit 的變長編碼。據我所知 GBK 從來沒成爲過正式的國家標準，只不過因爲 Windows 的普及，它已經成爲事實上的標準了。後來國家頒佈了新的 GB18030 標準，還是 8-bit 的變長編碼，只不過從 GB2312 和 GBK 的最長雙字節編碼變成了最長四字節編碼，這樣就多了很多位置，把日文、韓文和很多少數民族文字都包括進來了。GB18030 是基本兼容（只有一個例外）GBK 的（誰敢不兼容 Windows），所以也就兼容 GB2312，兼容 ASCII。

Big5 我知道的就少了，只知道它也是 8-bit 的變長編碼，最長雙字節。最早的 Big5 缺了很多字符，後來各種系統有不同的擴展，好像比較流行的是倚天系統的擴展，現在大家所說的 Big5 實際應該都是指這個擴展集。Windows 的繁體中文 encoding 是 codepage 950，是兼容 Big5 的（也許就是倚天的擴展 Big5）。（以上說的要有什麽錯，還望臺灣的諸位指正。）

[swallowman]

既然你有興趣，我就再多說幾句。

所謂 encoding，就是建立各個正整數序列和字符圖形（glyph）之間的一一對應關係，這樣計算機在存儲文字的時候，只要存儲一些整數就行了。
..............

恕刪~
謝謝狼兄說明,看了之後果然又對GB文化又多了一層認識.BIG5碼也是不讓須眉:
http://freebsd.sinica.edu.tw/phpBB2/viewtopic.php?t=583

看來都差不多,utf8應該是目前較有共識的編碼^^"

[高原之狼]

感謝 swallowman 兄提供的鏈接，看了以後發現臺灣在中文支持方面實在是做了很多工作啊。

不知這篇文章的作者謝東翰現在在做什麽工作呢？

[swallowman]

不知這篇文章的作者謝東翰現在在做什麽工作呢？

這個...可能moto大(台北)較清楚@@,
小弟覺得目前中文資訊較集中的站應該是:
http://freebsd.sinica.edu.tw/,
而cle的maillist就很少看了
中文真是一個痛處,更痛的是oreilly的書(CJKV Information Processing)還是出自外國人之手~,咱們用中文的人(含日文)只能搞翻譯><.[/url]