1、以utf-8格式開啟原始碼檔案，並將utf-8格式作為預設的編碼模式。
情況一：原始檔的格式為utf-8(str="中文")
codeblocks的開啟格式、儲存格式、**解析格式、內碼編碼格式、與設定一致，解析輸出不能看到準確的漢子，這取決作業系統，因為國內windows作業系統cmd的輸出是gbk,所以會有亂碼，但是可以將編碼的hex列印出來，就可以看到其內碼格式為utf-8。
**解析：即編輯器對c/c++這些語言的解析。
情況二：原始檔不是utf-8
code blocks嘗試以utf-8去開啟時，發現解析不了，那麼就會以另一種格式去解析，
(中文解析格式替換出現在任何地方，不僅僅是注釋，str=中文的話，也會出錯)
此時codeblocks的開啟格式、儲存格式、**解析格式、內碼編碼格式等不可預料，所以不能允許出現此類情況。
解決方式：
1、edit-file_reload,重新reload定義該檔案的編碼格式，將原先解析錯誤的字元刪除，重新輸入，並儲存。
舉例：如果原始檔編碼格式為asni且包含有中文，codeblock()設定為utf-8,沒有設定gbk)開啟後會以另一種不可預料的格式解析,此時中文就會亂碼。即使通過file_reload,重新將檔案編碼格式定位為asni也解決不了亂碼情況，（已經不可逆）。
2、使用notpad++,將檔案格式轉為utf-8，將原先解析錯誤的字元刪除，重新輸入，並儲存。
gbk與utf-8設定同樣的道理。
問題：若code blocks不指定解析內碼的編碼格式，那麼會有乙個嚴重的問題，當乙個工程中的兩個原始檔，乙個是utf8,乙個gbk,那麼在中文在內碼的儲存上1個是3個位元組，1個是兩個位元組；
utf8儲存的是utf8的內碼，gbk儲存的是gb2312的編碼。
codeblock若不指定gcc的編譯引數，其內碼的解析格式與原始檔的格式保持一致。vs編譯器內碼的解析格式與原始檔的格式無關，與作業系統一致，始終為gbk。
預設編碼模式，指的是對某一檔案進行，編輯時文字以哪種方式進行儲存，一旦編輯了檔案，改檔案就會以該編碼模式進行儲存。
若只是檢視，reload只是臨時更改了，編碼方式。若編輯則會按照設定的編碼模式更改原始檔的編碼方式。
vs//新建
預設建立新建的檔案編碼方式為gb2312,這可以從高階系統設定中檢視，預設都是第乙個就是gb2312.
此時若在vs建立了檔案，也可以通過更改高階設定，更改編碼方式，我們一般只用到utf8與gb2312
//新增現有檔案
若現有檔案為gbk,沒有問題
若檔案為utf8編碼，可能會出現亂碼，錯誤現象，將下屬打鉤即可，匯入進來的新的utf8檔案，可從高階檔案設定中看到變為了unicode,並不是之前預設的gb2312了。
若此時中文亂碼問題解決了，但是編譯時候出現下述問題，請參考以下解決方案：
//注意的是：不論vs工程中檔案本身的編碼格式是什麼，內碼都是以作業系統的gbk編碼進行儲存。
若是編寫linux下應用程式，檔案編碼方式全部都為utf8
url使用get請求含有中文編碼問題
encodeuri 把uri字串採用utf 8編碼格式轉化成escape格式的字串。不會被此方法編碼的字元 反向編碼函式 decodeuri 上面這個函式用的比較多，可以實現對get請求url引數部分含有中文等特殊字元，進行批量編碼 encodeuricomponent 把uri字串採用urf 8編...
中文編碼問題
分為兩個方向 資料傳輸方向 1 伺服器端 客戶端 伺服器端用什麼編碼，客戶端就用什麼編碼 2 客戶端 網路傳輸 伺服器端 當 客戶端是瀏覽器時 表單輸入全是英文是以iso 8859 1作為編碼，輸入有中文時則以utf 8作為編碼方式，這是瀏覽器的 內建功能。當客戶端是android時，輸入中文和英文...
中文編碼問題
專案中的所有中文都放在乙個單獨的配置檔案中，在專案的resource資源目錄下，該檔案的編碼是ascll的字符集。瀏覽器傳送表單中的資料會對其進行編碼，通過url編碼，打包資料然後傳送。處理瀏覽器的編碼問題可以用jdk自帶類庫 例 parameter 這是對於 url引數進行編碼方便記錄。其中 st...