• <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>

            飄雪

            C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              31 Posts :: 0 Stories :: 60 Comments :: 0 Trackbacks
                vc 2005 sp1下isspace函數(shù)的debug版本對中文處理有問題

                今天碰到一個(gè)怪問題,從別人那兒拿來的一段代碼先在gcc下過了,又移植到vc下編譯,結(jié)果debug時(shí)老是有assert錯(cuò)誤。看了一下代碼,錯(cuò)誤發(fā)生在一個(gè)trim函數(shù)中。trim函數(shù)接受一個(gè)char*類型的字符串參數(shù),去掉字符串前后的空格、制表符等空白字符。其中判斷是否是空白字符用的是isspace函數(shù)。按照一般的想法,char*字符串里的字符編碼無論是GBK還是utf-8,因?yàn)槎技嫒軦SCII,所以isspace函數(shù)都不應(yīng)該發(fā)生問題。但事實(shí)是只要是字符串有中文,無論是gbk還是utf-8編碼,isspace內(nèi)都有assert錯(cuò)誤。為了便于說明,把其中的代碼抽像出來如下:

                char* lpszBuffer = (char*)"高";
                int nLen = (int)strlen(lpszBuffer);
                for( int i=0;i
                {
                    printf("0x%x %dn",lpszBuffer[i],isspace(lpszBuffer[i]) );
                }

                這段代碼在debug編譯的情況下會assert失敗。沒有辦法,只好跟蹤到c運(yùn)行庫里,isspace的實(shí)現(xiàn)如下(在"_ctype.c"文件里):

            extern __inline int (__cdecl isspace) (
                    int c
                    )
            {
                if (__locale_changed == 0)
                {
                    return __fast_ch_check(c, _SPACE);
                }
                else
                {
                    return (_isspace_l)(c, NULL);
                }
            }

                跟蹤發(fā)現(xiàn),__locale_changed的值為0,走第一個(gè)分支,調(diào)用__fast_ch_check,它其實(shí)是個(gè)宏定義,最后進(jìn)入_chvalidator函數(shù),它的實(shí)現(xiàn)代碼如下:

            extern "C" int __cdecl _chvalidator(
                    int c,
                    int mask
                    )
            {
                    _ASSERTE((unsigned)(c + 1) <= 256);
                    return _chvalidator_l(NULL, c, mask);
            }

                錯(cuò)誤就發(fā)生在這個(gè)函數(shù)的第一行“ _ASSERTE((unsigned)(c + 1) <= 256);”。
                
                代碼看到這里,錯(cuò)誤的原因基本也就出來了。“高”的GBK編碼是“b8 df”,調(diào)用isspace函數(shù)是逐個(gè)字節(jié)判斷,但是isspace和_chvalidator接受的參數(shù)都是int,這樣就會產(chǎn)生一個(gè)char到int的轉(zhuǎn)型,在vc下,char默認(rèn)是"signed char",這樣char“b8”轉(zhuǎn)型到int后,會變成一個(gè)負(fù)數(shù),然后在assert的時(shí)候,又強(qiáng)制轉(zhuǎn)型為unsigned,它又變成了一個(gè)非常巨大的正數(shù),自然assert就失敗了。
                為什么在gcc下沒有錯(cuò)誤?gcc下的isspace函數(shù)實(shí)現(xiàn)我倒沒看,不過我的gcc中的char默認(rèn)就是“unsighed char”,所以即使isspace的實(shí)現(xiàn)跟上面的一樣,也不會產(chǎn)生問題。
                另:在win32 release和wince下,也不會有上述問題,因?yàn)檫@幾種環(huán)境下isspace的實(shí)現(xiàn)跟上面不一樣。
                
                問題找到了,剩下的就看怎么解決了。
                首先用用一個(gè)最簡單的方法,既然問題發(fā)生在轉(zhuǎn)型上,只要把char的默認(rèn)類型改為unsigned char就可以了,vc也提供了這個(gè)選項(xiàng)。但這有幾個(gè)問題,一是別人用我的代碼的時(shí)候還得修改編譯選項(xiàng),二是修改了整個(gè)工程的編譯選項(xiàng)可能會對其它代碼產(chǎn)生不好的影響。
                既然上面的方法不大好操作,那就再想想別的方法。經(jīng)觀察發(fā)現(xiàn),isspace函數(shù)中靠__locale_changed變量控制流程走向,搜索整個(gè)crt的源代碼,發(fā)現(xiàn)__locale_changed的值只有在setlocale函數(shù)中發(fā)生了改變。最后,我把代碼修改成如下:

                #if defined(WIN32) && defined(_DEBUG)
                char* locale = setlocale( LC_ALL, ".OCP" );
                #endif
                char* lpszBuffer = (char*)"高";
                int nLen = (int)strlen(lpszBuffer);
                for( int i=0;i
                {
                    printf("0x%x %dn",lpszBuffer[i],isspace(lpszBuffer[i]) );
                }
               
                這樣在debug版本上就不會再有問題,但是可能其中仍有隱患,等到具體碰到的時(shí)候再說吧。先把目前的工作繼續(xù)下去。

            posted on 2009-03-12 14:04 飄雪 閱讀(4657) 評論(5)  編輯 收藏 引用

            Feedback

            # re: vc 2005 sp1下isspace函數(shù)對中文處理有問題[未登錄] 2009-03-13 17:39 foxriver
            自己寫一個(gè)isspace啊,十幾行的事情,我一直不太相信vc crt string部分。  回復(fù)  更多評論
              

            # re: vc 2005 sp1下isspace函數(shù)對中文處理有問題 2009-03-13 17:54 飄雪
            @foxriver
            自己寫一個(gè)isspace啊,十幾行的事情,我一直不太相信vc crt string部分

            最終他給我的是一個(gè)靜態(tài)庫,在靜態(tài)庫里調(diào)用的isspace,沒法自己寫呀,只能繞過去  回復(fù)  更多評論
              

            # re: vc 2005 sp1下isspace函數(shù)對中文處理有問題 2009-04-05 21:13 Dancefire
            如果我沒有理解錯(cuò),你試圖用locale為ASCII的isspace來判斷GBK編碼的空格,對么?如果我理解正確的話,那么這不是VC的問題,而是使用上的問題。

            對于C++而言,應(yīng)該使用isspace(ch, loc); 這個(gè)版本,loc是類型為std::locale的變量,如果你想判斷GBK的空格,那么讓loc是GBK的locale,然后這個(gè)函數(shù)就正常了。

            你現(xiàn)在使用的是C的isspace(ch)函數(shù),這個(gè)函數(shù)使用的是默認(rèn)的全局locale,你把這個(gè)全局的設(shè)為GBK,也應(yīng)該可以解決這個(gè)問題。總之調(diào)用locale為默認(rèn)的ASCII的locale的isspace去判斷編碼為GBK的字串是否是空格,邏輯上不對。  回復(fù)  更多評論
              

            # re: vc 2005 sp1下isspace函數(shù)對中文處理有問題 2010-10-27 10:07 leeeryan
            @Dancefire
            同意樓上,分析的很在理  回復(fù)  更多評論
              

            # re: vc 2005 sp1下isspace函數(shù)對中文處理有問題[未登錄] 2012-12-17 13:59 jack
            我也遇到這個(gè)問題,輸出“包”字符(0xfc)時(shí),用isspace檢查返回值為0x08,所以輸出亂碼。后來我使用iswspace就好了,程序中應(yīng)該盡可能的使用寬字符函數(shù)  回復(fù)  更多評論
              


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            成人妇女免费播放久久久| 欧美伊人久久大香线蕉综合| 欧美丰满熟妇BBB久久久| 久久精品国产99久久久| 综合久久久久久中文字幕亚洲国产国产综合一区首 | 欧美国产成人久久精品| 欧美亚洲国产精品久久高清| 久久久国产乱子伦精品作者| 狠狠精品干练久久久无码中文字幕 | 久久久久亚洲AV无码专区体验| 久久综合丝袜日本网| 亚洲人成无码网站久久99热国产| 婷婷伊人久久大香线蕉AV | 久久香蕉国产线看观看99| 思思久久99热免费精品6| 国产精品毛片久久久久久久| 77777亚洲午夜久久多人| 亚洲国产日韩综合久久精品| 久久青草国产手机看片福利盒子| 婷婷国产天堂久久综合五月| 国产精品美女久久久| 无码国内精品久久人妻| 亚洲精品久久久www| 久久99精品久久久久久噜噜| 久久国产精品99精品国产987| 国产成年无码久久久久毛片| 一本色综合网久久| 久久天天躁狠狠躁夜夜2020一 | 久久无码一区二区三区少妇| 精品久久久久久久| 99久久久国产精品免费无卡顿| 精品国产青草久久久久福利| 欧美国产成人久久精品| 久久婷婷五月综合色99啪ak| 午夜肉伦伦影院久久精品免费看国产一区二区三区 | 精品久久久久久久无码 | 三上悠亚久久精品| 亚洲av伊人久久综合密臀性色| 一本久久a久久精品vr综合| 久久人妻无码中文字幕| 亚洲精品乱码久久久久久久久久久久|