我以三种不同的形式编辑三个具有相同内容“你”（you英文）的文件——gbk\utf-8\ucs-2，gedit 名为“ok1,ok2,ok3”。
>>> f1 = open('ok1', 'rb').read()
>>> f2 = open('ok2', 'rb').read()
>>> f3 = open('ok3', 'rb').read()
>>> f1
'\xc4\xe3\n'
>>> f2
'\xe4\xbd\xa0\n'
>>> f3
'`O\n\x00'
>>> hex(ord("`"))
'0x60'
>>> hex(ord("O"))
'0x4f'
实际上 f3 是 '\x60\x4f'，但是下面的输出让我很困惑
>>> '\xe4\xbd\xa0'.decode("utf-8")
u'\u4f60'
>>> '\xc4\xe3'.decode("gbk")
u'\u4f60'
>>>
为什么在ucs-2（或说unicode）中只有字节序问题，而不是utf-8，而不是gbk？
UTF-8和GBK以字节序列存储数据。在这些编码中，强烈定义了哪个字节值在哪个之后。此字节顺序不会随着编码、传输或解码中使用的架构而改变。
另一方面，UCS-2或新的UTF-16以 2 字节序列存储数据。这些 2 字节令牌中各个字节的顺序是字节序，它取决于底层机器架构。在与UCS-2中编码的数据进行通信之前，系统必须就如何识别令牌的字节顺序达成一致。
在您的情况下，Unicode 点 U+4F60 在UCS-2中编码为单个 2-byte token 0x4F60。由于您的机器在内存对齐中将最低有效字节放在最高有效字节之前，因此('0x60', '0x4F')已将序列放入文件中。因此，文件读取将按此顺序产生字节。
Python 仍然可以正确解码这些数据，因为它会在形成 2 字节标记之前以正确的顺序读取字节：
>>> '`O\n\x00'.decode('utf-16')
u'\u4f60\n'
Endian-ness 仅适用于多字节字，但 UTF-8 使用 8 位单位来编码信息（这就是名称中的 8 所代表的意思）。那里从来没有订购混乱的问题。
有时它可能需要多个单元来编码信息，但它们被认为是不同的。例如，字母A是一个字节0x41。当它必须用更多字节编码一个字符时，它使用一个前导指示字节，然后是额外的连续字节来捕获该字符所需的所有信息。从逻辑上讲，这些是不同的单位。
GBK采用了类似的方案；字符使用 1 个字节为单位，就像 UTF-8 一样，第二个字节可用于某些字符。
另一方面，UCS-2（以及它的后继者 UTF-16）是一种 2 字节格式。它以 16 位为单位对信息进行编码，而这 16 位总是在一起。该单元中的 2 个字节在逻辑上属于一起，现代架构将它们视为一个单元，因此决定了它们的存储顺序。这就是字节序出现的地方，一个单元中 2 个字节的顺序取决于架构。在您的体系结构中，字节是使用小端序排列的，这意味着“较小的”字节首先出现。这就是为什么字节在文件中的0x4F字节之前出现的原因0x60。
请注意，python 可以很好地读取大端或小端 UTF-16；如果开头没有指示符（字节顺序标记或 BOM），您可以显式选择字节顺序：
>>> '`O\n\x00'.decode('utf-16')
u'\u4f60\n'
>>> '`O\n\x00'.decode('utf-16-le')
u'\u4f60\n'
>>> 'O`\x00\n'.decode('utf-16-be')
u'\u4f60\n'
在后一个示例中，字节已被反转，并被解码为大端。