用cl编译两个小程序如下：

程序1:

程序2:

发现程序2编译之后所得的.exe文件比程序1的要大得多。当下甚为不解，于是手工编译了一下，并使用了/FAs编译选项来查看了一下其各自的.asm，发现在程序1.asm中ar的定义如下：


而在程序2.asm中，ar被定义为：


区别很明显，一个位于.bss段，而另一个位于.data段，两者的区别在于：全局的未初始化变量存在于.bss段中，具体体现为一个占位符；全局的已初始化变量存于.data段中；而函数内的自动变量都在栈上分配空间。.bss是不占用.exe文件空间的，其内容由操作系统初始化（清零）；而.data却需要占用，其内容由程序初始化，因此造成了上述情况。

相关参考： http://www.linuxsir.org/bbs/showthread.php?t=204807 1. GBK是GB2312与BIG5的超集，结构基本相同
2. GB13000/Unicode是等同采用ISO 10646/Unicode的国家标准
3. GB13000/Unicode又是GBK的超集
4. UTF-8/UTF-16只是Unicode的编码变种，并不是字符集合的变种
5. GB18030是目前最大的汉字字符集合，比GB13000都要大
6. GB18030不是简单的GBK超集，其体系结构完全不一样
7. GB18030从未实现并真正应用过......
8. GBK是国家规范，GB2312/GB18030/GB13000则为国家标准
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. 程序员趣味读物：谈谈Unicode编码
2. 维基百科全书 - GBK
3. 用信息化手段进行语言文字研究 问题表现：小企鹅输入法的编码配置导致Console中的Man出现<A1><AF>的乱码，比如，man setup/man tcpdump

解决方案：禁止Console使用中文编码，在.bash_profile或.bashrc中将CHARSET和LANG均修改为en_US.utf8；同时记得在SecureCRT中将Session的编码改为UTF-8即可。

遗留问题：上述方法带来了一些新问题，首先，cat一个GB2312编码的文件，发现SecureCRT中是乱码，这是因为GB2312被SecureCRT解释成了UTF-8，翻了翻man，发现一个自带的编码转换工具iconv不错，于是将它作为一个alias写在.bashrc里面了："alias ic='iconv -f GB2312 -t UTF-8'"，这样，只需"cat filename | ic"可正确输出GB2312编码的文件。其次，还存在着一个问题，那便是vim，vim一个GB2312编码的文件，也发现了乱码，仔细思考了一下，发现只需要把/etc/vimrc中vim打开文件的默认编码改成GB2312即可，即在其最后添加上"set fileencoding=gbk"、"set fileencodings=utf-8,gbk,utf-16,big5"即可。

至此，问题全部解决。