字符编码方式

用VS2013时,不小心改变了其默认保存的编码方式:Chinese Simplified(GB2312)-Codepage 936,导致软件界面中文显示时部分字会乱码。

  字符编码对于程序的跨平台开发、中文乱码问题解决等都是非常重要。在计算机内部,所有的信息最终都表示为二进制数,每个二进制位(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,又能正常使用本地化语言。
  大陆的国际码发展了好几代,归结如下:
这里写图片描述

  新的国际码标准通常是兼容旧的编码方式的,所以一般对简体中文的文本选择GBK或GB18030编码都是可以正常显示的。微软针对各种本地化语言的页面有自己的编号方式,GBK对应的代码页编号是936,GB18030对应的代码页编号是54936。

二、Unicode编码

  ANSI多字节编码解决了各种语言的本地化使用问题,也有自己的缺陷:各地指定的编码标准只对自己的语言文字有效,大家都用0x810~0xFF来表示自己的语言文字,而不考虑别的语言文字如何编码,所以不同语言文字的编码都是冲突的。比如简体中文(GBK)的文本放到繁体中文(Big5)的操作系统里,就被默认解析成繁体字编码,显示混乱的繁体字。
  因此,国际组织制订了unicode,也叫万国码、国际码等。这种字符编码是对全球语言同一分配编码区间,各种语言互不冲突。Unicode编码可以分为编码方式和实现方式两个层次。对于国际组织发布的Unicode编码标准,就是编码方式,最常用的是UCS-2(Universal Character Set 2),采用两字节编码一个字符。当然国际语言文字太多,两个字节不够用,就有四字节编码方式UCS-4。它们仅仅是标准,而不是实现。
  在编码实现的过程中,有些考虑旧的单字节ASCII编码,有些不考虑兼容性;有些考虑双字节中哪个字节放在前面,哪个字节放在后面的问题,即BOM(Byte Order Mark, 字节顺序标记)的作用。因此诞生了多种Unicode的实现方式,统称为Unicode转换格式(Unicode Transformation Format, UTF):

  unicode只规定了符号的二进制代码,却没有规定了这个二进制代码如何在计算机存储。比如汉字“严”的unicode是十六进制4E25,二进制数是100111000100101。也就是说这个字符的表示至少需要两个字节。其他更大的字符,可能至少需要3个字节或4个字节。这就导致出现了unicode的多种编码方式,也就是说不同的二进制格式用来表示unicode。
ASCII码中,用来表示字符的二进制数,就是计算机中的存储形式。

UTF-8
UTF-8是Unicode的实现方式之一。UTF-8是一种变长的编码方式,可以使用1~4个字节表示一个字符,根据不同的字符变化字节的长度。
UTF-8的编码规则很简单,只有二条:
1)对于单字节的符号,字节的第一位设为0,后面7位为这个符号的unicode码。因此对于英语字母,UTF-8编码和ASCII码是相同的。
2)对于n字节的符号(n>1),第一个字节的前n位都设为1,第n+1位设为0,后面字节的前两位一律设为10。剩下的没有提及的二进制位,全部为这个符号的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* 都用得比较少。

在新标准 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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 在不同的环境下,即使使用相同的哈希函数和字符编码方式,也有可能会计算出不同的哈希值。这可能是由于两个环境使用的是不同版本的 Python 解释器,这两个解释器可能会使用不同的哈希算法实现。此外,还有可能是因为系统的体系结构不同而导致了计算哈希值的细微差异。 ### 回答2: 在不同环境下的Python,对同一个字符串使用相同的哈希函数和字符编码方式,计算出不同的哈希值可能是因为以下几个原因: 1. 哈希函数的实现不同:不同的Python环境可能使用不同的哈希函数实现,这些实现可能采用不同的算法或参数,导致相同的输入得到不同的输出。 2. 字符编码的不一致:字符串在计算哈希值之前需要被编码成字节序列。不同的Python环境可能采用不同的字符编码方式,比如在Python 2中默认使用ASCII编码,而在Python 3中默认使用Unicode编码。不同的编码方式可能会将相同的字符映射成不同的字节序列,进而影响到哈希值的计算结果。 3. 环境依赖的因素:Python的哈希函数实现可能依赖于一些环境因素,比如操作系统、硬件架构等。不同的环境因素可能会影响到哈希函数的行为,造成计算相同字符串的哈希值时的不一致性。 因此,为了保证在不同环境下计算出相同的哈希值,可以采取以下措施: 1. 显式指定哈希函数:可以使用标准库中提供的特定哈希函数,如MD5或SHA-256等,以确保不同环境下的一致性。 2. 统一字符编码方式:在处理字符串之前,将其统一编码成同一种字符编码方式,如UTF-8。这样可以避免因编码方式不一致而导致的哈希值不同。 3. 确保环境一致性:在不同环境下进行字符串哈希计算时,尽量保持环境的一致性,比如操作系统、Python版本等。这样可以减小环境因素对哈希值计算的影响。 综上所述,不同环境下的Python计算相同字符串的哈希值可能会产生不同结果,这涉及到哈希函数实现、字符编码方式和环境因素等多个方面。为了确保一致性,可以采取相应措施来规避这些问题。 ### 回答3: 在不同的环境中,对同一个字符串使用相同的哈希函数和字符编码方式计算出不同的哈希值,可能由以下几个原因造成: 1. 字符编码方式不一致:不同的环境可能使用不同的字符编码方式。比如,在一个环境中使用UTF-8编码方式,而在另一个环境中使用ASCII编码方式,这样相同的字符串在不同环境中编码后的二进制表示就会不同,进而导致计算出的哈希值不同。 2. 哈希函数实现差异:尽管使用相同的哈希函数,但在不同的环境中也有可能有差异的实现。哈希函数的实现可以基于操作系统、编程语言版本等因素,各种差异都可能导致相同字符串计算出不同的哈希值。 3. 原始数据的差异:相同的字符串在不同环境中可能对应不同的原始数据。原始数据包括字符串的字节表示以及额外的元数据等信息。如果原始数据不同,即使使用相同的哈希函数和字符编码方式,在计算哈希值时也会得到不同的结果。 因此,对于同一个字符串在不同环境中计算出不同的哈希值,需要考虑字符编码方式的差异、哈希函数实现的差异以及原始数据的差异等因素。如果想要在不同环境中得到一致的哈希值,需要确保使用相同的字符编码方式,并且在不同环境中使用相同的哈希函数实现。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值