标签：unicode 中国人 空间换时间 表示 文本编辑 定制 png not 选择
字符编码与文件处理
一 了解字符编码的储备知识
python解释器和文件本编辑的异同
相同点：python解释器是解释执行文件内容的，因而python解释器具备读py文件的功能，这一点与文本编辑器一样
不同点：文本编辑器将文件内容读入内存后，是为了显示/编辑，而python解释器将文件内容读入内存后，是为了执行（识别python语法）
二 什么是字符编码
所谓的字符编码就是让计算机读懂人类的字符
必须经过一个过程：
字符--------（翻译过程）------->数字
这个过程实际就是一个字符如何对应一个特定数字的标准，这个标准称之为字符编码
以下两个场景下涉及到字符编码的问题：
1. 一个python文件中的内容是由一堆字符组成的（python文件未执行时）
2. python中的数据类型字符串是由一串字符组成的（python文件执行时）
三 字符编码发展史
阶段一：现代计算机起源于美国，最早诞生也是基于英文考虑的ASCII
阶段二:为了满足中文，中国人定制了GBK（其他各国为了满足各国的发展需求纷纷制定了自己的字符编码）
阶段三：各国有各国的标准，就会不可避免地出现冲突，结果就是，在多语言混合的文本中，显示出来会有乱码。
于是产生了unicode， 统一用2Bytes代表一个字符， 2**16-1=65535，可代表6万多个字符，因而兼容万国语言
但对于通篇都是英文的文本来说，这种编码方式无疑是多了一倍的存储空间（二进制最终都是以电或者磁的方式存储到存储介质中的）
于是产生了UTF-8，对英文字符只用1Bytes表示，对中文字符用3Bytes。unicode 和UTF-8各有优劣
unicode：简单粗暴，所有字符都是2Bytes，优点是字符->数字的转换速度快，缺点是占用空间大
utf-8：精准，对不同的字符用不同的长度表示，优点是节省空间，缺点是：字符->数字的转换速度慢，因为每次都需要计算出字符需要多长的Bytes才能够准确表示
**** 所有程序，最终都要加载到内存，程序保存到硬盘不同的国家用不同的编码格式，但是到内存中我们为了兼容万国（计算机可以运行任何国家的程序原因在于此），统一且固定使用unicode，这就是为何内存固定用unicode的原因，你可能会说兼容万国我可以用utf－8啊，可以，完全可以正常工作，之所以不用肯定是unicode比utf－8更高效啊（uicode固定用2个字节编码，utf－8则需要计算），但是unicode更浪费空间，没错，这就是用空间换时间的一种做法，而存放到硬盘，或者网络传输，都需要把unicode转成utf－8，因为数据的传输，追求的是稳定，高效，数据量越小数据传输就越靠谱，于是都转成utf－8格式的，而不是unicode。
四 字符编码的使用
文本编译器（以notepadd++为例）
当我们用编译器编译一段对我们有用的信息并且关闭之后 当我们需要的时候打开之后却发现所编译的内容和之前的完全不一样了 会出现大量的乱码。那么为什么会有乱码呢？
一 存文件时就已经乱码
存文件时，由于文件内有各个国家的文字，我们单以shiftjis去存，
本质上其他国家的文字由于在shiftjis中没有找到对应关系而导致存储失败，用open函数的write可以测试，f=open(‘a.txt‘,‘w‘,encodig=‘shift_jis‘)
f.write(‘你瞅啥\n何を見て\n‘) #‘你瞅啥‘因为在shiftjis中没有找到对应关系而无法保存成功，只存‘何を見て\n‘可以成功
但当我们用文件编辑器去存的时候，编辑器会帮我们做转换，保证中文也能用shiftjis存储（硬存，必然乱码），这就导致了，存文件阶段就已经发生乱码
此时当我们用shiftjis打开文件时，日文可以正常显示，而中文则乱码了
二 存文件时不乱码而读文件时乱码
存文件时用utf-8编码，保证兼容万国，不会乱码，而读文件时选择了错误的解码方式，比如gbk，则在读阶段发生乱码，读阶段发生乱码是可以解决的，选对正确的解码方式就ok了，而存文件时乱码，则是一种数据的损坏。
怎么防止乱码出现？
无论是何种编辑器，要防止文件出现乱码（请一定注意，存放一段代码的文件也仅仅只是一个普通文件而已，此处指的是文件没有执行前，我们打开文件时出现的乱码）
核心法则就是，文件以什么编码保存的，就以什么编码方式打开
标签：unicode 中国人 空间换时间 表示 文本编辑 定制 png not 选择
原文地址：http://www.cnblogs.com/bypp/p/7230904.html
