字符编码知识以及相互之间的转换

简介: UTF-16(UCS-2)是Unicode的其中一个使用(实现)方式,大部分字符采用定长的字节存储,即字符属于宽字符,但UTF-16却无法兼容于ASCII编码。

UTF-16(UCS-2)是Unicode的其中一个使用(实现)方式,大部分字符采用定长的字节存储,即字符属于宽字符,但UTF-16却无法兼容于ASCII编码。

UTF-8是Unicode的一个使用(实现)方式,编码格式兼容ASCII编码,采用变长的字节存储字符,即字符属于多字节字符。

windows(C语言)在使用unicode的时候就是采用的UTF-16,即宽字符。

UTF-16比起UTF-8,好处在于大部分字符都以固定长度的字节 (2字节) 储存。

以下是以windows为例的几种字符转换:

1、UTF8转UNICODE

MultiByteToWideChar(CP_UTF8,0,utf8_code,strlen(utf8_code),unicode,strlen(utf8_code));

2、UNICODE转UTF8

WideCharToMultiByte(CP_UTF8,0,unicode,wcslen(unicode),utf8_code,wcslen(unicode),0,0);

3、UTF8与ASCII的相互转换

因为UTF8兼容ASCII所以在进行ASCII字符编码处理的时候,UTF8可以不用转换就可以正确的处理ASCII字符,而在用UTF8进行其他语言字符编码处理的时候就会因为编码问题而出现问题,因为操作系统包括windows在内部数据处理的时候都会统一一种编码方式,通常是ASCII编码形式,然后根据地区以及使用的语言和字符编码不同再进行相应的编码转换,从而正确完成字符编码和字符集(codepage)的匹配,达到正确处理数据的目的。

乱码是可以显示当前指定的字体和文字,但是因为字符的编码不对导致在显示的时候索引错误。

还有一种情况是出现口口口口,所有的都是口,这样的情况是因为缺少字库。

在内存中最小的单位是字节,而最小的文字单位是字符(包括汉字以及其他语言形式),在进行编码存储的时候两者不一定相互对应,即一个字符不一定只占一个字节,所以在进行数据处理的时候需要根据字符进行处理,一段char类型内存可以存储任何字符的编码,但是编解码方式都是按照ASCII单字节对应单个字符的形式,而这种编解码方式只适用于英文字符,对于其他语言字符则会出现问题,而出现乱码的根本原因是编码方式和解码方式不一致。

比如:编码方式采用的是UTF8,而解码的时候却是用的ASCII,或者编码采用的GBK,而解码却是UTF8,这些情况下都会出现乱码,解决办法也很简单,就是统一编解码方式。

不同的codepage对应不同语言字符,不同的语言字符编码方式可能不同,统一的编码方式是unicode。


一、UTF8转ASCII

先把UTF8转换为UNICODE,再从UNICODE转换为ASCII,变的是编码方式,这样在进行输出的时候就可以根据codepage和具体字符编码输出正确的结果,而不会出现乱码。

二、ASCII转UTF8

先把ASCII转换为UNICODE,再从UNICODE转换为UTF8。


目录
相关文章
Unicode码和ASCII码及其转换
Unicode码和ASCII码及其转换
212 0
|
iOS开发
Unicode 与 UTF-8 编码的转换
Unicode 与 UTF-8 编码的转换
Unicode 与 UTF-8 编码的转换
错误: 编码GBK的不可映射字符
错误: 编码GBK的不可映射字符
101 0
|
存储 算法 Java
【字符编码】字符编码 && Base64编码算法
  在前面的解决乱码的一文中,只找到了解决办法,但是没有为什么,说白了,就是对编码还是不是太熟悉,编码问题是一个很简单的问题,计算机从业人员应该也必须弄清楚,基于编码的应用有Base64加密算法,然后,这个问题一直放着,想找个机会解决。于是乎,终于逮到机会,开始下手。
187 0
【字符编码】字符编码 && Base64编码算法
ASCII编码(含扩展ASCII)
ASCII编码(含扩展ASCII)
153 0
ASCII编码(含扩展ASCII)
|
Web App开发 存储 Windows
字符编码知识:Unicode、UTF-8、ASCII、GB2312等编码之间是如何转换的?
转自:  http://apps.hi.baidu.com/share/detail/17798660 字符编码是计算机技术的基石,想要熟练使用计算机,就必须懂得字符编码的知识。不注意的人可能对这个不在意,但这些名词有时候实在让人迷惑,对想学习计算机知识的人来说,搞懂它也十分重要,我也是在学习中慢慢了解了一些这方面的知识。
1803 0