用cl編譯兩個小程序如下：
程序1:
int?ar[30000];
void?main()
{
????......
} 程序2:
int?ar[300000]?=?{1,?2,?3,?4,?5,?6?};
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 閱讀(4633) |
評論 (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 閱讀(452) |
評論 (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 閱讀(966) |
評論 (0) |
編輯 收藏