• <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運(yùn)行庫里,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的時候,又強(qiáng)制轉(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 飄雪 閱讀(4663) 評論(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   管理


            国产激情久久久久影院老熟女| 久久影院亚洲一区| 久久久久久久人妻无码中文字幕爆| 欧美喷潮久久久XXXXx| …久久精品99久久香蕉国产 | 国产精品久久久久免费a∨| 久久久亚洲裙底偷窥综合| www.久久热.com| 久久亚洲天堂| 国产精品久久久久久影院| 香蕉99久久国产综合精品宅男自 | 久久久国产99久久国产一| 99久久综合狠狠综合久久止| 狠狠久久亚洲欧美专区| 国产精品久久久久蜜芽| 国产精品成人99久久久久91gav| 欧美日韩久久中文字幕| 国产精品va久久久久久久| 久久精品中文无码资源站| 久久综合亚洲色HEZYO国产| 丁香狠狠色婷婷久久综合| 综合久久一区二区三区| 国产一区二区精品久久| 久久九九兔免费精品6| 香港aa三级久久三级老师2021国产三级精品三级在 | 久久无码专区国产精品发布 | 久久综合久久综合九色| 伊人久久综合精品无码AV专区| 久久免费视频6| 亚洲国产精品无码久久青草| 中文字幕久久欲求不满| 99久久免费国产特黄| 久久久噜噜噜久久熟女AA片| 久久婷婷五月综合成人D啪| 一本一道久久a久久精品综合| 美女久久久久久| 亚洲精品97久久中文字幕无码| 久久精品免费网站网| 久久AAAA片一区二区| 久久夜色精品国产www| 久久亚洲视频|