• <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
            <2010年6月>
            303112345
            6789101112
            13141516171819
            20212223242526
            27282930123
            45678910

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

            常用鏈接

            留言簿(21)

            隨筆分類(lèi)

            隨筆檔案

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

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

            我的小游戲

            資源下載

            搜索

            •  

            積分與排名

            • 積分 - 492222
            • 排名 - 38

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            <本文PDF文檔下載>

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

            從字符到整數(shù)

            char是一種整數(shù)類(lèi)型,這句話(huà)的含義是,char所能表示的字符在C/C++中都是整數(shù)類(lèi)型。好,接下來(lái),很多文章就會(huì)舉出一個(gè)典型例子,比如,'a'的數(shù)值就是0x61。這種說(shuō)法對(duì)嗎?如果你細(xì)心的讀過(guò)K&R和BS對(duì)于C和C++描述的原著,你就會(huì)馬上反駁道,0x61只是'a'的ASCII值,并沒(méi)有任何規(guī)定C/C++的char值必須對(duì)應(yīng)ASCII。C/C++甚至沒(méi)有規(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)起來(lái)”,類(lèi)似這樣的規(guī)定,是特定系統(tǒng)和特定編譯器制定的,C/C++中有個(gè)特定的名詞來(lái)描述這種規(guī)定的集合:本地化策略集(locale。也有翻譯成“現(xiàn)場(chǎng)”)。而翻譯——也就是代碼轉(zhuǎn)換(codecvt)只是這個(gè)集合中的一個(gè),C++中定義為策略(facet。也有翻譯為“刻面”)

            C/C++的編譯策略

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

            寬字符 wchar_t
            正如char沒(méi)有規(guī)定大小,wchar_t同樣沒(méi)有標(biāo)準(zhǔn)限定,標(biāo)準(zhǔn)只是要求一個(gè)wchar_t可以表示任何系統(tǒng)所能認(rèn)識(shí)的字符,在win32中,wchar_t為16位;Linux中是32位。wchar_t同樣沒(méi)有規(guī)定編碼,因?yàn)閁nicode的概念我們后面才解釋?zhuān)赃@里只是提一下,在win32中,wchar_t的編碼是UCS-2BE;而Linux中是UTF-32BE(等價(jià)于UCS-4BE),不過(guò)簡(jiǎn)單的說(shuō),在16位以?xún)?nèi),一個(gè)字符的這3種編碼值是一樣的。因此:
            const wchar_t* ws = L"中文abc";
            的編碼分別為:
            0x4E2D   0x6587    0x0061   0x0062   0x0063                                                //win32,16位
            0x00004E2D   0x00006587    0x00000061   0x00000062   0x00000063        //Linux,32位
            大寫(xiě)的L是告訴編譯器:這是寬字符串。所以,這時(shí)候是需要編譯器根據(jù)locale來(lái)進(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編寫(xiě),所以自己只認(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[未登錄](méi) 2011-04-15 21:29 hzh
            # re: 徹底解密C++寬字符:1、從char到wchar_t 2011-06-20 17:56 路人
            @hzh
            哥,0x61 確實(shí)等于 97 的說(shuō)  回復(fù)  更多評(píng)論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t[未登錄](méi) 2012-11-09 21:53 afei
            寫(xiě)的真好,樓主很強(qiáng)。  回復(fù)  更多評(píng)論
              
            # re: 徹底解密C++寬字符:1、從char到wchar_t[未登錄](méi) 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)論
              
            品成人欧美大片久久国产欧美...| 久久久久se色偷偷亚洲精品av| 久久精品国产久精国产果冻传媒| 国产成人精品久久二区二区| 中文字幕乱码人妻无码久久| 波多野结衣AV无码久久一区| 久久久久久精品免费看SSS| 久久久久久久免费视频| 亚洲午夜福利精品久久| 亚洲午夜无码AV毛片久久| 波多野结衣久久精品| 中文国产成人精品久久不卡 | 久久久久人妻精品一区三寸蜜桃 | 久久亚洲sm情趣捆绑调教| 亚洲国产另类久久久精品黑人| 亚洲中文字幕无码久久2020| 久久这里只有精品18| 久久青青草原精品影院| 国内精品久久久久久久涩爱| 久久夜色精品国产噜噜亚洲a| 老色鬼久久亚洲AV综合| 丰满少妇人妻久久久久久4| 欧美精品丝袜久久久中文字幕 | 久久水蜜桃亚洲av无码精品麻豆| 精品久久久久久久| 久久精品无码免费不卡| 亚洲乱码中文字幕久久孕妇黑人| 国产一久久香蕉国产线看观看 | 国产精品内射久久久久欢欢| 一本久久精品一区二区| 色婷婷综合久久久久中文一区二区| 久久久久久久尹人综合网亚洲 | 国产精品无码久久综合网| 一本色道久久88综合日韩精品 | 久久精品aⅴ无码中文字字幕不卡| 九九久久精品国产| 久久精品99久久香蕉国产色戒| 久久综合成人网| 热久久国产精品| 久久香蕉超碰97国产精品| 久久综合色老色|