• <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年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

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

            常用鏈接

            留言簿(21)

            隨筆分類

            隨筆檔案

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

            我的個人網(wǎng)頁

            我的小游戲

            資源下載

            搜索

            •  

            積分與排名

            • 積分 - 492114
            • 排名 - 38

            最新評論

            閱讀排行榜

            評論排行榜

            <本文PDF文檔下載>

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

            從字符到整數(shù)

            char是一種整數(shù)類型,這句話的含義是,char所能表示的字符在C/C++中都是整數(shù)類型。好,接下來,很多文章就會舉出一個典型例子,比如,'a'的數(shù)值就是0x61。這種說法對嗎?如果你細心的讀過K&R和BS對于C和C++描述的原著,你就會馬上反駁道,0x61只是'a'的ASCII值,并沒有任何規(guī)定C/C++的char值必須對應(yīng)ASCII。C/C++甚至沒有規(guī)定char占幾位,只是規(guī)定了sizeof(char)等于1。
            當然,目前大部分情況下,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下,編譯器可以直接認識作為整數(shù)的c,但是在情況B下,編譯器必須將'a'翻譯成整數(shù)。編譯器的策略也很簡單,就是直接讀取字符(串)在源文件中的編碼數(shù)值。比如:
            const char* s = "中文abc";
            這段字符串在GB2312(Windows 936),也就是我們的windows默認中文系統(tǒng)源文件中的編碼為:
            0xD6   0xD0   0xCE 0xC4 0x61 0x62 0x63
            在UTF-8,也就是Linux默認系統(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同樣沒有標準限定,標準只是要求一個wchar_t可以表示任何系統(tǒng)所能認識的字符,在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)才認;而MinGW卻用gcc編寫,所以自己只認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"
            樓主仔細測試了嗎,應(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ù)  更多評論
              
            久久精品草草草| 国产午夜精品理论片久久 | 亚洲国产精品无码久久SM| 久久精品国产免费观看三人同眠| 噜噜噜色噜噜噜久久| 狠狠色婷婷久久一区二区| 久久er99热精品一区二区| 久久久久亚洲av毛片大| 77777亚洲午夜久久多喷| 久久精品成人免费网站| 久久久久久久久久久精品尤物| 99久久国产热无码精品免费| 热综合一本伊人久久精品| 精品久久久久久久无码| 日韩久久久久中文字幕人妻| 99国产欧美精品久久久蜜芽| 久久久久亚洲AV片无码下载蜜桃| 国产午夜久久影院| 久久久久亚洲精品无码蜜桃| 欧美粉嫩小泬久久久久久久| 一级做a爰片久久毛片16| 77777亚洲午夜久久多人| 热综合一本伊人久久精品| 99久久精品国产综合一区| 久久99精品久久久久子伦| 7777精品久久久大香线蕉| 区亚洲欧美一级久久精品亚洲精品成人网久久久久 | 四虎国产精品免费久久5151| 久久综合亚洲鲁鲁五月天| 久久综合九色欧美综合狠狠| 91精品免费久久久久久久久| 久久精品国产亚洲AV无码偷窥| 久久精品国产乱子伦| 久久亚洲精品国产亚洲老地址| 久久这里只有精品首页| 久久国产成人精品麻豆| 久久久无码一区二区三区| 久久精品无码专区免费青青| 漂亮人妻被黑人久久精品| 亚洲AV日韩精品久久久久| 亚洲AV无码久久精品蜜桃|