• <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
            <2013年1月>
            303112345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

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

            常用鏈接

            留言簿(21)

            隨筆分類

            隨筆檔案

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

            我的個(gè)人網(wǎng)頁

            我的小游戲

            資源下載

            搜索

            •  

            積分與排名

            • 積分 - 493132
            • 排名 - 39

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            <本文PDF文檔下載>

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

            從字符到整數(shù)

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

            本地化策略集(locale)

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

            C/C++的編譯策略

            “本地化策略集”是個(gè)很好的概念,可惜在字符和字符串這個(gè)層面上,C/C++并不使用(C++的locale通常只是影響流(stream)),C/C++使用更直接簡單的策略:硬編碼。
            簡單的說,字符(串)在程序文件(可執(zhí)行文件,非源文件)中的表示,與在程序執(zhí)行中在內(nèi)存中的表示一致。考慮兩種情況:
            A、char c = 0x61;
            B、char c = 'a';
            情況A下,編譯器可以直接認(rèn)識(shí)作為整數(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
            一般情況下,編譯器會(huì)忠實(shí)于源文件的編碼為s賦值,例外的情況比如VC會(huì)自作聰明的把大部分其他類型編碼的字符串轉(zhuǎn)換成GB2312(除了像UTF-8 without signature這樣的幸存者)。
            程序在執(zhí)行的時(shí)候,s也就保持是這樣的編碼,不會(huì)再做其他的轉(zhuǎn)換。

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

            FeedBack:
            # re: 徹底解密C++寬字符:1、從char到wchar_t 2010-06-26 14:44 唐風(fēng)
            哈哈,好,這個(gè)系列會(huì)很有價(jià)值的樓主!  回復(fù)  更多評(píng)論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t[未登錄] 2011-04-15 21:29 hzh
            # re: 徹底解密C++寬字符:1、從char到wchar_t 2011-06-20 17:56 路人
            @hzh
            哥,0x61 確實(shí)等于 97 的說  回復(fù)  更多評(píng)論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t[未登錄] 2012-11-09 21:53 afei
            寫的真好,樓主很強(qiáng)。  回復(fù)  更多評(píng)論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t[未登錄] 2013-01-17 23:20 smile
            "在win32中,wchar_t的編碼是UCS-2BE"
            樓主仔細(xì)測(cè)試了嗎,應(yīng)該是ucs-2le才對(duì)吧?  回復(fù)  更多評(píng)論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t 2013-12-19 21:43 ligand
            在win32中,wchar_t的編碼是UCS-2LE;在Linux上,是UCS-4LE  回復(fù)  更多評(píng)論
              
            久久福利资源国产精品999| 久久久久亚洲av无码专区导航| 精品久久久久久亚洲精品| 精品免费久久久久久久| 精品免费久久久久国产一区| 狠狠人妻久久久久久综合蜜桃| 亚洲精品第一综合99久久| 国产午夜免费高清久久影院| 青青青国产精品国产精品久久久久| 久久久精品久久久久久| 久久久无码一区二区三区| 久久精品国产一区二区 | 91秦先生久久久久久久| 久久国产香蕉视频| 欧美午夜精品久久久久免费视 | 国产情侣久久久久aⅴ免费| 国产伊人久久| 狠狠久久亚洲欧美专区| 久久久无码精品亚洲日韩京东传媒 | 久久精品国产免费| 亚洲中文字幕久久精品无码APP| 国产成人久久777777| 国内精品久久久久影院一蜜桃| 欧美日韩精品久久久久| 伊人色综合久久天天| 99久久精品影院老鸭窝| 精品多毛少妇人妻AV免费久久 | 99久久这里只精品国产免费| 久久精品无码一区二区日韩AV| 精品国产一区二区三区久久| 欧美亚洲色综久久精品国产| 中文精品久久久久人妻不卡| 思思久久好好热精品国产| 蜜臀久久99精品久久久久久| 久久无码一区二区三区少妇 | 久久精品人人做人人爽电影蜜月| 久久经典免费视频| 久久婷婷五月综合国产尤物app | 精品国产日韩久久亚洲| 久久久久99这里有精品10 | 国产成人久久激情91|