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

            ACG狂人

            其實我更愛姐汁...

            封裝MySQL時解決的兩個字符集問題

            在我開始封裝MySQL C API時,真的沒有想過居然會在字符集問題上連續(xù)卡殼,折騰了一下午+一晚上,終于搞定這些問題。下面記錄一下我遇見的問題以及解決辦法,以作備忘。
            首先遇見的當然是中文亂碼問題。這個問題相對來說資料比較多,文檔寫得應該也是很清楚的,但是我沒心思看,靠猜搞定。我首先設置MySQL服務器的默認字符集為UTF8,并保證我操作的表中的列字符集也是UTF8,然后重啟MySQL服務,并嘗試用mysql_query("INSERT INTO TestTable VALUES('你好')")來寫入,結果失敗在預料之中。我猜可能可以使用類似"INSERT INTO TestTable VALUES('\0x2734\0x3432')"這樣的方式寫入中文,但這樣太丑了,也沒有實用價值,我堅決不會去用。我又嘗試使用MultiByteToWideChar去做,甚至使用了Qt的QTextCodec去轉換“你好”這兩個字,結果依然失敗。這就有些蹊蹺了,我決定調用mysql_character_set_name()看看到底有沒有正確的設置成UTF8格式,讓我意料之外的是:結果是latin1,這難道是拉丁字符集??我查看了一下API函數(shù)的相關說明,發(fā)現(xiàn)這里獲取到的是客戶端鏈接的字符集,我突然覺得,也許MySQL可以自動的在客戶端與服務器之間的字符集進行轉化!說做就做,我查到了可以用mysql_options()或者mysql_set_character_name()函數(shù)來設置客戶端鏈接字符集,但這兩個函數(shù)用的時機分別在調用mysql_real_connect()之前或之后。我將客戶端鏈接設置成gb2312字符集,這是VC中支持中文的標準字符集之一(另一個標準是UTF16,需要用wchar_t  wstring和常量字符串前的L),結果,當然是非常正確的插入中文啦,呵呵!
            正當我覺得下面的封裝肯定會順湯順水之時,在封裝基本完成的時候,我發(fā)現(xiàn)控制臺不能輸出我從MySQL取出的中文了!這太奇怪了,輸出英文就沒有問題,而中文雖然的確被準確無誤的讀入了std::string中(通過單步調試和ofstream得到確認),然而輸出到cout中卻會出錯。為什么文件流沒問題,控制臺流會出問題呢?我跟蹤了代碼,發(fā)現(xiàn)在fputc()函數(shù)中出現(xiàn)了問題。另一個奇特的地方,就是在mysql_init()函數(shù)被調用之前,cout可以正確輸出中文,但調用之后就不能輸出,iostate被賦予4值,即badbit。我求了一下google,發(fā)現(xiàn)sputc()中的一個_nolock_write()函數(shù)是msvcrtd.lib中的函數(shù),暈了,我在單步調試中也發(fā)現(xiàn)就是這里有問題,確切的說,mysql_init()函數(shù)被調用后,_nolock_write()函數(shù)就會出錯。哈哈,總結出了這些特點之后,我已經(jīng)隱約猜到了是哪里的問題了,還記得前幾日才寫的blog里的東西,我由于想要將libmysql.lib換成mysqlclient.lib靜態(tài)庫,所以便禁掉了msvcrtd.lib庫,我肯定這里面有關聯(lián)。
            到底是什么原因呢?我覺得,由于這個MySQL的SDK不是我自己編譯的,mysqlclient.lib里面調用crt函數(shù)時,對字符集的本地化做了設置,由于是歐美的字符集設置,所以一旦我調用了mysqlclient.lib里的函數(shù),就無法再顯示中文了。
            猜出了問題的根源,那么如何解決這個問題呢?我可以肯定的是,使用std::cout.imbue(std::locale())是行不通的,那么下面就是列出的幾個辦法:
            1、使用人家編譯好的動態(tài)庫,libmysql.lib,并將libmysql.dll拷貝過來,由于動態(tài)庫和你的程序共享crt dll,因此字符集設置應該會是一致的。
            2、如果你還是想用靜態(tài)庫,可以考慮自己下載源碼并編譯一遍,這是根本的解決辦法。
            3、如果你可以自己編譯,且想用mysqlclient.lib,那么就重新編譯mysqlclient吧,動態(tài)靜態(tài)都可以。不過官網(wǎng)上下載的編譯好的mysqlclient.lib是靜態(tài)的,不能使用。

            我最終的解決辦法是第1種,因為比較懶,不想自己再去編譯了,呵呵。

            posted on 2009-10-09 22:29 釀妹汁 閱讀(1973) 評論(3)  編輯 收藏 引用 所屬分類: C++

            評論

            # re: 封裝MySQL時解決的兩個字符集問題 2009-10-11 11:33 Jeff Chen

            我在之前的項目里遇到過相同的問題。

            解決方案是:將數(shù)據(jù)庫的字符集都改為UTC8,并將服務器端和客戶端的配置文件的字符集設置都改為UTC8。  回復  更多評論   

            # re: 封裝MySQL時解決的兩個字符集問題 2010-12-23 10:58 天下

            真有那么復雜嗎?

            歡迎去我的博客看看.有關于C操作Mysql這一塊的.

            不過C操作MYSQL沒有mysql++操作方便.
            特別是多線程環(huán)境.
              回復  更多評論   

            # re: 封裝MySQL時解決的兩個字符集問題 2010-12-23 10:58 天下

            真有那么復雜嗎?

            歡迎去我的博客看看.有關于C操作Mysql這一塊的.

            不過C操作MYSQL沒有mysql++操作方便.
            特別是多線程環(huán)境.  回復  更多評論   

            国产精品久久久天天影视香蕉| 亚洲伊人久久成综合人影院 | 亚洲国产成人久久一区WWW| 久久伊人色| 亚洲精品无码专区久久久| 国内精品伊人久久久久AV影院| 99久久99这里只有免费的精品| 久久久久国产一区二区三区| 一本色道久久99一综合| 久久精品不卡| 久久久久99精品成人片直播| 久久天天日天天操综合伊人av| 日日躁夜夜躁狠狠久久AV| 久久99精品国产麻豆不卡| 亚洲国产美女精品久久久久∴| segui久久国产精品| 亚洲国产美女精品久久久久∴| 久久九九久精品国产| 久久久久夜夜夜精品国产| 2021国产精品久久精品| 狠狠人妻久久久久久综合| 日产精品久久久久久久性色| 三级韩国一区久久二区综合| 91精品婷婷国产综合久久| 2021久久国自产拍精品| 国产成年无码久久久免费| 日韩久久无码免费毛片软件| 伊人久久综在合线亚洲2019| 99久久人妻无码精品系列蜜桃| 国产成人精品三上悠亚久久| 国产精品成人久久久| 精品久久久久久久国产潘金莲| 久久久久国产精品嫩草影院| 国产精品九九久久免费视频 | 久久综合狠狠综合久久综合88 | 久久er99热精品一区二区| 久久天天躁狠狠躁夜夜躁2014 | 97久久国产露脸精品国产| 国产99久久久国产精品小说| 久久亚洲国产最新网站| 日本WV一本一道久久香蕉|