結論:
1、source insight 3.50.63 不能顯示編碼為utf8的原始檔中的中文字元。ansi編碼的檔案中的中文字元能正常顯示。(最新的3.50.64版本也有同樣問題)
2、windows下無論源**檔案是utf8還是ansi,對編譯結果無影響。
3、linux下源**檔案是utf8的中文顯示正常,ansi的中文亂碼。
正文:(發現問題的經過)
今天偶然發現,在si中,中文字串顯示為亂碼。
但如果用notepad開啟該檔案,則不是亂碼。從notepad開啟的介面中複製到si中,也不是亂碼。
據此,可以推測,該檔案儲存為某種編碼,使得si不能正確顯示。
用ue開啟該檔案,另存乙個為ansi格式的檔案ktvmainscreen1.cpp:
然後再在si中開啟,中文顯示正常了。
然後用bc開啟,發現:原來的si中亂碼的檔案是utf-8格式的。
把左邊選擇為ansi才能顯示正常:
能否用另存的檔案來代替原來的檔案進行編譯呢?那樣會不會在軟體**現亂碼?
後來,用下面**測試中文顯示,有一種寫法中文顯示正常。
//qpushbutton hello(qobject::trutf8("世界您好!")); //win7下執行時中文亂碼
//qpushbutton hello(qobject::tr("世界您好!"));//win7下執行時中文亂碼
qpushbutton hello(qstring::fromlocal8bit("世界您好!"));//win7下中文顯示正常
hello.resize(100, 30);
但二進位制比較該原始檔時,可以發現utf8比ansi每個漢字多乙個位元組。
由此可知,windows上,源**檔案為utf8還是ansi編碼,編譯後都不會有亂碼。
然後在linux上也把兩種檔案都編譯一次,發現utf8的檔案,中文正常;ansi的檔案,中文亂碼。
原始檔的編碼會對編譯結果有影響
結論 1 source insight 3.50.63 不能顯示編碼為utf8的原始檔中的中文字元。ansi編碼的檔案中的中文字元能正常顯示。最新的3.50.64版本也有同樣問題 2 windows下無論源 檔案是utf8還是ansi,對編譯結果無影響。3 linux下源 檔案是utf8的中文顯示正...
編譯器對原始檔編碼的處理
漢字 gbk編碼 ba ba d7 d6 utf 8編碼 e6 b1 89,e5 ad 97 utf 16be編碼 6c 49,5b 57 兩種常用編譯器gcc,cl中對unicode字面值的實現 gcc中跟編碼方式轉換有關的三個編譯選項 有了以上鋪墊,下面兩條語句的意義就很清楚了 cpp view...
Python原始檔的字元編碼
預設情況下,python 原始碼檔案以 utf 8 編碼方式處理。在這種編碼方式中,世界上大多數語言的字元都可以同時用於字串字面值 變數或函式名稱以及注釋中 儘管標準庫中只用常規的 ascii 字元作為變數或函式名,而且任何可移植的 都應該遵守此約定。要正確顯示這些字元,你的編輯器必須能識別 utf...