• <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版本對中文處理有問題

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

                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運行庫里,isspace的實現(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,走第一個分支,調(diào)用__fast_ch_check,它其實是個宏定義,最后進(jìn)入_chvalidator函數(shù),它的實現(xiàn)代碼如下:

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

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

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

            Feedback

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

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

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

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

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

            你現(xiàn)在使用的是C的isspace(ch)函數(shù),這個函數(shù)使用的是默認(rèn)的全局locale,你把這個全局的設(shè)為GBK,也應(yīng)該可以解決這個問題。總之調(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
            我也遇到這個問題,輸出“包”字符(0xfc)時,用isspace檢查返回值為0x08,所以輸出亂碼。后來我使用iswspace就好了,程序中應(yīng)該盡可能的使用寬字符函數(shù)  回復(fù)  更多評論
              


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


            久久91精品国产91久久麻豆| 久久精品国产2020| 久久精品国产亚洲av瑜伽| 久久精品无码一区二区日韩AV| 久久亚洲精品无码播放| 久久综合给合久久狠狠狠97色| 精品久久久久久中文字幕| 亚洲精品无码久久久久AV麻豆| 国产精品女同久久久久电影院| 久久精品夜色噜噜亚洲A∨| 色婷婷久久综合中文久久蜜桃av| 久久av高潮av无码av喷吹| 久久人人爽人人爽人人片AV不| 精品久久久久国产免费 | 国产真实乱对白精彩久久| 国产精品亚洲综合久久| 一级做a爱片久久毛片| 久久精品国产清自在天天线| 国产成人99久久亚洲综合精品| 久久久噜噜噜www成人网| 国产精品久久久久久久人人看| 成人亚洲欧美久久久久| 久久久婷婷五月亚洲97号色| 亚洲国产精品无码久久久秋霞2| 久久久久99精品成人片三人毛片 | 亚洲va中文字幕无码久久| 久久久综合香蕉尹人综合网| 久久久久久久综合日本亚洲| 久久99国产综合精品| 欧美熟妇另类久久久久久不卡| 国产69精品久久久久观看软件 | 久久久综合九色合综国产| 99久久精品国产高清一区二区| 热re99久久精品国99热| 久久综合狠狠综合久久| 久久精品人人做人人爽97| 69久久精品无码一区二区| 久久国产色AV免费看| 久久精品国产99国产精品澳门| 99久久精品国产高清一区二区| 欧美亚洲另类久久综合|