随笔 - 85  文章 - 47  trackbacks - 0

常用链接

随笔分类

随笔档案

搜索

  •  

最新评论

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

程序1:
int ar[30000];
void main()
{
    ......
}

程序2:
int ar[300000= {123456 };
void main()
{
    ......
}

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

_BSS SEGMENT
     ?ar@@3PAHA DD 0493e0H DUP (?)    ; ar
_BSS ENDS

而在程序2.asm中,ar被定义为:

_DATA SEGMENT
     ?ar@@3PAHA DD 01H     ; ar
                DD 02H
                DD 03H
                ORG $+1199988
_DATA ENDS

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

相关参考: http://www.linuxsir.org/bbs/showthread.php?t=204807
posted @ 2007-03-13 00:09 w2001 阅读(4562) | 评论 (0)编辑 收藏
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. 用信息化手段进行语言文字研究
posted @ 2007-03-13 00:05 w2001 阅读(397) | 评论 (0)编辑 收藏
问题表现:小企鹅输入法的编码配置导致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"即可。

至此,问题全部解决。
posted @ 2007-03-12 15:50 w2001 阅读(887) | 评论 (0)编辑 收藏
仅列出标题
共9页: 1 2 3 4 5 6 7 8 9