字符亂碼問題詳解

在解釋字符亂碼問題之前，我們需要先理清一些基本概念

1 編碼字符集與字符編碼方式

編碼字符集

編碼字符集是所有字符以及對應代碼值的集合。編碼字符集中的每個字符都對應一個唯一的代碼值。常見的編碼字符集：ASCII字符集、GBXXXX字符集、BIG5字符集、Unicode字符集等。

字符編碼方式

編碼字符集中只規(guī)定了字符的代碼值并未規(guī)定具體如何存儲，字符編碼方式解決了字符在計算機中如何存儲的問題，它是將編碼字符集中的字符代碼值轉換為實際的存儲字節(jié)序列的一種映射規(guī)則。常見字符編碼方式：ASCII編碼、GBXXXX編碼、BIG5編碼、UTF-8編碼、UTF-16編碼、UTF-32編碼等。每種編碼字符集至少對應一種字符編碼方式，也可以對應多種編碼方式。

什么是字符的編碼與解碼?
編碼就是把?個字符編碼成二進制碼存起來的方式，而解碼就是把這個二進制碼按照原本編碼的規(guī)則還原成原來的字符。

源字符集： 源文件字符集是指源文件保存時按源字符集編碼方式編碼后的字符集。VS2019源字符集編碼格式默認是GBK格式，在利用VS編寫代碼時，源代碼會自動編碼為GBK字符集。

執(zhí)行字符集： 程序運行時所使用的字符集，編譯器會將源字符集先按照源字符集編碼方式進行解碼，再將解碼后得到的字符按照執(zhí)行字符集編碼方式編碼為執(zhí)行字符集。執(zhí)行字符集一般默認使用Windows系統本地字符編碼，若是簡體中文系統，則是GBK或GB2312字符集。

2 字符亂碼原因

在編程中我們給某個函數輸入中文字符串的時候，在運行的時候中文字符串往往就會變成亂碼，這是因為編碼方式與解碼方式不一致造成的。

例：
VS+QT編譯環(huán)境中，如果直接將中文字符串傳給QT函數時，會出現亂碼：

QString s("你好");//亂碼
qDebug() << "路漫漫其修遠兮";//亂碼

原因在于這些中文字符串被GBK編碼為源字符集，編譯器會先采用GBK將這被GBK編碼的源字符集解碼，再用GB2312編碼為執(zhí)行字符集，而Qt5內部采用Unicode字符集，UTF-16編碼，QT中的函數會將執(zhí)行字符集使用UTF-8解碼，再使用UTF-16編碼為unicode字符集，QString內部使用UTF-8對執(zhí)行字符集進行解碼的時候，與執(zhí)行字符集編碼格式不一致，肯定會出現亂碼現象。

為什么英文字符就不會出現亂碼現象呢？

英文字符通常都是ASCII字符編碼，常見的字符編碼都會以某種形式“兼容”ASCII編碼，而我們接觸比較多的UTF-8和GBK則是完全兼容ASCII，也就是ASCII編碼的數據，在UTF-8、GBK中會是一樣的數字形式（一個字節(jié)）。即
AB在ASCII編碼中對應的是0x41和0x42，在GB2312和UTF-8中還是0x41和0x42，所以對于AB這兩個字符用GB2312編碼為0x41和0x42后，采用UTF-8再進行解碼，得出來的仍然是AB，所以不會出現亂碼。

3 字符亂碼解決方案

（1）使用QStringLiteral宏

從“字符串常量”創(chuàng)建QString對象

qDebug() << QStringLiteral("路漫漫其修遠兮");

QStringLiteral宏它只能處理常量。

（2）使用fromLocal8Bit()函數

fromLocal8Bit是Qt 中QString 類的一個成員函數，用于將使用本地編碼的字符串轉換為 QString 對象的內部 Unicode編碼。

qDebug() << QString::fromLocal8Bit("路漫漫其修遠兮");

使用QStringLiteral宏和fromLocal8Bit()函數輸出的字符串還帶有雙引號：

使用下面的這兩個方法可以解決這種問題。

（3）使用#pragma execution_character_set(“utf-8”)

源程序中加上如下指令，將源文件的可執(zhí)行字符集編碼方式設置為utf-8

#pragma execution_character_set("utf-8")
 qDebug() << "路漫漫其修遠兮";

（4）使用u8關鍵字

C++17到來后出現了u8關鍵字，表示一個字符串的可執(zhí)行字符集編碼方式是UTF-8編碼

qDebug() << u8"路漫漫其修遠兮"

到此這篇關于VS+QT編譯環(huán)境中字符亂碼問題詳解的文章就介紹到這了,更多相關VS QT字符亂碼內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論