最近开始从零基础学习python语言，安装配置好开发环境后打算先写个“hello word”验证是否配置成功。
发现问题
Python属于解释型脚本语言，可直接执行目标代码。于是乎，写了下面一行代码：
print "Hello python!你好python！"
运行脚本，没有出现预期的输出，而是报出一个参数错误的提示：
SyntaxError: Non-ASCII character '\xe4' in file G:\Eclipse\workspace\MyPy1\src\Test1\__init__.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
这是为什么呢？如此简单的一个脚本，如此出师不利！
顺藤摸瓜，从报错信息着手排查问题。经过查询，原来问题出在脚本中的中文字符。要想搞清楚这个问题，还得从字符集和字符编码说起。
分析原因
在介绍字符集之前，我们先了解下为什么要有字符集。我们在屏幕上能看到的是实体化的文字，而在计算机存储介质中存放的实际是二进制的比特流。那么在这两者之间的转换规则就需要一个统一的标准，否则把我们的U盘插到其他电脑上，文档就乱码了；小伙伴QQ上传过来的文件，在我们本地打开又乱码了。于是为了实现转换标准，各种字符集标准就出现了。简单的说字符集就是规定了某个文字对应的二进制数值（编码）和某串二进制数值代表了哪个文字（解码）的转换关系。
那么为什么会有那么多字符集标准呢？这个问题实际是因为很多规范和标准在最初制定时并不会意识到这将会是以后全球普适的准则，或者处于组织本身利益就想从本质上区别于现有标准。于是，就产生了那么多具有相同效果但又不相互兼容的标准了。
举个例子，以下是“编”这个汉字在不同字符编码下的十六进制和二进制对比结果：
字符编码 十六进制编码 二进制
UTF-8 E7BC96 111001111011110010010110
ANSI B1E0 1011000111100000
Unicode 7F16 111111100010110
字符集只是一个规则集合的名字，对应到真实生活中，字符集就是对某种语言的称呼。例如：英语，汉语，日语。对于一个字符集来说要正确编码转码一个字符需要三个关键元素：字库表（character repertoire）、编码字符集（coded character set）、字符编码（character encoding form）。其中字库表是一个相当于所有可读或者可显示字符的数据库，字库表决定了整个字符集能够展现表示的所有字符的范围。编码字符集，即用一个编码值code point来表示一个字符在字库中的位置。字符编码，将编码字符集和实际存储数值之间的转换关系。一般来说都会直接将code point的值作为编码后的值直接存储。例如在ASCII中A在表中排第65位，而编码后A的数值是0100 0001也即十进制的65的二进制转换结果。
字库表和编码字符集看来是必不可少的，那既然字库表中的每一个字符都有一个自己的序号，直接把序号作为存储内容就好了。为什么还要多此一举通过字符编码把序号转换成另外一种存储格式呢？
统一字库表的目的是为了能够涵盖世界上所有的字符，但实际使用过程中会发现真正用的上的字符相对整个字库表来说比例非常低。例如中文地区的程序几乎不会需要日语字符，而一些英语国家甚至简单的ASCII字库表就能满足基本需求。而如果把每个字符都用字库表中的序号来存储的话，每个字符就需要3个字节（这里以Unicode字库为例），这样对于原本用仅占一个字符的ASCII编码的英语地区国家显然是一个额外成本（存储体积是原来的三倍）。算的直接一些，同样一块硬盘，用ASCII可以存1500篇文章，而用3字节Unicode序号存储只能存500篇。于是就出现了UTF-8这样的变长编码。在UTF-8编码中原本只需要一个字节的ASCII字符，仍然只占一个字节。而像中文及日语这样的复杂字符就需要2个到3个字节来存储。
解决问题
编码和解码时用了不同或者不兼容的字符集。对应到真实生活中，就像是一个英国人为了表示祝福在纸上写了bless（编码过程）。而一个法国人拿到了这张纸，由于在法语中bless表示受伤的意思，所以认为他想表达的是受伤（解码过程）。这个就是一个现实生活中的乱码情况。在计算机科学中一样，一个用UTF-8编码后的字符，用GBK去解码。由于两个字符集的字库表不一样，同一个汉字在两个字符表的位置也不同，最终就会出现乱码。
而python默认使用ASCII字符编码（只有1个字节的编码，最大支持256个字符），这个编码格式中不包含中文，所以造成了在执行过程中出现无法解码的错误。
解决办法很简单，只要在代码最前面声明当前代码中出现的字符能正常使用的字符编码方式即可。
#-*- coding: utf-8 -*-
1
#-*- coding: utf-8 -*-
加上之后，脚本运行正常啦！
扩展延伸
以UTF-8编码方式为例，介绍一下这种在互联网上使用最广的Unicode的字符编码。其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。这里的UTF-8是Unicode的实现方式之一。
UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。
UTF-8的编码规则很简单：
对于单字节的符号，字节的第一位设为0，后面7位为这个符号的Unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。
对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位都置为10。剩下的没有提及的二进制位，全部为这个符号的Unicode码。
下表总结了编码规则，字母x表示可用编码的位。
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
以汉字“严”为例，如何利用上述编码规格进行UTF-8编码。
已知“严”的Unicode是4E25（100111000100101），根据上表，可以发现4E25处在第三行的范围内（0000 0800-0000 FFFF），因此“严”的UTF-8编码需要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，“严”的UTF-8编码是“11100100 10111000 10100101”，转换成十六进制就是E4B8A5。
大家会发现，为什么采用UTF-8编码后反而比Unicode多了一个字节？为何不直接用Unicode保存？
如果用直接用Unicode表示字符，就会存在两个较为严重的问题：
如何才能区别Unicode和ASCII？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？
我们已经知道，英文字母只用一个字节表示就够了，如果Unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。