用cl編譯兩個小程序如下：

程序1:

程序2:

發(fā)現(xiàn)程序2編譯之后所得的.exe文件比程序1的要大得多。當(dāng)下甚為不解，于是手工編譯了一下，并使用了/FAs編譯選項(xiàng)來查看了一下其各自的.asm，發(fā)現(xiàn)在程序1.asm中ar的定義如下：


而在程序2.asm中，ar被定義為：


區(qū)別很明顯，一個位于.bss段，而另一個位于.data段，兩者的區(qū)別在于：全局的未初始化變量存在于.bss段中，具體體現(xiàn)為一個占位符；全局的已初始化變量存于.data段中；而函數(shù)內(nèi)的自動變量都在棧上分配空間。.bss是不占用.exe文件空間的，其內(nèi)容由操作系統(tǒng)初始化（清零）；而.data卻需要占用，其內(nèi)容由程序初始化，因此造成了上述情況。

相關(guān)參考： http://www.linuxsir.org/bbs/showthread.php?t=204807 1. GBK是GB2312與BIG5的超集，結(jié)構(gòu)基本相同
2. GB13000/Unicode是等同采用ISO?10646/Unicode的國家標(biāo)準(zhǔn)
3. GB13000/Unicode又是GBK的超集
4. UTF-8/UTF-16只是Unicode的編碼變種，并不是字符集合的變種
5. GB18030是目前最大的漢字字符集合，比GB13000都要大
6. GB18030不是簡單的GBK超集，其體系結(jié)構(gòu)完全不一樣
7. GB18030從未實(shí)現(xiàn)并真正應(yīng)用過......
8. GBK是國家規(guī)范，GB2312/GB18030/GB13000則為國家標(biāo)準(zhǔn)
9. ASCII、GB2312、GBK到GB18030是向下兼容的（另一說）
10. Unicode只與ASCII兼容（另一說）

GB2312<GBK<GB13000/Unicode<ISO?10646/Unicode
BIG5<GBK<GB13000/Unicode<ISO?10646/Unicode
GB13000/Unicode<GB18030
Unicode==UTF-8==UTF-16

參考：
1. 程序員趣味讀物：談?wù)刄nicode編碼
2. 維基百科全書 - GBK
3. 用信息化手段進(jìn)行語言文字研究 問題表現(xiàn)：小企鵝輸入法的編碼配置導(dǎo)致Console中的Man出現(xiàn)<A1><AF>的亂碼，比如，man setup/man tcpdump

解決方案：禁止Console使用中文編碼，在.bash_profile或.bashrc中將CHARSET和LANG均修改為en_US.utf8；同時記得在SecureCRT中將Session的編碼改為UTF-8即可。

遺留問題：上述方法帶來了一些新問題，首先，cat一個GB2312編碼的文件，發(fā)現(xiàn)SecureCRT中是亂碼，這是因?yàn)镚B2312被SecureCRT解釋成了UTF-8，翻了翻man，發(fā)現(xiàn)一個自帶的編碼轉(zhuǎn)換工具iconv不錯，于是將它作為一個alias寫在.bashrc里面了："alias ic='iconv -f GB2312 -t UTF-8'"，這樣，只需"cat filename | ic"可正確輸出GB2312編碼的文件。其次，還存在著一個問題，那便是vim，vim一個GB2312編碼的文件，也發(fā)現(xiàn)了亂碼，仔細(xì)思考了一下，發(fā)現(xiàn)只需要把/etc/vimrc中vim打開文件的默認(rèn)編碼改成GB2312即可，即在其最后添加上"set fileencoding=gbk"、"set fileencodings=utf-8,gbk,utf-16,big5"即可。

至此，問題全部解決。