由一次詭異的codeblocks中文亂碼想到的漢字編碼知識

由一次詭異的codeblocks中文亂碼想到的漢字編碼知識一,問題復(fù)現(xiàn)1用codeblocks新建一個1.c，里面寫入：#include"stdio.h”main（）{printf（-中文"）；}保存，編譯，可以正常顯示。關(guān)閉codeblocks，復(fù)制了一份1.c，改叫"1-對照.c”，再打開1.c，發(fā)現(xiàn)"中文”兩個字變成了亂碼（是四個字母，好像是俄文）2用codeblocks新建一個2.c，里面寫入：#include"stdio.h”main（）{printf（"為啥這樣的中文可以"）;}保存，編譯，可以正常顯示。關(guān)閉codeblocks，再打開2.c，發(fā)現(xiàn)一切正常。二思考

百思不得其解，遂查閱了大量關(guān)于漢字編碼的文章。用winhex查看"1.c”（用codeblocks再次打開過）和"1-對照.c”（沒有用codeblocks再次打開過），發(fā)現(xiàn)兩個文件內(nèi)碼都一樣，而且中文兩個字的內(nèi)碼沒有錯，就是6日1＜對應(yīng)的編碼"D6D0CEC4"。于是我吐了。一"吐定思痛"，我懷疑是codeblocks的自動檢測編碼機制工作失誤，查看了codeblocks的狀態(tài)欄，果然是將編碼錯認成了KOI8-R。為什么2.c沒有錯認呢？可能是因為那幾個字的機內(nèi)碼已經(jīng)不在KOI8-R的范圍內(nèi)了，所以codeblocks正確的認成了GBK。實際上，因為默認是Windows-936，所以剛新建文件時，editor界面顯示正常，保存時，也是用的ANSI編碼（在簡體中文win7上就是Windows-936就是GBK）個人認為，源碼是什么編碼，gcc就認為是什么編碼，生成的exe也就是什么編碼，而不是像網(wǎng)上說的"如果源文件的字符集是GBk，那么就必須指定-finput-charset=GBK，如果不指定一律當做UTF-8處理。除非你源文件真的是UTF-8，否則就會出現(xiàn)轉(zhuǎn)換錯誤?！?"并且生成的exe默認是UTF-8的”；否則，我的codeblocksGCC編譯器不加-fexec-charset=GBK（還有說讓加-finput-charset=UTF-8的）按說就不應(yīng)該生成能正常顯示中文的程序了啊。當然，小弟學(xué)識太淺，如果有錯，還請高手指正。三、漢字編碼的相關(guān)知識原版資料就不摘了，網(wǎng)上一搜一大把，這里只說說自己的理解。任何符號都要編碼才能在計算機中顯示，英文，中文等都不例外。因為西文數(shù)量少，編碼簡單，涉及到的不多，所以設(shè)計到的概念較少（至少從網(wǎng)上的資料看，西文的編碼沒有這么多概念）。然而到了漢字這，情況就不一樣了。人們?yōu)榱司幋a有條理、方便查找，發(fā)明了輸入碼、交換碼、機內(nèi)碼的概念。輸入碼簡單理解就是用輸入法的時候打的符號，不同輸入方法，輸入碼就不同。交換碼是為了方便交換而設(shè)定的編碼，就是對符號的第一次編號。對于漢字，我們目前常提到的交換碼是"區(qū)位碼”、"國標碼”，來自于GB2312-80標準。以下所說的"區(qū)位碼”特指漢字的區(qū)位碼，筆者雖然沒見過別的文字的區(qū)位碼，但是想來區(qū)位碼這個概念也能用在其他文字上。機內(nèi)碼就是計算機儲存空間中存儲的二進制形式的編碼，人們常寫成16進制方便閱讀。//========================================查表得到的區(qū)位碼一般是十進制數(shù)，由區(qū)碼、位碼構(gòu)成，是兩個兩位數(shù)，而不是一個四位數(shù)，轉(zhuǎn)換成國標碼的時候要先轉(zhuǎn)成十六進制區(qū)位碼。這里要注意，十進制區(qū)位碼轉(zhuǎn)成十六進制區(qū)位碼的時候，要分成高位兩位和低位兩位分開轉(zhuǎn)換，而不是把那個四個數(shù)當成一個十進制數(shù)整個轉(zhuǎn)成十六進制數(shù)??！例如："文”，區(qū)位碼4636，要先分成高位兩位46和低位兩位36，然后把他們分別轉(zhuǎn)換成十六進制數(shù)，即2E24（H）。然后就可以加0x2020得到國標碼4E44（H），再加0x8080得到機內(nèi)碼CEC4（H）了。我一開始總是把4636直接轉(zhuǎn)成121C（H），再+0x2020+0x8080，然后就悲劇了。//=========================================下面有些自己的一些推論，可能會有錯，拋磚引玉了理解了交換碼、機內(nèi)碼，個人感覺其實交換碼、機內(nèi)碼這些概念其實也是適用于英文等西文的，只不過西文的交換碼、機內(nèi)碼是一樣的罷了。證據(jù):比如說ASCII=AmericanStandardCodeimformationInterchange，從名字就能看出這是交換碼，并且大家都知道，英文存在內(nèi)存以及硬盤里的時候（機內(nèi)碼），也是ASCII碼的形式。Unicode編碼系統(tǒng)中"代碼點”這個概念就是"交換碼”。UCS是"人類符號”到"代碼點”的映射關(guān)系，UTF是"代碼點”到"機內(nèi)碼”的映射關(guān)系。同理，在GB2312中由區(qū)位表是"漢字”到"區(qū)位碼”的映射關(guān)系，”十六進制區(qū)位碼+A0A0(H)=機內(nèi)碼”是"區(qū)位碼”到"機內(nèi)碼”的映射關(guān)系。GBK是對GB2312的內(nèi)碼進行了拓展(GBK的K就是這個"擴展”的意思)，并且只保留高位字節(jié)的第八位置一，不再強制低位字節(jié)的第八位置一，這樣才擴展了編碼空間。區(qū)位碼是GB2312特有的。GBK是對GB2312內(nèi)碼直接擴展的，而不是對其區(qū)位碼進行擴展的，所以GBK新增加的漢字是沒有區(qū)位碼的。也就是說，對于GBK相對于GB2312新增加的漢字，他們是直接由"人類符號”映射到"機內(nèi)碼”的。證據(jù)：我找了一張UNICODE，GBK，GB2312對照表，發(fā)現(xiàn)里面的區(qū)位碼一欄很多空白。這個不是什么推論，是猜測：所謂的GBK向上兼容UNICODE，只是說GBK里面的漢字，unicode里面都有，但是沒有簡單的對應(yīng)關(guān)系。因為GBK跟unicode里面漢字的順序是不一樣的。四、解決方案如果只是想解決最開始那