愿编程不再乱码(含Qt)-根因深究

C++98 的问题： 既没有规定源码字符集，也没有规定执行字符集 。 可参见 【转】源码字符集(the source character set) 与 执行字符集(the execution character set) 。

字符集/编码/ASCII/ANSI/UNICODE

按照惯例，人们认为 字符集 和 字符编码 是同义词，因为使用同样的标准来定义提供什么字符并且这些字符如何编码到一系列的代码单元（通常一个字符一个单元）。由于历史的原因，MIME和使用这种编码的系统使用术语 字符集 来表示用于将一组字符编码成一系列八位字节数据的整个系统。

字符集（即 字符编码）： 被收纳进入标准的 字符和符号的集合。

编码： 规定“字符集”中具体的某一字符存储的方式（字节数、哪些字节）。

但通常所说的 “字符集” 、 “编码” 与 “GB2312, GBK, JIS, Big5” 常有混用，应结合上下文理解到底说的哪一个含义。如 notepad++ 中集中常见的编码；

其分类为如下

单字节字符编码 ISO-8859-1，ASCII ANSI 编码（多字节） GB2312(简体中文)，BIG5(繁体中文)，Shift_JIS(日本) UNICODE 编码 UTF-8，UTF-8-BOM，UTF-16（UCS-2 Big、UCS-2 Little）

Unicode ：只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。它的实现方式有如下：

UTF-8 是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。

UTF-16 用二个字节存储一个字符。

UTF32 用四个字节存储一个字符。

大端和小端（字节序）

​ 大端(Big Endian) 认为第一个字节是最高位字节（按照从低地址到高地址的顺序存放数据的高位字节到低位字节）；

​ 小端（Little Endian） 则相反，它认为第一个字节是最低位字节（按照从低地址到高地址的顺序存放据的低位字节到高位字节）。

例子： 如 0x1234abcd 写入到以 0x0000 开始的内存中，则 Little endian 和 Big endian 模式的存放结果如下：
地址 0x0000 0x0001 0x0002 0x0003
big-endian 0x12 0x34 0xab 0xcd
little-endian 0xcd 0xab 0x34 0x12

UTF-8 带 BOM 与不带区别

BOM 就是一个标记，用于放在数据最开始的几个预定的特殊符号， 并无特殊的含义 。研究一通，最后发现就是本段第一行话。南墙在 UTF-8与UTF-8 BOM && 关于UTF-8的BOM：“EF BB BF” 。

BOM Encoding
EF BB BF UTF-8
FE FF UTF-16 (big-endian)
FF FE UTF-16 (little-endian)
00 00 FE FF UTF-32 (big-endian)
FF FE 00 00 UTF-32 (little-endian)

代码页，本地编码，ANSI编码

简单理解：仅在 Windows 系统中才有代码页面，在终端 chcp 可查看。一个代码页的数字，对应这一个字符编码。而 ANSI编码 就是使用的本机器默认的字符编码，本机的简体中文中为 GB2312 。

ANSI 编码 ：使用2个字节（通常使用 0x80~0xFF 范围的2个字节来表示1个字符）来代表一个字符的各种汉字延伸编码方式。不同的国家和地区制定了不同的标准，由此产生了 GB2312, BIG5, JIS 等各自的编码标准。但是不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码的文本中。

简体中文系统：ANSI 编码代表 GB2312 编码

繁体中文系统：ANSI 编码代表 BIG 编码

日文操作系统：ANSI 编码代表 JIS 编码

MinGW/MSVC 中默认的编码

​ 这个里面属实有大坑，如下。

MSVC 的编码字符集和执行字符集都默认为 GBK；而 QtCretor 编码字符集和执行字符集都默认为 UTF-8。

MSVC 执行编译时候，发现近仅只能够将 “UFT-8 带 BOM” 格式的文件正确识别。而不带 BOM 的 UTF-8 实际也是被识别为 GBK 格式。

MSVC 在编译时，无论 .cpp 文件源码字符集是 UTF-8 、 UTF-8 BOM 、 GBK 中的哪一种；只要没有声明为执行码字符集为 UFT-8，则最终在内存中，都会被 强制转换 GBK 处理；若一旦声明，则也都会被 强制转换为 UTF-8 格式 。

// 若想声明执行字符集为 UFT-8，添加如下
#pragma execution_character_set("utf-8")

若测试的字符串 "xxxxxxx" 为偶数，恰好会有“错错得对”巧合；故特地选择 我是汉字奇 这奇数个的中文来测试

win10 终端默认的编码是 GBK，有时候还是很坑

字符串二进制的表示形式不需要编译，直接拷贝到执行程序的二进制中。

C++/Qt 中字符串和编码

​ 开发者自然重点关于 Qt 和 C++ 的字符串，以及涉及到的有关函数，以及里面内部的存储方式。

QString

QString stores a string of 16-bit QChar s, where each QChar corresponds to one UTF-16 code unit. (Unicode characters with code values above 65535 are stored using surrogate pairs, i.e., two consecutive QChar s.)

文档解释很清楚：QString 内部是以 16 位的 QChar 来存储（Unicode 的一种，但不是 utf-8）。

QByteArray

QByteArray can be used to store both raw bytes (including ‘\0’s) and traditional 8-bit ‘\0’-terminated strings. Using QByteArray is much more convenient than using const char * .

QByteArray 既可以用来存储原始的字节，包括 '\0' ，也可以用来存储传统的 8-bit 的以 '\0' 结尾的字符串。使用QByteArray比使用普通的const char* 更方便。

QChar

In Qt, Unicode characters are 16-bit entities without any markup or structure. This class represents such an entity. It is lightweight, so it can be used everywhere. Most compilers treat it like an unsigned short .

在 Qt 中，Unicode 字符是没有任何标记或结构的 16 位实体。 这个类代表了这样一个实体。它是轻量级的，所以它可以被到处使用。大多数编译器把它当作一个 unsigned short。

fromUtf16 utf16 和 unicode 与 UTF-16（UCS2）编码的字符串互相转换，utf16 函数与 unicode 函数功能一样， 注意没有 to 前缀，因为 QString 运行时的内码就是 UTF-16，字符的双字节采用主机字节序。 fromUcs4 toUcs4 与 UTF-32（UCS4）编码的字符串互相转换，一个字符用四个字节编码，占空间多，应用较少。 fromStdString toStdString 与 std::string 对象互相转换，因为 C++11 规定标准字符串 std::string 使用 UTF-8 编码，这对函数功能与上面 **Utf8 转码函数相同。 fromStdWString toStdWString 与 std::wstring 对象相互转换，在 Linux 系统里宽字符是四字节的 UTF-32，在 Windows 系统里宽字符是两字节的 UTF-16。因为不同平台有歧义，不建议使用。 fromCFString fromNSString toCFString toNSString 仅存在于苹果 Mac OS X 和 iOS 系统。

QTextCodec：仅支持在非 Unicode 格式和 Unicode 之间进行转换。不能不同的非 Unicode 之间直接转换（如： Shift_JIS 和 GBK 之间不可直接转换、必须使用 Unicode 中转一次）

C++ 使用的字符串

​ 在 C++ 中，以前通常使用 char 表示单字节的字符，使用 wchar_t 表示宽字符，对国际码提供一定程度的支持。 char * 字符串有专门的封装类 std::string 来处理，标准输入输出流是 std::cin 和 std::cout 。对于 wchar_t * 字符串，其封装类是 std::wstring，标准输入输出流是 wcin 和 wcout。

​ 虽然规定了宽字符，但是没有明确一个宽字符是占用几个字节，Windows 系统里的宽字符是两个字节，就是 UTF-16；而 Unix/Linux 系统里为了更全面的国际码支持，其宽字符是四个字节，即 UTF-32 编码。这为程序的跨平台带来一定的混乱，除了 Windows 程序开发常用 wchar_t* 字符串表示 UTF-16 ，其他情况下 wchar_t* 都用得比较少。

​ MFC 一般用自家的 TCHAR 和 CString 类支持国际化，当没有定义 _UNICODE 宏时，TCHAR = char，当定义了 _UNICODE宏 时，TCHAR = wchar_t，CString 内部也是类似的。 Qt 则用 QChar 和 QString 类（内部恒定为 UTF-16），一般的图形开发库都用自家的字符串类库。

在新标准 C++11 中，对国际码的支持做了明确的规定：

char * 对应 UTF-8 编码字符串（代码表示如 u8”多种文字”），封装类为 std::string；

新增 char16_t * 对应 UTF-16 编码字符串（代码表示如 u”多种文字”），封装类为 std::u16string ；

新增 char32_t * 对应 UTF-32 编码字符串（代码表示如 U”多种文字”），封装类为 std::u32string 。

因为 Qt 有封装好的 QString，所以不太需要这些新增的字符串格式。

char *

1. 如果是“窄字符/字符串”(以char为单位)，那么不同的编译器可能不一样。以 VC++ 为例，它是由系统代码页决定的，比如在中文 windows 系统下就采用 GBK 编码。（算是 ⓶式 的乱码的最开始原因）
2. 如果字符/字符串前有指定编码方式，那没什么好说的了，就采用指定的编码方式，如下：

char* s1 = u8"hello";     //窄字符串，utf-8编码 (C++11)
wchar_t* s2 =  L"hello";  //宽字符串，utf-16编码
char16_t* s3 =  u"hello"; //宽字符串，utf-16编码 (C++11)
char32_t* s4 =  U"hello"; //utf-32编码 (C++11)
//'\x12' : \x后面接2个16进制数字，可表示一个窄字符char，多个\x连起来可表示一个utf-8字符，如"\xE4\xBD\xA0"
//L'\u1234' : \u后面接4个16进制数字，可表示一个utf-16宽字符
//U'\U12345678' : \U后面接8个16进制数字，可表示一个Utf-32

char []

通常情况下和可以 char [] 和 char * 进行混用，一个为形参，另一个为实参。

不同点为，详细可见 【C/C++】对char* 和 char[]区别的一些理解 ：

3. char*是变量，值可以改变， char[]是常量，值不能改变。
4. char[]对应的内存区域总是可写，char*指向的区域有时可写，有时只读
5. char * 和char[]的初始化操作有着根本区别（指向常量区和赋值变量的栈区）

string

typedef basic_string string;

String class

Strings are objects that represent sequences of characters.

The standard string class provides support for such objects with an interface similar to that of a standard container of bytes, but adding features specifically designed to operate with strings of single-byte characters.

The string class is an instantiation of the basic_string class template that uses char (i.e., bytes) as its character type , with its default char_traits and allocator types (see basic_string for more info on the template).

Note that this class handles bytes independently of the encoding used: If used to handle sequences of multi-byte or variable-length characters (such as UTF-8), all members of this class (such as length or size ), as well as its iterators, will still operate in terms of bytes (not actual encoded characters).

字符串类是 basic_string 类模板的实例，它使用 char（即字节）作为其字符类型，并具有默认的char_traits 和分配器类型（关于模板的更多信息请参见 basic_string ）。

请注意，该类处理字节的方式与使用的编码无关。如果用于处理多字节或可变长度的字符序列（如 UTF-8），这个类的所有成员（如 length 或 size ），以及它的迭代器，仍将以字节为单位进行操作（而不是实际编码的字符）。

see: https://www.cplusplus.com/reference/string/string

char

char - 能在目标系统上最有效地处理的字符表示的类型（拥有与 signed char 或 unsigned char 之一相同的表示和对齐，但始终是独立的类型）。 多字节字符串 用此类型表示编码单元。对于每个范围 [0, 255] 中的 unsigned char 类型值，将该值转换成 char 再转换回 unsigned char 产生原值。 (C++11 起) char 的符号性取决于编译器和目标平台： ARM 和 PowerPC 的默认设置常为无符号，而 x86 与 x64 的默认设置常为有符号。

wchar_t - 宽字符表示的类型（见 宽字符串 ）。要求大到足以表示任何受支持的字符编码位点（支持 Unicode 的系统上为 32 位。值得注意的例外是 Windows，其中 wchar_t 为 16 位并保有 UTF-16 编码单元）。它与上述整数类型之一具有相同的大小、符号性和对齐，但它是独立的类型。

const char * cc = "\xce\xd2\xca\xc7\xba\xba\xd7\xd6\xc6\xe6" ; // GBK const char * cc1 = "\xe6\x88\x91\xe6\x98\xaf\xe6\xb1\x89\xe5\xad\x97\xe5\xa5\x87" ; // UTF-8 const char * cc2 = "我是汉字奇" ; // 是 10 或 15 字节，但一定是 5 个字符 cout << "cout ==> cc: " << & cc << " " << cc << endl ; cout << "cout ==> cc1: " << & cc1 << " " << cc1 << endl ; cout << "cout ==> cc2: " << & cc2 << " " << cc2 << endl ; qDebug ( ) << "qDebug ==> cc: " << & cc << " " << cc ; qDebug ( ) << "qDebug ==> cc1: " << & cc1 << " " << cc1 ; qDebug ( ) << "qDebug ==> cc2: " << & cc2 << " " << cc2 ; return 0 ;

​ 将上面代码分别在 VS2017 和 QtCreator 中验证；（取消）注释 //#pragma execution_character_set("utf-8") 来验证；最后测试的验证结果如图 https://kdocs.cn/l/slqOBPQmfajc 。

优雅在 Win 上使用 UTF-8 + Qt 跨平台

​ 最初的愿望和其简单，只不过是想使用一套代码，既可以使用 MSVC + Qt + UTF-8 编译运行不乱码；也可以在 Linux + gcc + UTF-8 也不乱码。

​ 综上的解决方案为同运行一下即可：

在 CMakeLists.txt 中添加如下代码

# 此处配合 VMSVC 的 UTF8-BOM 插件，达到跨平台
if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
  message("---using Clang---")
elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
  message("---using GCC---")
elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
  message("---using Intel C++---")
elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
	message("---sing Visual Studio C++---")
	add_compile_options("$<$<C_COMPILER_ID:MSVC>:/utf-8>")
	add_compile_options("$<$<CXX_COMPILER_ID:MSVC>:/utf-8>")
endif()

Visual Studio 中开发时候，所有 .h .cpp 文件都使用 UTF-8-BOM 格式，可以安装 ForceUTF8（withBOM） 扩展

​ 感觉这样子使用 utf-8 跨平台清爽了很多。 对于网上的添加 //#pragma execution_character_set("utf-8") 方式，则需要在每一个 .h/.cpp 中都加上这几行，相比之下只用在 cmake 中添加两行，则是优雅了很多。

#if _MSC_VER >= 1600 
	#pragma execution_character_set("utf-8") 
#endif

总结

​ 关于使用 Visual Studio、Qt Crator 中容易出现的字符乱码问题；一般可重如下三个方面入手：⑴文件编码、⑵代码编码、⑶输出结果显示的编码。我们只要以此来检查这三部分，就可以找到乱码的原因，结合上面的每一个知识点的理解，即可更正。 毕竟乱码的问题是由编码和解码方式不对引起的 。

​ 希望本篇能够协助读者彻底理解乱码原因后，最后均能可自行解决自己平台所对应的实际乱码问题，最终授人以渔。最后，若没啥疑问和问题的话？那我就要去准备喝汤了~~

形如 "中文123" 这种格式的 ANSI 字符串 ，其在不同编码下所占字节和字符个数？

不同系统（默认的编码）对 "中文123" 字符串是如何处理的？

MSVC 的一些大坑、以及强制转换 GBK/UTF-8

终端的编码是否会影响输出效果？

shouce.jb51.net 或 crifan.com

Qt开发中文显示乱码

qt中文乱码问题

QString乱谈(2)

QT、VS（二）——VS控制台程序显示中文为乱码的问题解决办法

彻底解决Qt中文乱码以及汉字编码的问题(UTF-8/GBK)

源文件字符集，编译器内部字符集，执行字符集，控制台乱码问题，Qt中文问题