python 字符集字符编码， UTF-8的编码过程

linux 的编码输出，比如从文件输出，从 printf 输出，需要控制台做适当的编码匹配（如果编码不匹配，一般和该程序编译时的编码有若干关系），而控制台的转换输入需要查看当前的系统编码。

比如控制台当前的编码是 UTF-8, 那么 UTF-8 编码的东西能正确显示，GBK 就不能；

同样，当前编码是 GBK, 就能显示 GBK 编码。

 

 

https://www.zhihu.com/question/23374078

简单来说：

Unicode 是「字符集」

UTF-8 是「编码规则」

其中：

字符集：为每一个「字符」分配一个唯一的 ID（学名为码位 / 码点 / Code Point）

编码规则：将「码位」转换为字节序列的规则（编码/解码 可以理解为 加密/解密 的过程）

广义的 Unicode 是一个标准，定义了一个字符集以及一系列的编码规则，即 Unicode 字符集和 UTF-8、UTF-16、UTF-32 等等编码……

Unicode 字符集为每一个字符分配一个码位，例如「知」的码位是 30693，记作 U+77E5（30693 的十六进制为 0x77E5）。

UTF-8 顾名思义，是一套以 8 位为一个编码单位的可变长编码。

会将一个码位编码为 1 到 4 个字节：

U+ 0000 ~ U+ 007F: 0XXXXXXX

U+ 0080 ~ U+ 07FF: 110XXXXX 10XXXXXX

U+ 0800 ~ U+ FFFF: 1110XXXX 10XXXXXX 10XXXXXX

U+10000 ~ U+1FFFF: 11110XXX 10XXXXXX 10XXXXXX 10XXXXXX

根据上表中的编码规则，之前的「知」字的码位 U+77E5 属于第三行的范围：

7　　7　　E　　5

0111 0111 1110 0101 二进制的 77E5

--------------------------

0111 011111 100101 二进制的 77E5

1110XXXX 10XXXXXX 10XXXXXX 模版（上表第三行）

11100111 10011111 10100101 代入模版（上两行做或运算）

　　E 7 　　9 F 　　A 5

这就是将 U+77E5 按照 UTF-8 编码为字节序列 E79FA5 的过程。反之亦然。

 

---

 

作者：盛世唐朝
链接：https://www.zhihu.com/question/23374078/answer/69732605
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

很久很久以前，有一群人，他们决定用8个可以开合的晶体管来组合成不同的状态，以表示世界上的万物。他们看到8个开关状态是好的，于是他们把这称为”字节“。再后来，他们又做了一些可以处理这些字节的机器，机器开动了，可以用字节来组合出很多状态，状态开始变来变去。他们看到这样是好的，于是它们就这机器称为”计算机“。

 

开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。
他们把其中的编号从0开始的32种状态分别规定了特殊的用途，一但终端、打印机遇上约定好的这些字节被传过来时，就要做一些约定的动作：

遇上0×10, 终端就换行；

遇上0×07, 终端就向人们嘟嘟叫；

遇上0x1b, 打印机就打印反白的字，或者终端就用彩色显示字母。

他们看到这样很好，于是就把这些0×20以下的字节状态称为”控制码”。他们又把所有的空
格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字了。大家看到这样，都感觉
很好，于是大家都把这个方案叫做 ANSI 的”Ascii”编码（American Standard Code for Information Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。

 

后来，就像建造巴比伦塔一样，世界各地都开始使用计算机，但是很多国家用的不是英文，他们的字母里有许多是ASCII里没有的，为了可以在计算机保存他们的文字，他们决定采用
127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128 到255这一页的字符集被称”扩展字符集“。

从此之后，贪婪的人类再没有新的状态可以用了，美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧！

 

等中国人们得到计算机时，已经没有可以利用的字节状态来表示汉字，况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民，我们不客气地把那些127号之后的奇异符号们直接取消掉, 规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的”全角”字符，而原来在127号以下的那些就叫”半角”字符了。中国人民看到这样很不错，于是就把这种汉字方案叫做 “GB2312“。GB2312 是对 ASCII 的中文扩展。

 

但是中国的汉字太多了，我们很快就就发现有许多人的人名没有办法在这里打出来，特别是某些很会麻烦别人的国家领导人。于是我们不得不继续把GB2312 没有用到的码位找出来老实不客气地用上。后来还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字
符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK包括了GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。 后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。 中国的程序员们看到这一系列汉字编码的标准是好的，于是通称他们叫做 “DBCS“（Double Byte Charecter Set 双字节字符集）。在DBCS系列标准里，最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里，因此他们写的程序为了支持中文处理，必须要注意字串里的每一个字节的值，如果这个值是大于127的，那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持，会编程的计算机僧侣们都要每天念下面这个咒语数百遍： “一个汉字算两个英文字符！一个汉字算两个英文字符……”

 

因为当时各个国家都像中国这样搞出一套自己的编码标准，结果互相之间谁也不懂谁的编码，谁也不支持别人的编码，连大陆和台湾这样只相隔了150海里，使用着同一种语言的兄弟地区，也分别采用了不同的 DBCS 编码方案——当时的中国人想让电脑显示汉字，就必须装上一个”汉字系统”，专门用来处理汉字的显示、输入的问题，像是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持 BIG5 编码的什么”倚天汉字系统”才可以用，装错了字符系统，显示就会乱了套！这怎么办？而且世界民族之林中还有那些一时用不上电脑的穷苦人民，他们的文字又怎么办？ 真是计算机的巴比伦塔命题啊！

 

正在这时，大天使加百列及时出现了——一个叫 ISO（国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号 的编码！他们打算叫它”Universal Multiple-Octet Coded Character Set”，简称 UCS, 俗称 “unicode“。

 

unicode开始制订时，计算机的存储器容量极大地发展了，空间再也不成为问题了。于是 ISO
就直接规定必须用两个字节，也就是16位来统一表示所有的字符，对于ASCII里的那些“半角”字符，unicode包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于”半角”英文符号只需要用到低8位，所以其高8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。

 

这时候，从旧社会里走过来的程序员开始发现一个奇怪的现象：他们的 strlen 函数靠不住了，一个汉字不再是相当于两个字符了，而是一个！是的，从unicode开始，无论是半角的英文字母，还是全角的汉字，它们都是统一的”一个字符“！

同时，也都是统一的”两个字节“，请注意”字符”和”字节”两个术语的不同，“字节”是一个8位的物理存贮单元，而“字符”则是一个文化相关的符号。在unicode中，一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。

 

unicode同样也不完美，这里就有两个的问题，一个是，如何才能区别unicode和ascii？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？第二个问题是，我们已经知道，英文字母只用一个字节表示就够了，如果unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储空间来说是极大的浪费，文本文件的大小会因此大出二三倍，这是难以接受的。

 

unicode在很长一段时间内无法推广，直到互联网的出现，为解决unicode如何在网络上传输的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，顾名思义，UTF-8就是每次8个位传输数据，而UTF-16就是每次16个位。UTF-8就是在互联网上使用最广的一种unicode的实现方式，这是为传输而设计的编码，并使编码无国界，这样就可以显示全世界上所有文化的字符了。UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度，当字符在ASCII码的范围时，就用一个字节表示，保留了ASCII字符一个字节的编码做为它的一部分，注意的是unicode一个中文字符占2个字节，而UTF-8一个中文字符占3个字节）。从unicode到utf-8并不是直接的对应，而是要过一些算法和规则来转换。

最高位的 1 的数量表示当前字符占用的字节数。 

 

Unicode符号范围 | UTF-8编码方式

(十六进制) | （二进制）
—————————————————————–
0000 0000-0000 007F | 0xxxxxxx

0000 0080-0000 07FF | 110xxxxx 10xxxxxx

0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

 

最后简单总结一下：

• 中国人民通过对 ASCII 编码的中文扩充改造，产生了 GB2312 编码，可以表示6000多个常用汉字。
• 汉字实在是太多了，包括繁体和各种字符，于是产生了 GBK 编码，它包括了 GB2312 中的编码，同时扩充了很多。
• 中国是个多民族国家，各个民族几乎都有自己独立的语言系统，为了表示那些字符，继续把 GBK 编码扩充为 GB18030 编码。
• 每个国家都像中国一样，把自己的语言编码，于是出现了各种各样的编码，如果你不安装相应的编码，就无法解释相应编码想表达的内容。
• 终于，有个叫 ISO 的组织看不下去了。他们一起创造了一种编码 UNICODE ，这种编码非常大，大到可以容纳世界上任何一个文字和标志。所以只要电脑上有 UNICODE 这种编码系统，无论是全球哪种文字，只需要保存文件的时候，保存成 UNICODE 编码就可以被其他电脑正常解释。
• UNICODE 在网络传输中，出现了两个标准 UTF-8 和 UTF-16，分别每次传输 8个位和 16个位。于是就会有人产生疑问，UTF-8 既然能保存那么多文字、符号，为什么国内还有这么多使用 GBK 等编码的人？因为 UTF-8 等编码体积比较大，占电脑空间比较多，如果面向的使用人群绝大部分都是中国人，用 GBK 等编码也可以。

 

来源于网络，出处实在无法考证，无法署名，有删减修改，如有侵权请直接联系。

可能的原文：unicode,ansi,utf-8,unicode big endian编码的区别，网页编码就是那点事

 

---

 

https://sf-zhou.github.io/programming/chinese_encoding.html

ASCII 码，全称 American Standard Code for Information Interchange，一共规定了 128 个字符的编码，包括 10 个阿拉伯数字（从 0x30 开始）、26 个大写字母（从 65 开始）、26 个小写字母（从 97 开始），33 个英文标点符号，及 32 个控制字符，还有最后一个 0x7F。

128 个字符，至少需要 7 个比特（bit）来表示，而一个字节（byte）有 8 个比特，故将字节的最高位的比特规定为 0，使用剩下的 7 个比特，刚好可以完整的表示 ASCII 码规定的字符。

 

在汉字编码中，之前 ASCII 码没有使用的最高位派上了用场。如果一个字节最高位是 0，说明这个字节便是 ASCII 码，查表解析即可；如果最高位非 0，那么说明这是一个多字节编码，需要联合下一个字节一起进行解析。

不同的编码，也就意味着要查询不同的表，也就会得到不同的解码结果。

Unicode 便是便是文字和符号的统一度量衡。Unicode，Unique Code，Universe Code，全世界每一个字符对应一个唯一的编码。Unicode 收录了大量的汉字，汉字的编码从 0x4E00 开始，到 0x9FFF 结束。  unicode就是个对照表。

https://sf-zhou.github.io/hidden/chinese_unicode_encoding_table.html

 

 然而 Unicode 仅仅定义了符号与二进制编码的关系，但没有定义如何存储和解析这些二进制编码。如果直接将二进制编码写入文件，那么读取时会产生歧义。例如 4E 00 41，你无法知道这记录的是 1 个字符，还是 2 个字符（可以解码为“一A”），或者是 3 个字符（可以解码为“N[空]A”）。如果统一每个字符的记录长度，那么便需要至少 3 个字节来表示一个符号，那么对于全英的文件则太浪费了。

UTF-8 则解决了 Unicode 没有解决的问题。

最高位的 1 的数量表示当前字符占用的字节数。

 

日常使用中可以通过 C++ 中的 cout << "雾失楼台，月迷津渡" << endl;，直接打印得到对应的汉字字符串，是因为代码文件编码和控制台编码显示的编码一致。以 Mac 为例，可以尝试将代码文件的编码切换为 CP939，vim 的话指令为 :e ++enc=utf-8，再尝试编译和运行，就会得到编译器提出的 Warning 及输出的乱码。

直到现在为止，C++ 中获取 UTF-8 编码的字符串字符长度都是一个麻烦的问题，一般需要依赖第三方库。这一点感觉可以借鉴 Python3，将字节流 bytes 和字符串 str 分割开，并提供方便的转换。

目前为止 C++ 没有采用上一节说的方案，而是大力出奇迹，提出使用 wchar_t 解决多字节编码带来的问题。既然多字节计算长度不准确，那就直接使用一个类型代替多字节。目前 UTF-8、Unicode 等编码至多需要 4 个字节，那就直接定义 wchar_t 为 4 个字节，所有问题都可以迎刃而解了。

是的，这不是开玩笑。wchar_t 具体定义为 2 个字节，还是 4 个字节并没有明确规定，视平台而定。

使用宽字符类型可以解决字符串长度计算的问题，但会浪费了大量的存储空间。并且当前的 std::wstring 无法直接使用 std::cout 输出到标准输出流、无法使用 std::ofstream 输出到文件，

而需要使用适配的 std::wcout 和 std::wofstream。综合来看，并不易用。

 

C++ 代码中可以使用 "Hello World" 和 L"Hello World" 来声明字符串和宽字符串常量。C++ 11 开始支持 UTF-8、UTF-16 和 UTF-32 字符串常量的声明，分别使用 u8""、u"" 和 U"" 作为声明的标志

 

 

#include <codecvt>
#include <fstream>
#include <iostream>

int main() {
  const std::locale utf8( std::locale(), new std::codecvt_utf8<wchar_t> );
  const std::wstring love_cpp = L"我爱C++";

  std::wcout.imbue(utf8);
  std::wcout << love_cpp << std::endl;  // 输出 "我爱C++"
  std::wcout << love_cpp.length() << std::endl;  // 输出 5
  std::wcout << love_cpp.substr(0, 2) << std::endl;  // 输出 "我爱"

  const auto k_output_filename = "test_02.txt";
  std::wofstream f_out(k_output_filename, std::ios::out);
  f_out.imbue(utf8);
  f_out << love_cpp << std::endl;
  f_out.close();

  std::wifstream f_in(k_output_filename, std::ios::in);
  f_in.imbue(utf8);
  std::wstring value;
  f_in >> value;
  std::wcout << (value == love_cpp ? "Yes": "Opps") << std::endl;  // 输出 "Yes"
  f_in.close();
}

　　

---

 

linux下用libiconv在utf8和Unicode之间进行转换

 

 

UTF-8是unicode编码的一种落地方案：

Unicode符号范围 | UTF-8编码方式
(十六进制) | （二进制）
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

\x对应的是UTF-8编码的数据，通过转化规则可以转换为Unicode编码，就能得到对应的汉字，转换规则很简单，先将\x去掉，转换为数字，然后进行对应的位移操作即可，需要注意的是先要判断utf-8的位数：

在计算机内存中，统一使用Unicode编码，当需要保存到硬盘或者需要传输的时候，就转换为UTF-8编码。 

>>> "我正在学Python".encode('utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 0: ordinal not in range(128)


>>> u"我正在学Python".encode('utf-8')
'\xe6\x88\x91\xe6\xad\xa3\xe5\x9c\xa8\xe5\xad\xa6Python'


>>> s = "我正在学Python"
>>> s
'\xe6\x88\x91\xe6\xad\xa3\xe5\x9c\xa8\xe5\xad\xa6Python'
>>> s.encode('utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 0: ordinal not in range(128)


>>> '\xe6\x88\x91\xe6\xad\xa3\xe5\x9c\xa8\xe5\xad\xa6Python'.decode('utf-8')
u'\u6211\u6b63\u5728\u5b66Python'
>>> print '\xe6\x88\x91\xe6\xad\xa3\xe5\x9c\xa8\xe5\xad\xa6Python'.decode('utf-8')
我正在学Python

>>> s = "我正在学Python"
>>> s
'\xe6\x88\x91\xe6\xad\xa3\xe5\x9c\xa8\xe5\xad\xa6Python'
>>> s_u = u"我正在学Python"
>>> s_u
u'\u6211\u6b63\u5728\u5b66Python'
>>> print s
我正在学Python
>>> print s_u
我正在学Python

 http://kuanghy.github.io/2017/02/24/python-str-to-unicode-escape

在 Python2 中，有两种类型的字符编码，即 str 和 unicode。而 str 是字节字符串，也就二进制数据；unicode 是文本字符串，是字节序列通过编码后的文本类型。

从上例可以看出，我们直接运行 s 或者 s_u  与  用 print 打印输出是不一样的。

直接运行实际上解释器是调用的 repr 方法，这样的输出表示是计算机可读的形式，也就在 Python 解释器内部是这么存储的；

而用 print 输出的字符串则是人可读的，它的目的就是让人能够读懂。

 

那么，问题就来了，如果你得到这样的字符串：

\xe6\x88\x91\xe6\xad\xa3\xe5\x9c\xa8\xe5\xad\xa6Python

\u6211\u6b63\u5728\u5b66Python

通过肉眼，肯定是没人能直接看出它们是什么东西的。再来看下示例：

>>> ss = "\xe6\x88\x91\xe6\xad\xa3\xe5\x9c\xa8\xe5\xad\xa6Python"
>>> ss
'\xe6\x88\x91\xe6\xad\xa3\xe5\x9c\xa8\xe5\xad\xa6Python'
>>> print ss
我正在学Python
>>> ss_u = "\u6211\u6b63\u5728\u5b66Python"
>>> ss_u
'\\u6211\\u6b63\\u5728\\u5b66Python'
>>> print ss_u
\u6211\u6b63\u5728\u5b66Python

也就是说，\x 开头的这种字符串与直接写中文的字符串是一样的，没有什么区别。因为它是二进制的表示，解释器可以直接表示它，输入中文的时候，解释器内部也是这么存储的。

而 \u开头的字符串解释器则不认识，因为这是一种编码，人们通过约定，用这个编码来表示这个汉字。

通常，我们在网络中接收到的字符串很多都是 \u 开头的，当我们拿到这种字符串的时候，看不出它是些什么东西，是不是很焦虑呢。

实际上，这种字符串可以理解为是一种 escape 编码的字符串，也就是便于网络传输的字符串。

能进行传输的，一般都是 ASCII 字符集，汉字是没法直接传输的，要传输汉字就需要把它转化成 ASCII 字符串。

要怎样才能让 \u 字符串的意思显而易见呢？我们先来分析一下，要看懂它肯定是要做一些编码转换的。首先你要清楚，你现在拿到的用双引号括起来的字符串一个 str 类型，而 str 类型是二进制的。我把这种字符串称之为 转义字符串，也就是通过汉字转义后得到的字符串，这种叫法不一定正确，只是为了便于理解。那么，我们把它转化为文本字符串是不是就可以了呢。从二进制字符串到文件字符，一般被称之为 解码，也就是 decode。这里，我们把它解码为 unicode-escape 编码的字符串：

decode("unicode-escape")

继续上边的例子：

>>> ss_uu = ss_u.decode("unicode-escape")
>>> ss_uu
u'\u6211\u6b63\u5728\u5b66Python'
>>> print ss_uu
我正在学Python

在 Python3 中，则不再会出现这样的问题。Python3 中不再有 str 和 unicode 字符类型的概念，取而代之的是 str 和 bytes 两种字符类型。

str 是编码过的 unicode 文本字符，bytes 是编码前的字节序列。

Python3 在编码的处理上要简单得多，它不再有所谓 unicode 字符串的概念，虽然也兼容 u"" 这样的写法，但这实际上也是一个 str 类型。如示例：

>>> s = "我正在学Python"
>>> s
'我正在学Python'
>>> print(s)
我正在学Python
>>> s_u = u"我正在学Python"
>>> s_u
'我正在学Python'
>>> print(s_u)
我正在学Python
>>> type(s)
<class 'str'>
>>> type(s_u)
<class 'str'>
>>> ss_u = "\u6211\u6b63\u5728\u5b66Python"
>>> ss_u
'我正在学Python'
>>> print(ss_u)
我正在学Python

 

======================================== 

 

 

http://blog.konghy.cn/2017/02/24/python-str-to-unicode-escape/

 

http://www.cnblogs.com/huxi/articles/1897271.html

https://www.liaoxuefeng.com/wiki/001374738125095c955c1e6d8bb493182103fac9270762a000/001386819196283586a37629844456ca7e5a7faa9b94ee8000

 

python一般从数据库中读取的字符串会自动被转换为unicode字符串

 

===============================================================================

由于计算机是美国人发明的，因此，最早只有127个字母被编码到计算机里，也就是大小写英文字母、数字和一些符号，这个编码表被称为ASCII编码，比如大写字母A的编码是65，小写字母z的编码是122。

但是要处理中文显然一个字节是不够的，至少需要两个字节，而且还不能和ASCII编码冲突，所以，中国制定了GB2312编码，用来把中文编进去。

你可以想得到的是，全世界有上百种语言，日本把日文编到Shift_JIS里，韩国把韩文编到Euc-kr里，各国有各国的标准，就会不可避免地出现冲突，结果就是，在多语言混合的文本中，显示出来会有乱码。

因此，Unicode应运而生。Unicode把所有语言都统一到一套编码里，这样就不会再有乱码问题了。

Unicode标准也在不断发展，但最常用的是用两个字节表示一个字符（如果要用到非常偏僻的字符，就需要4个字节）。现代操作系统和大多数编程语言都直接支持Unicode。

现在，捋一捋ASCII编码和Unicode编码的区别：ASCII编码是1个字节，而Unicode编码通常是2个字节。

字母A用ASCII编码是十进制的65，二进制的01000001；

字符0用ASCII编码是十进制的48，二进制的00110000，注意字符'0'和整数0是不同的；

汉字‘中'已经超出了ASCII编码的范围，用Unicode编码是十进制的20013，二进制的01001110 00101101【两个字节】。

你可以猜测，如果把ASCII编码的A用Unicode编码，只需要在前面补0就可以，因此，A的Unicode编码是00000000 01000001【两个字节】。

新的问题又出现了：如果统一成Unicode编码，乱码问题从此消失了。但是，如果你写的文本基本上全部是英文的话，用Unicode编码比ASCII编码需要多一倍的存储空间，在存储和传输上就十分不划算。

所以，本着节约的精神，又出现了把Unicode编码转化为“可变长编码”的UTF-8编码。UTF-8编码把一个Unicode字符根据不同的大小编码成1-6个字节，常用的英文字母被编码成1个字节，汉字通常是3个字节，只有很生僻的字符才会被编码成4-6个字节。

如果你要传输的文本包含大量英文字符，用UTF-8编码就能节省空间

在计算机内存中，统一使用Unicode编码，当需要保存到硬盘或者需要传输的时候，就转换为UTF-8编码。

用记事本编辑的时候，从文件读取的UTF-8字符被转换为Unicode字符到内存里，编辑完成后，保存的时候再把Unicode转换为UTF-8保存到文件：

 

浏览网页的时候，服务器会把动态生成的Unicode内容转换为UTF-8再传输到浏览器：

 

所以你看到很多网页的源码上会有类似<meta charset="UTF-8" />的信息，表示该网页正是用的UTF-8编码。

ASCII(单字节，只能英文) ---> Unicode（所有语言统一，双字节，英文会浪费空间） ---> UTF-8（压缩Unicode，可变 字节表示不同的语言）

 

把unicode的u'xxx'转换为UTF-8编码，用encode('utf-8')方法：

>>> u'ABC'.encode('utf-8')
'ABC'
>>> u'中文'.encode('utf-8')
'\xe4\xb8\xad\xe6\x96\x87'

英文字符转换后表示的UTF-8的值和Unicode值相等（但占用的存储空间不同），而中文字符转换后1个Unicode字符将变为3个UTF-8字符，你看到的\xe4就是其中一个字节，因为它的值是228，没有对应的字母可以显示，所以以十六进制显示字节的数值。len()函数可以返回字符串的长度：

>>> len(u'ABC')
3
>>> len('ABC')
3
>>> len(u'中文')
2
>>> len('\xe4\xb8\xad\xe6\x96\x87')    #\xe4这是utf8的格式
6

反过来，把UTF-8编码表示的字符串'xxx'转换为Unicode字符串u'xxx'， 用decode('utf-8')方法：。

 

 

1. 字符编码简介

1.1. ASCII

ASCII(American Standard Code for Information Interchange)，是一种单字节的编码。计算机世界里一开始只有英文，而单字节可以表示256个不同的字符，可以表示所有的英文字符和许多的控制符号。不过ASCII只用到了其中的一半（\x80以下），这也是MBCS得以实现的基础。

1.2. MBCS

然而计算机世界里很快就有了其他语言，单字节的ASCII已无法满足需求。后来每个语言就制定了一套自己的编码，由于单字节能表示的字符太少，而且同时也需要与ASCII编码保持兼容，所以这些编码纷纷使用了多字节来表示字符，如GBxxx、BIGxxx等等，他们的规则是，如果第一个字节是\x80以下，则仍然表示ASCII字符；而如果是\x80以上，则跟下一个字节一起（共两个字节）表示一个字符，然后跳过下一个字节，继续往下判断。

这里，IBM发明了一个叫Code Page的概念，将这些编码都收入囊中并分配页码，GBK是第936页，也就是CP936。所以，也可以使用CP936表示GBK。

MBCS(Multi-Byte Character Set)是这些编码的统称。目前为止大家都是用了双字节，所以有时候也叫做DBCS(Double-Byte Character Set)。必须明确的是，MBCS并不是某一种特定的编码（而是一个多字节编码的统称），Windows里根据你设定的区域不同，MBCS指代不同的编码，而Linux里无法使用MBCS作为编码。在Windows中你看不到MBCS这几个字符，因为微软为了更加洋气，使用了ANSI来吓唬人，记事本的另存为对话框里编码ANSI就是MBCS。同时，在简体中文Windows默认的区域设定里，指代GBK。

1.3. Unicode

后来，有人开始觉得太多编码导致世界变得过于复杂了，让人脑袋疼，于是大家坐在一起拍脑袋想出来一个方法：所有语言的字符都用同一种字符集来表示，这就是Unicode。

最初的Unicode标准UCS-2使用两个字节表示一个字符，所以你常常可以听到Unicode使用两个字节表示一个字符的说法。但过了不久有人觉得256*256太少了，还是不够用，于是出现了UCS-4标准，它使用4个字节表示一个字符，不过我们用的最多的仍然是UCS-2。

UCS(Unicode Character Set)还仅仅是字符对应码位的一张表而已，比如"汉"这个字的码位是6C49。字符具体如何传输和储存则是由UTF(UCS Transformation Format)来负责。

一开始这事很简单，直接使用UCS的码位来保存，这就是UTF-16，比如，"汉"直接使用\x6C\x49保存(UTF-16-BE)，或是倒过来使用\x49\x6C保存(UTF-16-LE)。

但用着用着美国人觉得自己吃了大亏，以前英文字母只需要一个字节就能保存了，现在大锅饭一吃变成了两个字节，空间消耗大了一倍……于是UTF-8横空出世。

UTF-8是一种很别扭的编码，具体表现在他是变长的，并且兼容ASCII，ASCII字符使用1字节表示。然而这里省了的必定是从别的地方抠出来的，你肯定也听说过UTF-8里中文字符使用3个字节来保存吧？4个字节保存的字符更是在泪奔……（具体UCS-2是怎么变成UTF-8的请自行搜索）

另外值得一提的是BOM(Byte Order Mark)。我们在储存文件时，文件使用的编码并没有保存，打开时则需要我们记住原先保存时使用的编码并使用这个编码打开，这样一来就产生了许多麻烦。（你可能想说记事本打开文件时并没有让选编码？不妨先打开记事本再使用文件 -> 打开看看）

而UTF则引入了BOM来表示自身编码，如果一开始读入的几个字节是其中之一，则代表接下来要读取的文字使用的编码是相应的编码：

BOM_UTF8 '\xef\xbb\xbf' 
BOM_UTF16_LE '\xff\xfe' 
BOM_UTF16_BE '\xfe\xff'

 

并不是所有的编辑器都会写入BOM，但即使没有BOM，Unicode还是可以读取的，只是像MBCS的编码一样，需要另行指定具体的编码，否则解码将会失败。

你可能听说过UTF-8不需要BOM，这种说法是不对的，只是绝大多数编辑器在没有BOM时都是以UTF-8作为默认编码读取。即使是保存时默认使用ANSI(MBCS)的记事本，在读取文件时也是先使用UTF-8测试编码，如果可以成功解码，则使用UTF-8解码。记事本这个别扭的做法造成了一个BUG：如果你新建文本文件并输入"姹塧"然后使用ANSI(MBCS)保存，再打开就会变成"汉a"，你不妨试试 ：）

2. Python2.x中的编码问题

2.1. str和unicode

str和unicode都是basestring的子类。严格意义上说，str其实是字节串，它是unicode经过编码后的字节组成的序列。对UTF-8编码的str'汉'使用len()函数时，结果是3，因为实际上，UTF-8编码的'汉' == '\xE6\xB1\x89'。

unicode才是真正意义上的字符串，对字节串str使用正确的字符编码进行解码后获得，并且len(u'汉') == 1。

再来看看encode()和decode()两个basestring的实例方法，理解了str和unicode的区别后，这两个方法就不会再混淆了：

# coding: UTF-8 

t = 'hi'                 #str

u = u'汉'    #unicode

print repr(u) # u'\u6c49'

s = u.encode('UTF-8')         //对uinicode字符串进行编码，编码成字节串str

print repr(s) # '\xe6\xb1\x89'

u2 = s.decode('UTF-8')        //对str的字节码进行解码，解码成字符串

print repr(u2) # u'\u6c49'

 

# 对unicode进行解码是错误的

# s2 = u.decode('UTF-8')

# 同样，对str进行编码也是错误的

# u2 = s.encode('UTF-8')

 

 

Python 有办法将任意值转为字符串：将它传入repr() 或str() 函数。

函数str() 用于将值转化为适于人阅读的形式，而repr() 转化为供解释器读取的形式

str()出来的值是给人看的。。。repr()出来的值是给python看的，可以通过eval()重新变回一个Python对象

 

需要注意的是，虽然对str调用encode()方法是错误的，但实际上Python不会抛出异常，而是返回另外一个相同内容但不同id的str；对unicode调用decode()方法也是这样。

很不理解为什么不把encode()和decode()分别放在unicode和str中而是都放在basestring中，但既然已经这样了，我们就小心避免犯错吧。

unicode只有encode()方法

str只有decode()方法

2.2. 字符编码声明

源代码文件中，如果有用到非ASCII字符（ASCII:单字节编码），则需要在文件头部进行字符编码的声明，如下：

#-*- coding: UTF-8 -*-

实际上Python只检查#、coding和编码字符串，其他的字符都是为了美观加上的。另外，Python中可用的字符编码有很多，并且还有许多别名，还不区分大小写，比如UTF-8可以写成u8。参见http://docs.python.org/library/codecs.html#standard-encodings。

另外需要注意的是声明的编码必须与文件实际保存时用的编码一致，否则很大几率会出现代码解析异常。现在的IDE一般会自动处理这种情况，改变声明后同时换成声明的编码保存，但文本编辑器控们需要小心 ：）

2.3. 读写文件

内置的open()方法打开文件时，read()读取的是str(字节码)，读取后需要使用正确的编码格式进行decode()。

write()写入时，如果参数是unicode(字符串)，则需要使用你希望写入的编码进行encode()，如果是其他编码格式的str，则需要先用该str的编码进行decode()，转成unicode后再使用写入的编码进行encode()。

如果直接将unicode作为参数传入write()方法，Python将先使用源代码文件声明的字符编码进行编码然后写入。

# coding: UTF-8

 

f = open('test.txt')

s = f.read()

f.close()

print type(s) # <type 'str'>    str:字节

# 已知是GBK编码，解码成unicode  

u = s.decode('GBK')        //对字节进行解码

 

f = open('test.txt', 'w')

# 编码成UTF-8编码的str

s = u.encode('UTF-8')

f.write(s)

f.close()

另外，模块codecs提供了一个open()方法，可以指定一个编码打开文件，使用这个方法打开的文件读取返回的将是unicode。写入时，如果参数是unicode，则使用open()时指定的编码进行编码后写入；如果是str，则先根据源代码文件声明的字符编码，解码成unicode后再进行前述操作。相对内置的open()来说，这个方法比较不容易在编码上出现问题。

# coding: GBK
 
import codecs
 
f = codecs.open('test.txt', encoding='UTF-8')
u = f.read()
f.close()
print type(u) # <type 'unicode'>
 
f = codecs.open('test.txt', 'a', encoding='UTF-8')
# 写入unicode
f.write(u)
 
# 写入str，自动进行解码编码操作
# GBK编码的str
s = '汉'
print repr(s) # '\xba\xba'
# 这里会先将GBK编码的str解码为unicode再编码为UTF-8写入
f.write(s) 
f.close()

　　

2.4. 与编码相关的方法

sys/locale模块中提供了一些获取当前环境下的默认编码的方法。

# coding:gbk
 
import sys
import locale
 
def p(f):
    print '%s.%s(): %s' % (f.__module__, f.__name__, f())
 
# 返回当前系统所使用的默认字符编码
p(sys.getdefaultencoding)
 
# 返回用于转换Unicode文件名至系统文件名所使用的编码
p(sys.getfilesystemencoding)
 
# 获取默认的区域设置并返回元祖(语言, 编码)
p(locale.getdefaultlocale)
 
# 返回用户设定的文本数据编码
# 文档提到this function only returns a guess
p(locale.getpreferredencoding)
 
# \xba\xba是'汉'的GBK编码
# mbcs是不推荐使用的编码，这里仅作测试表明为什么不应该用
print r"'\xba\xba'.decode('mbcs'):", repr('\xba\xba'.decode('mbcs'))
 
#在笔者的Windows上的结果(区域设置为中文(简体, 中国))
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp936')
#locale.getpreferredencoding(): cp936
#'\xba\xba'.decode('mbcs'): u'\u6c49'

　　

3.一些建议

3.1. 使用字符编码声明，并且同一工程中的所有源代码文件使用相同的字符编码声明。

这点是一定要做到的。

3.2. 抛弃str，全部使用unicode。

按引号前先按一下u最初做起来确实很不习惯而且经常会忘记再跑回去补，但如果这么做可以减少90%的编码问题。如果编码困扰不严重，可以不参考此条。

3.3. 使用codecs.open()替代内置的open()。

如果编码困扰不严重，可以不参考此条。

3.4. 绝对需要避免使用的字符编码：MBCS/DBCS和UTF-16。

这里说的MBCS不是指GBK什么的都不能用，而是不要使用Python里名为'MBCS'的编码，除非程序完全不移植。

Python中编码'MBCS'与'DBCS'是同义词，指当前Windows环境中MBCS指代的编码。Linux的Python实现中没有这种编码，所以一旦移植到Linux一定会出现异常！另外，只要设定的Windows系统区域不同，MBCS指代的编码也是不一样的。分别设定不同的区域运行2.4小节中的代码的结果：

中文(简体, 中国)
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp936')
#locale.getpreferredencoding(): cp936
#'\xba\xba'.decode('mbcs'): u'\u6c49'
 
#英语(美国)
#sys.getdefaultencoding(): UTF-8
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp1252')
#locale.getpreferredencoding(): cp1252
#'\xba\xba'.decode('mbcs'): u'\xba\xba'
 
#德语(德国)
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp1252')
#locale.getpreferredencoding(): cp1252
#'\xba\xba'.decode('mbcs'): u'\xba\xba'
 
#日语(日本)
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp932')
#locale.getpreferredencoding(): cp932
#'\xba\xba'.decode('mbcs'): u'\uff7a\uff7a'

　　

可见，更改区域后，使用mbcs解码得到了不正确的结果，所以，当我们需要使用'GBK'时，应该直接写'GBK'，不要写成'MBCS'。

UTF-16同理，虽然绝大多数操作系统中'UTF-16'是'UTF-16-LE'的同义词，但直接写'UTF-16-LE'只是多写3个字符而已，而万一某个操作系统中'UTF-16'变成了'UTF-16-BE'的同义词，就会有错误的结果。实际上，UTF-16用的相当少，但用到的时候还是需要注意。

--END--

============================================

http://www.cnblogs.com/yyxayz/p/4044528.html

中文编码问题是用中文的程序员经常头大的问题，在python下也是如此，那么应该怎么理解和解决python的编码问题呢？

我们要知道python内部使用的是unicode编码，而外部却要面对千奇百怪的各种编码，比如作为中国程序经常要面对的gbk，gb2312，utf8等，那这些编码是怎么转换成内部的unicode呢？

首先我们先看一下源代码文件中使用字符串的情况。源代码文件作为文本文件就必然是以某种编码形式存储代码的，python默认会认为源代码文件是asci编码，比如说代码中有一个变量赋值：

s1=’a’ 
print s1

python认为这个’a'就是一个asci编码的字符。在仅仅使用英文字符的情况下一切正常，但是如果用了中文，比如：

s1=’哈’ 
print s1

这个代码文件被执行时就会出错，就是编码出了问题。python默认将代码文件内容当作asci编码处理，但asci编码中不存在中文，因此抛出异常。

解决问题之道就是要让python知道文件中使用的是什么编码形式，对于中文，可以用的常见编码有utf-8，gbk和gb2312等。只需在代码文件的最前端添加如下：

# -*- coding: utf-8 -*-

这就是告知python我这个文件里的文本是用utf-8编码的，这样，python就会依照utf-8的编码形式解读其中的字符，然后转换成unicode编码内部处理使用。

不过，如果你在Windows控制台下运行此代码的话，虽然程序是执行了，但屏幕上打印出的却不是哈字。这是由于python编码与控制台编码的不一致造成的。Windows下控制台中的编码使用的

是gbk，而在代码中使用的utf-8，python按照utf-8编码打印到gbk编码的控制台下自然就会不一致而不能打印出正确的汉字。

解决办法一个是将源代码的编码也改成gbk，也就是代码第一行改成：

# -*- coding: gbk -*-

另一种方法是保持源码文件的utf-8不变，而是在’哈’前面加个u字，也就是:

s1=u’哈’ 
print s1

这样就可以正确打印出’哈’字了。

这里的这个u表示将后面跟的字符串以unicode格式存储。python会根据代码第一行标称的utf-8编码识别代码中的汉字’哈’，然后转换成unicode对象。如果我们用type查看一下’哈’的数据类

型type(‘哈’)，会得到<type ‘str’>，而type(u’哈’)，则会得到<type ‘unicode’>，也就是在字符前面加u就表明这是一个unicode对象，这个字会以unicode格式存在于内存中，而如果不加u

，表明这仅仅是一个使用某种编码的字节串，编码格式取决于python对源码文件编码的识别，这里就是utf-8。

Python在向控制台输出unicode对象的时候会自动根据输出环境的编码进行转换，但如果输出的不是unicode对象而是普通字符串，则会直接按照字符串的编码输出字符串，从而出现上面的现

象。

使用unicode对象的话，除了这样使用u标记，还可以使用unicode类以及字符串的encode和decode方法。

unicode类的构造函数接受一个字符串参数和一个编码参数，将字符串封装为一个unicode，比如在这里，由于我们用的是utf-8编码，所以unicode中的编码参数使用’utf-8′将字符封装为

unicode对象，然后正确输出到控制台：

s1=unicode(‘哈’, ‘utf-8′) 
print s1

另外，用decode函数也可以将一个普通字符串转换为unicode对象。很多人都搞不明白python字符串的decode和encode函数都是什么意思。这里简要说明一下。

decode是将普通字符串按照参数中的编码格式进行解析，然后生成对应的unicode对象，比如在这里我们代码用的是utf-8，那么把一个字符串转换为unicode就是如下形式：

s2=’哈’.decode(‘utf-8′)

这时，s2就是一个存储了’哈’字的unicode对象，其实就和unicode(‘哈’, ‘utf-8′)以及u’哈’是相同的。

那么encode正好就是相反的功能，是将一个unicode对象转换为参数中编码格式的普通字符，比如下面代码：

s3=unicode(‘哈’, ‘utf-8′).encode(‘utf-8′)

s3现在又变回了utf-8的’哈’。

=============================

我们都知道计算机只能处理数字，文本转换为数字才能处理。计算机中8个bit作为一个字节，所以一个字节能表示最大的数字就是255。计算机是美国人发明的，而英文中涉及的编码并不多，一个字节可以表示所有字符了，所以ASCII（American national Standard Code for Information Interchange，美国国家标准信息交换码）编码就成为美国人的标准编码。但是我们都知道中文的字符肯定不止255个汉字，使用ASCII编码来处理中文显然是不够的，所以中国制定了GB2312编码，用两个字节表示一个汉字，碰到及其特殊的情况，还会用三个字节来表示一个汉字。GB2312还把ASCII包含进去了。同理，日文，韩文等上百个国家为了解决这个问题发展了一套自己的编码，于是乎标准越来越多，如果出现多种语言混合显示就一定会出现乱码。那么针对这种编码“乱象”，Unicode便应运而生了，其将所有语言统一到一套编码规则里。 

 

 

 

Unicode有许多种编码，比如说可以通过16个bit或者32个bit来把所有语言统一到一套编码里。举个栗子，字母A用ASCII编码的十进制为65，二进制为0100 0001；汉字“中”已经超出了ASCII编码的范围，用unicode编码是20013，二进制是01001110 00101101；A用unicode编码只需要前面补0，二进制是00000000 0100 0001。可以看出，unicode不仅解决了ASCII码本身的编码问题，还解决了超出ASCII编码范围之外的其他国家字符编码的统一问题。

 

 

虽然unicode编码能做到将不同国家的字符进行统一，使得乱码问题得以解决，但是如果内容全是英文unicode编码比ASCII编码需要多一倍的存储空间，同时如果传输需要多一倍的传输。当传输文件比较小的时候，内存资源和网络带宽尚能承受，当文件传输达到上TB的时候，如果 “硬”传，则需要消耗的资源就不可小觑了。为了解决这个问题，一种可变长的编码“utf-8”就应运而生了，把英文变长1个字节，汉字3个字节，特别生僻的变成4-6个字节，如果传输大量的英文，utf8的作用就很明显了。

 

不过正是因为utf-8编码的可变长，一会儿一个字符串是占用一个字节，一会儿一个字符串占用两个字节，还有的占用三个及以上的字节，导致在内存中或者程序中变得不好琢磨。

unicode编码虽然占用内存空间，但是在编程过程中或者在内存处理的时候会比utf-8编码更为简单，因为它始终保持一样的长度，一样的长度对于内存和代码来说，它的处理就会变得更加简单。

所以utf-8编码被用于网络传输和文件保存【节省空间】，将内存的unicode编码转换成utf-8编码，才能更好的发挥其作用；

当从文件中读取数据到内存中的时候，将utf-8编码转换为unicode编码，亦为良策。

 

 

如上图所示，当需要在内存中读取文件的时候，此时将utf-8编码的内存转换为unicode编码，在内存中进行统一处理；

当需要保存文件的时候，出于空间和传输效率的考虑，此时将unicode编码转换为utf-8编码。

在Python中进行读取和保存文件的时候，必须要显示的指定文件编码，其余的事情就交给Python的相关库去处理就可以了。

 

---

 

>>> f = open('out.txt')
>>> s = f.read()
>>> f.close()
>>> print s

CThostFtdcRspInfoField:
0
▒▒ȷ

>>> u =s.decode('GBK')
>>> u
u'\nCThostFtdcRspInfoField:\n0\n\u6b63\u786e\n'

 

>>> print u

CThostFtdcRspInfoField:
0
正确

所以在网络上传输，本地保存的是utf-8，如果里面包含中文，就就得把utf-8转成对应的中文编码格式，例如GBK，

但转成GBK之后，直接打印还是不行的，得用能支持中文输出的函数例如wcout。

python的print函数可以直接输出中文