我相信，每个写Python的哥们，都曾被那个红色的UnicodeDecodeError搞得百爪挠心过。真的，那感觉就像大半夜代码跑得好好的，突然一个鬼影闪过，屏幕上甩给你一串看不懂的错误，然后整个程序就瘫了。这玩意儿，就是个幽灵，一个盘旋在无数Python项目上空的编码幽灵。而“python怎么转码”这个问题，说白了，就是咱们如何学会当一个合格的“捉鬼大师”。
别跟我扯什么官方文档，那些东西写得跟法律条文似的，正确，但就是不说人话。今天，我就用大白话，给你把这层窗户纸捅破。
首先，你得在脑子里焊死一个概念：计算机这兄弟，脑子是方的，它只认识 0和1。你给它看的汉字“我”，它不认识；你给它的’A’，它也不认识。所有这些我们人类能看懂的字符，对计算机来说都是天书。要让它能存储、能传输，就必须把这些字符“翻译”成它唯一能懂的语言——二进制字节序列，也就是我们常说的 bytes。
这个“翻译”的过程，就是 编码（Encode）。
反过来，当计算机从硬盘里读出一堆0101，或者从网络上接收到一堆0101，它需要把这些天书“翻译”回来”，变成我们人类能看懂的字符。
这个“翻译回来”的过程，就是 解码（Decode）。
看明白没？一进一出，一个编码，一个解码。这就是所有乱码问题的根源。问题就出在这个“翻译”的规则上。
想象一下，你是个英国人，只会英语。我跟你说了一句中文“你好”。你听不懂，因为你没有“中文-英语”这本翻译词典。编码解码也是一个道理。UTF-8、GBK、ASCII 这些奇奇怪怪的名字，就是不同的“翻译词典”。
ASCII：老古董了，只能翻译英文字母、数字和一些符号，一共128个。遇到中文，它直接傻眼。GBK：中国自己搞的一套标准，专门用来翻译汉字的。一个汉字通常用2个字节表示。很长一段时间里，Windows中文版的默认编码就是它（或者它的超集cp936）。UTF-8：现在的王者，万国码。它牛逼在哪？它能表示地球上几乎所有的字符，而且是可变长度的。英文它用1个字节，跟ASCII一样，省空间；中文它用3个字节。兼容性极好，全世界通用。
现在，核心来了。Python 3 做了个非常伟大的决定，它在内存里，统一使用一种叫 Unicode 的东西来表示所有字符。你可以把 Unicode 想象成“世界语”，是所有语言的“普通话”。我们写的str类型，比如 s = "你好Python"，在Python的内存里，它就是Unicode，它是一种抽象的、理论上的存在，它不对应任何具体的01字节。
所以，Python 3 里的 str 和 bytes 是两种完全不同的东西，泾渭分明！
* str：字符串，是人看的，是内存里那个抽象的、统一的 Unicode 字符。
* bytes：字节串，是机器看的，是硬盘上、网络上实实在在传输的 0101 二进制流。
那么，python怎么转码？答案就是在这两者之间来回横跳！
str → bytes：编码 encode()
这个过程，就是把内存中抽象的Unicode字符，用一本具体的翻译词典（比如UTF-8），翻译成实实在在的二进制字节。
“`python
这是一个Unicode字符串，是抽象的
my_str = “你好，世界”
我要把它用UTF-8这本“词典”翻译成bytes，准备存盘或者发到网上
结果是b’…’开头的，这就是bytes类型
my_bytes = my_str.encode(‘utf-8’)
print(my_str) # 输出：你好，世界
print(my_bytes) # 输出：b’\xe4\xbd\xa0\xe5\xa5\xbd\xef\xbc\x8c\xe4\xb8\x96\xe7\x95\x8c’
``my_bytes` 那一长串就是“你好，世界”这几个字在UTF-8规则下的二进制样子。这就是机器眼里你的文字。
看，
bytes → str：解码 decode()
这个过程，就是拿到一串二进制字节，用同一本翻译词典，把它还原成内存里那个抽象的Unicode字符。
“`python
假设我们从文件里读到了这么一串bytes
received_bytes = b’\xe4\xbd\xa0\xe5\xa5\xbd\xef\xbc\x8c\xe4\xb8\x96\xe7\x95\x8c’
我知道这是用UTF-8编码的，所以我就用UTF-8这本“词典”把它翻译回来
结果就是我们能看懂的str类型
back_to_str = received_bytes.decode(‘utf-8’)
print(received_bytes) # 输出：b’\xe4\xbd\xa0\xe5\xa5\xbd\xef\xbc\x8c\xe4\xb8\x96\xe7\x95\x8c’
print(back_to_str) # 输出：你好，世界
``UnicodeDecodeError`是怎么出现的？
魔咒
就是你用错了翻译词典！
比如，一段文字本来是用UTF-8编码的，你非要用GBK去解码它。这就好比一个英国人拿着一本“德语-英语”词典去听中文，他能听懂才怪了！
“`python
my_str = “你好”
utf8_bytes = my_str.encode(‘utf-8’) # 用UTF-8编码
现在，我假装不知道它是UTF-8，非要用GBK去解
try:
wrong_str = utf8_bytes.decode(‘gbk’)
except UnicodeDecodeError as e:
print(f”出错了！错误是: {e}”)
# ‘gbk’ codec can’t decode byte 0xa0 in position 2: illegal multibyte sequence
# 看到没，GBK翻译官在第2个字节的地方（0xa0）就懵了，说这玩意儿我不认识！
“`
这就是乱码和错误的本质。编码和解码必须使用相同的、正确的编码格式。
实战中的“捉鬼”心法
理论都懂了，实战里坑还是那么多。给你几条我用血泪换来的金科玉律：
-
文件读写，永远指定
encoding最最常见的坑！
open()函数如果你不指定encoding，它会用操作系统的默认编码。在Linux和macOS上，通常是UTF-8，岁月静好。但在某些Windows上，它可能是GBK！你的代码在自己电脑上跑得欢，一部署到客户的Windows服务器上，立马死给你看。“`python
错误示范 👎
with open(‘my_file.txt’, ‘w’) as f:
f.write(“你好”)
正确姿势 👍
显式地告诉Python，我要用全世界通用的UTF-8来写这个文件
with open(‘my_file.txt’, ‘w’, encoding=’utf-8′) as f:
f.write(“你好”)读的时候也一样
with open(‘my_file.txt’, ‘r’, encoding=’utf-8′) as f:
content = f.read()
``encoding` 参数的每一次省略，都是在给未来的自己埋雷**。
记住，**对 -
网络请求，相信直觉但要验证
用
requests库爬网页，r.text会自动帮你解码。它会先从HTTP头里的Content-Type找编码，找不到再自己猜（r.apparent_encoding）。但网站开发者不靠谱的多了去了，有时候它猜的也不准。“`python
import requestsresponse = requests.get(‘https://www.example.com’)
requests觉得应该是这个编码
print(response.encoding)
requests通过分析内容猜出来的编码
print(response.apparent_encoding)
如果发现r.text是乱码，别慌，手动来！
这行代码治好了我多年的网络爬虫乱码强迫症
response.encoding = response.apparent_encoding
correct_text = response.text
``r.content
或者更狠一点，直接用拿到最原始的bytes，自己来decode`，我的地盘我做主。 -
万物皆可
utf-8除非你要和某些古老的、只认
GBK的系统（比如某些银行、政府接口）打交道，否则，请在你的所有项目中，无脑使用UTF-8。它是现代互联网的基石，是解决编码问题的银弹。在新项目里，别再用GBK了，给自己省点心吧。
核心思想：Decode Early, Encode Late
这句英文是Python社区的至理名言，翻译过来就是“尽早解码，尽晚编码”。
- 尽早解码：任何外部数据进入你的程序，第一时间就把它
decode成str。不管是来自文件、数据库，还是网络请求，一拿到手，立刻变成统一的Unicodestr。 - 程序核心逻辑：在你的程序内部，所有变量、函数、类的处理，只使用
str，不要让bytes到处乱窜。这样你就永远不用担心内部逻辑的编码问题。 - 尽晚编码：当你的程序需要把数据输出到外部时，比如写入文件、存入数据库、返回HTTP响应，在最后一刻，才把它
encode成指定的bytes格式（首选UTF-8）。
把这个流程刻在DNA里，python怎么转码这个问题，对你来说就不再是幽灵，而是一个清晰的、可控的流程。从此，告别UnicodeDecodeError，告别乱码，愿你的代码世界里，再无方块和问号。
评论(0)