字符编码方式

  字符编码对于程序的跨平台开发、中文乱码问题解决等都是非常重要。在计算机内部,所有的信息最终都表示为二进制数,每个二进制位(bit, 比特)有0和1两种状态,八个比特组成一个字节(Byte),即一个8位的物理存贮单元。而字符则是一个文化相关的符 。编码(encode)负责字符到字节的编码转换,解码(decode)负责字节到字符的解码转换。

一、ANSI多字节编码

  在计算机最早的时期,只支持英文字符,都是用ASCII(American Standard Code for Information Interchange, 美国标准信息交换代码)编码。ASCII码规定一个字符只占用一个字节的后面7位,最前面的1位统一规定为0,因此一共规定了128个字符,比如大写字母A是65(二进制01000001)。随着计算机的推广,越来越多的国家和地区面临本地语言如何在计算机里使用和显示的问题。对于中文DOS系统和早期的中文Windows系统,大陆制定了国际码GB2312,港澳台地区则使用大五码Big5。微软针对这些本地化字符编码采用的ANSI(American National Standards Institute, 美国国家标准学会)多字节编码方式。系统里的英文字符用0x00~0x7f来表示,而对于中文之类的本地化字符编码,用0x80~0xFF来表示,这样技能兼容ASCII,又能正常使用本地化语言。
  大陆的国际码发展了好几代,归结如下:

三、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* 都用得比较少。

在新标准 C++11 中,对国际码的支持做了明确的规定:
● char * 对应 UTF-8 编码字符串(代码表示如 u8”多种文字”),封装类为 std::string;
● 新增 char16_t * 对应 UTF-16 编码字符串(代码表示如 u”多种文字”),封装类为 std::u16string ;
● 新增 char32_t * 对应 UTF-32 编码字符串(代码表示如 U”多种文字”),封装类为 std::u32string 。

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

四、字符编码测试

在Windows系统下,将一个txt文件另存为时, 在弹出对话框底部有个编码下拉框。如下图所示

这里写图片描述
里面有四个选项:ANSI,Unicode,Unicode big endian 和 UTF-8。
1)ANSI:默认的编码方式,简体操作系统是GBK,繁体操作系统就是Big5。Window命令行默认的字符编码也是这个。
2)Unicode:Window所说的国际码一般都是之UTF-16LE,文件开头带有BOM标记(两个字节)。
3)Unicode big endian:即UTF-16BE,文件开头带有BOM标记(两个字节), 很少用到。
4)UTF-8:这是 Unix/Linux 系统里通用的国际码存储交换格式,记事本保存的文件开头会有 UTF-8 签名(3字节,类似 BOM)。

总结

从跨平台的运行的角度,推荐UTF-8编码的源文件。UTF-8 和 GBK 其实对英文和数字都是一样的 ASCII 单字节编码,所以源文件用英文和数字是肯定不乱码,主要是汉字之类的本地语言文字编码显示容易出错。
UTF-8 编码是属于通用的存储交换格式,但这种编码的缺点就是一个字符的长度不固定,这对字符串操作效率是有影响的,因为得先确定每个字符的长度。

参考资料:
https://qtguide.ustclug.org/
http://www.unicode.org/faq/utf_bom.html

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2017年9月27日
下一篇 2017年9月28日

相关推荐