字元編碼對程式的影響及分析

2021-07-27 19:18:33 字數 1313 閱讀 5286

今天在呼叫乙個動態庫的時候,使用到下面的語句:

hmodule hdll = loadlibrary("filedir\\dlltest.dll");
因為編譯環境選擇的是unicode字符集,所以當我上面的語句從乙個多位元組字符集的編譯環境複製過來後,出現了語法錯誤。語法錯誤的提示為:

error c2664: 「loadlibraryw」: 不能將引數 1 從「const char *」轉換為「lpcwstr」

其實是在c++庫函式中做了如下的處理:

#ifdef unicode

#define loadlibrary loadlibraryw

#else

#define loadlibrary loadlibrarya

#endif

也就是說如果在unicode編碼集下,程式呼叫的是函式loadlibraryw,該函式需要乙個wchar_t(寬字元)類的引數。那麼在傳入」filedir\dlltest.dll」做為引數時,是乙個多位元組字符集的形式,不能滿足引數要求。

解決方法:

需要對引數進行_t()或l處理,使之轉換為寬字元的儲存形式。其中_t()和l的區別參見這篇文章:

_t()與l區別

但是在修改之後動態庫仍未成功載入,原來是我漏拷了兩個依賴動態庫,拷貝之後成功解決問題。

重點:

1、字串在程式中的儲存形式是根據字元編碼的不同改變的,也就是說在linux環境下,如果我使用引數-finput-charset= 可以指定原始檔的字符集,如果未指定情況下預設是utf-8;如果我使用引數-fexec-charset= 可以指定可執行檔案中字元編碼方式。

例如:我的原始檔以anci儲存,在未使用引數指定原始檔字符集的情況下,為什麼能正常編譯呢?因為編譯器會以為原始檔中anci的字元編碼是utf-8格式的編碼,所以能夠正常編譯。但是編譯器會以utf-8來解析,導致輸出後會出現亂碼。這也就是在編輯介面能看到正常的字元顯示,但編譯後輸出亂碼的原因。

2、unicode是一種字元與編碼的對映表,utf-8、utf-16等則是依照unicode的編碼規則,制定相應的字元儲存方式。比如乙個「中」字,在unicode編碼中用「0x4e 0x2d」來表示,則utf-8、utf-16等編碼方式按其各自的規則解碼後,獲得的中字編碼必須為「0x4e 0x2d」。utf-8是變長編碼,節省空間並且容錯性強。容錯性強是因為它對每個字元的編碼都用第乙個位元組的前幾位來表示共有多少位元組來表示這個字元,也就說出現錯誤,只會導致乙個字元被破壞。utf-16是定長編碼,每個字元使用2位元組來表示。出現錯誤,會導致一整行的資料被破壞。

閏秒對linux的影響分析及解決

大概了解了下閏秒及其如何讓linux kernel panic 閏秒的產生 日常所用時間utc,是根據地球自轉計時,跟精確的原子時鐘存在偏差,為了保持一致,每偏差1s就進行1次同步,就產生了閏秒。即如人們所講的,在今年6月30號出現23 59 60。printk kern notice clock ...

gcc 不同版本對程式的影響

1.因為在linux 下我們寫的c 程式,預設是會鏈結 libstdc so 這個動態庫檔案,如果牽扯到版本的更新,直接用新的動態庫檔案更新老的話,老的程式都無法執行。因為找不到老的動態庫檔案。2.當使用高版本的 gcc 鏈結程式的時候,老的原始檔需要重新編譯,因為老的 o 檔案中 可能對 stl中...

大小端裝置對程式的影響

裝置大小端模式的概念 大端模式,是指資料的高位元組儲存在記憶體的低位址中,而資料的低位元組儲存在記憶體的高位址中,這樣的儲存模式有點兒類似於把資料當作字串順序處理 位址由小向大增加,而資料從高位往低位放 這和我們的閱讀習慣一致。小端模式,是指資料的高位元組儲存在記憶體的高位址中,而資料的低位元組儲存...