但是对于UTF-32和UTF-16编码方式还有一些其他不明显的缺点。不同的计算机系统会以不同的顺序保存字节。这意味着字符U+4E2D在UTF-16编码方式下可能被保存为4E 2D或者2D 4E，这取决于该系统使用的是大尾端(big-endian)还是小尾端(little-endian)。（对于UTF-32编码方式，则有更多种可能的字节排列。）只要文档没有离开你的计算机，它还是安全的 -- 同一台电脑上的不同程序使用相同的字节顺序(byte order)。但是当我们需要在系统之间传输这个文档的时候，也许在万维网中，我们就需要一种方法来指示当前我们的字节是怎样存储的。不然的话，接收文档的计算机就无法知道这两个字节4E 2D表达的到底是U+4E2D还是U+2D4E。

为了解决这个问题，多字节的Unicode编???方式定义了一个字节顺序标记(Byte Order Mark)，它是一个特殊的非打印字符，你可以把它包含在文档的开头来指示你所使用的字节顺序。对于UTF-16，字节顺序标记是U+FEFF。如果收到一个以字节FF FE开头的UTF-16编码的文档，你就能确定它的字节顺序是单向的(one way)的了；如果它以FE FF开头，则可以确定字节顺序反向了。

不过，UTF-16还不够完美，特别是要处理许多ASCII字符时。如果仔细想想的话，甚至一个中文网页也会包含许多的ASCII字符 -- 所有包围在可打印中文字符周围的元素(element)和属性(attribute)。能够在常数时间内找到第Nth个字符当然非常好，但是依然存在着纠缠不休的星芒层字符的问题，这意味着你不能保证每个字符都是2个字节长，所以，除非你维护着另外一个索引，不然就不能真正意义上的在常数时间内定位第N个字符。另外，朋友，世界上肯定还存在很多的ASCII文本…

另外一些人琢磨着这些问题，他们找到了一种解决方法：

UTF-8

UTF-8是一种为Unicode设计的变长(variable-length)编码系统。即，不同的字符可使用不同数量的字节编码。对于ASCII字符(A-Z,&c.)UTF-8仅使用1个字节来编码。事实上，UTF-8中前128个字符(0–127)使用的是跟ASCII一样的编码方式。像ñ和ö这样的扩展拉丁字符(Extended Latin)则使用2个字节来编码。（这里的字节并不是像UTF-16中那样简单的Unicode编码点(unicode code point)；它使用了一些位变换(bit-twiddling)。）中文字符比如则占用了3个字节。很少使用的星芒层字符则占用4个字节。

缺点：因为每个字符使用不同数量的字节编码，所以寻找串中第N个字符是一个O(N)复杂度的操作 -- 即，串越长，则需要更多的时间来定位特定的字符。同时，还需要位变换来把字符编码成字节，把字节解码成字符。

优点：在处理经常会用到的ASCII字符方面非常有效。在处理扩展的拉丁字符集方面也不比UTF-16差。对于中文字符来说，比UTF-32要好。同时，（在这一条上你得相信我，因为我不打算给你展示它的数学原理。）由位操作的天性使然，使用UTF-8不再存在字节顺序的问题了。一份以UTF-8编码的文档在不同的计算机之间是一样的比特流。

?

?

?

Python 3会假定我们的源码 -- 即.py文件 -- 使用的是UTF-8编码方式。

Python 2里，.py文件默认的编码方式为ASCII。Python 3的源码的默认编码方式为UTF-8

如果想使用一种不同的编码方式来保存Python代码，我们可以在每个文件的第一行放置编码声明(encoding declaration)。以下声明定义.py文件使用windows-1252编码方式：

从技术上说，字符编码的重载声明也可以放在第二行，如果第一行被类UNIX系统中的hash-bang命令占用了。

了解更多信息，请参阅PEP263: 指定Python源码的编码方式。

在Python 3，所有的字符串都是使用Unicode编码的字符序列。不再存在以UTF-8或者CP-1252编码的情况。也就是说，这个字符串是以UTF-8编码的吗？不再是一个有效问题。UTF-8是一种将字符编码成字节序列的方式。如果需要将字符串转换成特定编码的字节序列，Python 3可以为你做到。如果需要将一个字节序列转换成字符串，Python 3也能为你做到。字节即字节，并非字符。字符在计算机内只是一种抽象。字符串则是一种抽象的序列。

?