• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 96  文章 - 255  trackbacks - 0
            <2025年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            E-mail:zbln426@163.com QQ:85132383 長期尋找對戰(zhàn)略游戲感興趣的合作伙伴。

            常用鏈接

            留言簿(21)

            隨筆分類

            隨筆檔案

            SDL相關(guān)網(wǎng)站

            我的個人網(wǎng)頁

            我的小游戲

            資源下載

            搜索

            •  

            積分與排名

            • 積分 - 494283
            • 排名 - 39

            最新評論

            閱讀排行榜

            評論排行榜

            <本文PDF文檔下載>

            “這個問題比你想象中復(fù)雜”
            (我也學(xué)下BS的風(fēng)格,雖然這句話是我自己臨時想說的。^^)

            從字符到整數(shù)

            char是一種整數(shù)類型,這句話的含義是,char所能表示的字符在C/C++中都是整數(shù)類型。好,接下來,很多文章就會舉出一個典型例子,比如,'a'的數(shù)值就是0x61。這種說法對嗎?如果你細(xì)心的讀過K&R和BS對于C和C++描述的原著,你就會馬上反駁道,0x61只是'a'的ASCII值,并沒有任何規(guī)定C/C++的char值必須對應(yīng)ASCII。C/C++甚至沒有規(guī)定char占幾位,只是規(guī)定了sizeof(char)等于1。
            當(dāng)然,目前大部分情況下,char是8位的,并且,在ASCII范圍內(nèi)的值,與ASCII對應(yīng)。

            本地化策略集(locale)

            “將'a'翻譯成0x61的整數(shù)值”,“將ASCII范圍內(nèi)的編碼與char的整數(shù)值對應(yīng)起來”,類似這樣的規(guī)定,是特定系統(tǒng)和特定編譯器制定的,C/C++中有個特定的名詞來描述這種規(guī)定的集合:本地化策略集(locale。也有翻譯成“現(xiàn)場”)。而翻譯——也就是代碼轉(zhuǎn)換(codecvt)只是這個集合中的一個,C++中定義為策略(facet。也有翻譯為“刻面”)

            C/C++的編譯策略

            “本地化策略集”是個很好的概念,可惜在字符和字符串這個層面上,C/C++并不使用(C++的locale通常只是影響流(stream)),C/C++使用更直接簡單的策略:硬編碼。
            簡單的說,字符(串)在程序文件(可執(zhí)行文件,非源文件)中的表示,與在程序執(zhí)行中在內(nèi)存中的表示一致。考慮兩種情況:
            A、char c = 0x61;
            B、char c = 'a';
            情況A下,編譯器可以直接認(rèn)識作為整數(shù)的c,但是在情況B下,編譯器必須將'a'翻譯成整數(shù)。編譯器的策略也很簡單,就是直接讀取字符(串)在源文件中的編碼數(shù)值。比如:
            const char* s = "中文abc";
            這段字符串在GB2312(Windows 936),也就是我們的windows默認(rèn)中文系統(tǒng)源文件中的編碼為:
            0xD6   0xD0   0xCE 0xC4 0x61 0x62 0x63
            在UTF-8,也就是Linux默認(rèn)系統(tǒng)源文件中的編碼為:
            0xE4   0xB8   0xAD   0xE6   0x96   0x87   0x61   0x62   0x63
            一般情況下,編譯器會忠實于源文件的編碼為s賦值,例外的情況比如VC會自作聰明的把大部分其他類型編碼的字符串轉(zhuǎn)換成GB2312(除了像UTF-8 without signature這樣的幸存者)。
            程序在執(zhí)行的時候,s也就保持是這樣的編碼,不會再做其他的轉(zhuǎn)換。

            寬字符 wchar_t
            正如char沒有規(guī)定大小,wchar_t同樣沒有標(biāo)準(zhǔn)限定,標(biāo)準(zhǔn)只是要求一個wchar_t可以表示任何系統(tǒng)所能認(rèn)識的字符,在win32中,wchar_t為16位;Linux中是32位。wchar_t同樣沒有規(guī)定編碼,因為Unicode的概念我們后面才解釋,所以這里只是提一下,在win32中,wchar_t的編碼是UCS-2BE;而Linux中是UTF-32BE(等價于UCS-4BE),不過簡單的說,在16位以內(nèi),一個字符的這3種編碼值是一樣的。因此:
            const wchar_t* ws = L"中文abc";
            的編碼分別為:
            0x4E2D   0x6587    0x0061   0x0062   0x0063                                                //win32,16位
            0x00004E2D   0x00006587    0x00000061   0x00000062   0x00000063        //Linux,32位
            大寫的L是告訴編譯器:這是寬字符串。所以,這時候是需要編譯器根據(jù)locale來進行翻譯的。
            比如,在Windows環(huán)境中,編譯器的翻譯策略是GB2312到UCS-2BE;Linux環(huán)境中的策略是UTF-8到UTF-32BE。
            這時候就要求源文件的編碼與編譯器的本地化策略集中代碼翻譯的策略一致,例如VC只能讀取GB2312的源代碼(這里還是例外,VC太自作聰明了 ,會將很多其他代碼在編譯時自動轉(zhuǎn)換成GB2312),而gcc只能讀取UTF-8的源代碼(這里就有個尷尬,MinGW運行win32下,所以只有GB2312系統(tǒng)才認(rèn);而MinGW卻用gcc編寫,所以自己只認(rèn)UTF-8,所以結(jié)果就是,MinGW的寬字符被廢掉了)。
            寬字符(串)由編譯器翻譯,還是被硬編碼進程序文件中。

            FeedBack:
            # re: 徹底解密C++寬字符:1、從char到wchar_t 2010-06-26 14:44 唐風(fēng)
            哈哈,好,這個系列會很有價值的樓主!  回復(fù)  更多評論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t[未登錄] 2011-04-15 21:29 hzh
            a=97  回復(fù)  更多評論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t 2011-06-20 17:56 路人
            @hzh
            哥,0x61 確實等于 97 的說  回復(fù)  更多評論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t[未登錄] 2012-11-09 21:53 afei
            寫的真好,樓主很強。  回復(fù)  更多評論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t[未登錄] 2013-01-17 23:20 smile
            "在win32中,wchar_t的編碼是UCS-2BE"
            樓主仔細(xì)測試了嗎,應(yīng)該是ucs-2le才對吧?  回復(fù)  更多評論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t 2013-12-19 21:43 ligand
            在win32中,wchar_t的編碼是UCS-2LE;在Linux上,是UCS-4LE  回復(fù)  更多評論
              
            午夜肉伦伦影院久久精品免费看国产一区二区三区 | 一本久久久久久久| 久久久久久久人妻无码中文字幕爆| 国产亚洲欧美成人久久片| 97精品国产91久久久久久| 久久久91人妻无码精品蜜桃HD | 日本久久中文字幕| 久久久久久久精品成人热色戒| 久久综合狠狠综合久久综合88 | 日韩亚洲欧美久久久www综合网 | 日日狠狠久久偷偷色综合免费 | 久久久久久免费视频| 久久亚洲精品人成综合网| 精品国产福利久久久| 婷婷国产天堂久久综合五月| 久久精品成人免费网站| 国产精品成人久久久| 国产精品99久久精品爆乳| 久久精品中文字幕无码绿巨人| 久久综合久久伊人| 国产亚洲精品美女久久久| 久久久午夜精品| 久久中文字幕视频、最近更新| 欧美噜噜久久久XXX| 国产福利电影一区二区三区久久老子无码午夜伦不 | 亚洲国产精品18久久久久久| 亚洲国产天堂久久综合网站 | 国产亚洲精久久久久久无码 | 亚洲伊人久久大香线蕉综合图片| 精品国产乱码久久久久久郑州公司| 久久久青草青青国产亚洲免观| 久久国产色AV免费观看| 久久99久国产麻精品66| 久久久久亚洲AV片无码下载蜜桃| 久久精品免费观看| 99久久99久久精品免费看蜜桃| 久久偷看各类wc女厕嘘嘘| 久久久久av无码免费网| 久久久WWW成人免费精品| 久久精品无码一区二区三区免费| 久久国产成人|