从字符编码原理出发彻底解决PyCharm控制台中文乱码

如果你在PyCharm控制台里看到print("你好，世界")输出的不是“你好，世界”，而是一串浣犲ソ锛屼笘鐣或者ä½ å¥½这种天书字符，恭喜你，撞上了编码问题。很多刚接触 Python 的人第一次遇到这种情况，第一反应是 PyCharm 坏了，或者 Python 打不出中文。其实 PyCharm 没坏，Python 也没坏，坏的是“源码文件编码、Python 运行编码、控制台解码编码”这三条链路上有一个没对齐。

这个话题我前前后后折腾过不少次，每次场景还不太一样。有的乱码出现在 Run 窗口，有的出现在内置 Python Console，有的同一个脚本放到 CMD 里跑反而正常，代码本身一字未动，换台电脑结果又不一样。下面把这类问题的判断思路、配置位置、应急手段和永久解决方案完整梳理一遍，照着操作基本能解决 99% 的 PyCharm 控制台中文乱码。

1. 乱码背后的编码问题，先搞清楚你的脚本在哪个环节“翻译”坏了

1.1 三个编码节点：源码、运行环境、控制台

一个 Python 脚本从“写入”到“显示出来”，中间要经历三次编码转换。第一次是源码文件本身：你在 PyCharm 里写代码，文件以某种编码保存在磁盘上，可能是 UTF-8，也可能是 GBK。第二次是 Python 解释器读取源码并执行，它要用相同的编码去解码你的源码文件，同时在print输出文本时，要把内存里的 Unicode 字符串编码成标准输出流能接受的字节序列。第三次是 PyCharm 控制台拿到这些字节，再用它认为正确的编码去解码并渲染成屏幕上的文字。

任何一次编码和解码不是同一套，就会出现乱码。比如 Python 解释器按 UTF-8 编码输出了“你好”的字节序列，但 PyCharm 控制台按 GBK 去解码，就会显示成“浣犲ソ”。反过来，如果 Python 按 GBK 输出，控制台按 UTF-8 解码，就会显示成“ä½ å¥½”。这两种乱码形态，一个偏“澶╁純”风格，一个偏“Ã¥”风格，实际上对应了不同的编码错位方向，这是判断问题的关键线索。

所以才说先别急着改代码，先搞清楚你在哪个环节看乱码。同样的代码，可能源码编码、解释器编码、控制台编码都不同，但排列组合起来，结果就是“在我电脑上正常，到你电脑上乱码”这类玄学。诊断的第一步，是做一个非常小的定位实验，观察 Python 自己报告的编码信息。

1.2 先做一次最基础的定位实验

在 PyCharm 里新建一个 Python 文件，输入以下代码，然后直接运行：

import sys print('Python 解释器默认编码:', sys.getdefaultencoding()) print('标准输出流 using 编码:', sys.stdout.encoding) print('文件系统默认编码:', sys.getfilesystemencoding()) print('你好，世界')

运行后重点看第二行，也就是sys.stdout.encoding。在 PyCharm 的 Run 窗口里，如果显示的是utf-8，那说明 Python 解释器认为标准输出是 UTF-8，它会按 UTF-8 把中文字符编码成字节后抛给控制台。这时候如果控制台用 UTF-8 解码，一切正常；如果控制台用了 GBK，就乱码。如果显示的是cp936，说明 Python 解释器认为标准输出是 GBK，这个值在很多老版本 PyCharm 或某些新版 PyCharm 的特定终端模式下会出现。

还可以进一步做字节级验证：

print('中'.encode('utf-8')) print('中'.encode('gbk'))

如果控制台显示b'\xe4\xb8\xad'，说明 UTF-8 编码的字节是没问题的，问题出在显示时的解码环节。如果显示的是正常的b'\xd6\xd0'，那你看到的还是 GBK 字节。这一步能帮你精确判断到底是谁在“乱翻”，那后面的配置方向也就明确了：哪个环节跟别的环节不一致，就把哪个环节纠正过来。

2. PyCharm 控制台中文乱码的三种典型场景与对应解法

2.1 场景 A：Run 窗口输出乱码

这是最常见的场景。写完代码，点运行，下面的 Run 窗口输出中文乱码。处理步骤我按从“最快见效”到“永久修复”的顺序来排。

第一步，直接在 Run 窗口内切换编码。PyCharm 较新版本里，在 Run 窗口的空白处单击右键，或者点击左侧的齿轮图标，会看到类似 “Change encoding” 或者 “Change font size” 的选项。如果 “Change encoding” 存在，点开后可以逐一切换 GBK、UTF-8 等编码，切换后控制台会立刻重新解码当前输出。如果你的乱码是 UTF-8 字节被 GBK 解码导致的，切到 UTF-8 后马上变正常。这一步只是临时看看效果，帮你确认问题方向，但它能立刻验证“是不是控制台解码端的问题”。

第二步，统一 IDE 里的三项编码设置。打开Settings > Editor > File Encodings，把 Global Encoding、Project Encoding、Properties Files 的默认编码全部设为 UTF-8，这个设置决定了 PyCharm 以什么编码读取和保存你的代码文件。如果你的代码文件本身就存成了 GBK，而 IDE 强行按 UTF-8 去读，那你在编辑器里看到的代码会是乱码。如果你编辑器里代码正常，那此处基本没问题，但建议还是统一下，能避免后续很多隐藏问题。

第三步，修改 PyCharm 的 JVM 配置文件。PyCharm 跑在 JVM 上，底层有一个默认文件编码属性，可能出现 IDE 内部某些环节的编码被外部环境变量或系统区域干扰。打开Help > Edit Custom VM Options，会打开一个 vmoptions 文件，在文件末尾添加一行：

-Dfile.encoding=UTF-8

保存后完全退出 PyCharm 再重启。注意，一定要彻底退出，不是关闭项目窗口，Mac 上是Cmd+Q，Windows 上是托盘图标右键退出，不然 JVM 参数不生效。这一项主要解决 IDE 内部字节流转时的默认编码，很多“PyCharm 自己显示乱码”的问题都靠它解决。

第四步，给运行配置设置环境变量。在Run > Edit Configurations里找到当前运行配置，在Environment variables一栏添加：

PYTHONIOENCODING=utf-8

这是 Python 官方认可的环境变量，专门用来指定标准输入输出流的编码。设置了之后，Python 解释器就不会猜编码，直接按 UTF-8 输出。这一步对 Run 窗口、内置 Python Console 都有效，是一个很值得记住的通用方案。

第五步，如果以上都做了还乱，可以试一下运行配置里的执行模式。还是在Run/Debug Configurations里，找到 “Execution” 区域，有一个 “Emulate terminal in output console” 选项，有些版本叫“在输出控制台中模拟终端”。勾选前后分别跑一次，看看哪种方式下中文正常。这个选项的作用是把 Run 窗口变成一种终端模拟器，走的是另一条输出处理路径，解码规则和普通输出有区别，所以有时勾选能救，有时取消勾选反而能救，都需要实测。

2.2 场景 B：内置 Python Console 输出乱码

PyCharm 下方还有一个专门的 “Python Console” 面板，就是那个>>>的交互式环境。它的编码设置往往和 Run 窗口独立。很多人在 Run 窗口把问题修好了，切到 Python Console 一试，还是乱码，原因就在这里。

对这种交互式环境，首先要看它是怎么启动的。Python Console 本质上也是启动了一个 Python 进程，所以PYTHONIOENCODING=utf-8这个环境变量依然有用。设置方法有两种：一种是在系统环境变量里全局加，另一种是在 PyCharm 的设置里单独配。打开Settings > Build, Execution, Deployment > Console > Python Console，如果 PyCharm 版本较老，能看到类似 “Python interpreter” 和 “Environment variables” 的设置项，在里面加PYTHONIOENCODING=utf-8即可。新版本如果找不到这个入口，也可以直接在主界面运行配置中选择 Python Console 对应的配置，然后在运行配置里加环境变量。

还可以在 Python Console 里直接执行一段代码，临时重设标准输出的编码：

import sys sys.stdout.reconfigure(encoding='utf-8')

sys.stdout.reconfigure是 Python 3.7 之后提供的能力，可以在不重开进程的情况下修改输出流的编码。执行完再print('中文测试')，如果恢复正常，说明问题就出在标准输出编码上。不过这只能救当前会话，下次重新打开 Python Console 需要再执行一次，所以还是建议把环境变量加上，一劳永逸。

2.3 场景 C：Windows 外置终端或 CMD 运行脚本乱码

有时候你会发现同一个脚本在 PyCharm Run 窗口里正常，但打开 Windows 的 CMD，用命令行python script.py跑，中文输出却乱码。这是另外一类问题，和 PyCharm 无关，主要是 Windows 控制台默认用 GBK 代码页，也就是通常说的代码页 936 来解码输出流，而 Python 可能会按 UTF-8 输出。

临时解决办法是在 CMD 窗口手动切换代码页：

chcp 65001

然后重新运行脚本。65001代表 UTF-8，切换后 Python 输出的 UTF-8 字节就能被正确显示。需要注意的是，这个临时切换只对当前命令提示符窗口有效，关掉再开就没了；而且切换代码页后，某些使用 GBK 编码的老程序可能出现新的乱码，属于正常现象。

更根本的解决办法是设置环境变量PYTHONUTF8=1。这是 Python 3.7 引入的 UTF-8 模式开关，设置了它之后，整个 Python 进程会强制使用 UTF-8 作为默认编码，包括标准输入输出、文件读写，不再依赖系统区域设置。在 Windows 系统的用户环境变量里加一个名为PYTHONUTF8、值为1的变量，重开终端和 PyCharm 后，几乎所有 Python 编码问题都会大幅减少。如果你只是想对当前项目生效，也可以把PYTHONUTF8=1加到 PyCharm 对应运行配置的环境变量里。

我个人强烈推荐给 Windows 上的 Python 开发环境配置PYTHONUTF8=1，它的覆盖面比PYTHONIOENCODING更广，不光是控制台，连脚本里open()读取文件时如果不指定encoding，也会默认用 UTF-8，这能少很多莫名其妙的坑。当然，前提是你的代码和项目文件都统一使用 UTF-8 编码，如果项目里有大量 GBK 编码的旧文件，设置全局 UTF-8 模式反而会让那些文件读取出错，这一点切记。

3. 实操记录：完整修复一个“print 中文变问号”的案例

3.1 现象描述与初步排查

有一次我在一台新装的 Windows 11 电脑上运行一个爬虫脚本，脚本里读取了一个包含中文的网页正文，然后在 PyCharm 的 Run 窗口打印结果。输出里所有中文都是“？”。注意，这里不是“浣犲ソ”那种错位乱码，而是直接变成问号，这个现象非常典型：不是解码错了，而是某些环节直接把中文字符替换成了不支持或无法表示的字符。

我当时先跑了上面那段诊断脚本，打印结果里sys.stdout.encoding显示的是utf-8。正常情况下，UTF-8 输出应该没问题，但实际却变问号，这就说明问题大概率不在 Python 标准输出，而是在 PyCharm 控制台拿到字节之后，用了另一种方式去“理解”这些字节，或者字体渲染环节出了问题。不过，先按问号场景继续排查，最常见的情况，其实是 PyCharm 控制台字体不支持中文字符，导致中文字体被降级成了系统回退字体，某些字体回退效果差的组合下，中文会直接显示成“口口”或者问号。这属于“显示层故障”，不是“编码故障”。

那一次的真实原因后来定位到 PyCharm 的 JVM 参数上：因为那台电脑的系统区域设置了使用 Beta 版 UTF-8 提供全球语言支持，而 PyCharm 的 JVM 默认编码被系统区域影响，反而导致内部字节处理和对齐出现了意外组合，Run 窗口在解析流时把中文字节丢弃了。这个配置在 Windows 10/11 的“区域设置”里可以看到，勾选后整个系统默认代码页会变 UTF-8，对很多老软件有副作用，建议不要单独为了 PyCharm 去改它。

3.2 后台配置调整的具体位置和操作

我最终的修复流程，你可以按顺序实操。以下以 PyCharm 2023.2 版本为例，不同版本菜单可能有细微差异，但关键词一样，用搜索功能都能找到。

第一步，Help > Edit Custom VM Options，在打开的 vmoptions 文件里加上-Dfile.encoding=UTF-8，保存。第二步，关闭 PyCharm，右键任务栏图标退出进程，确保没有后台残留。重新打开后，先确认编辑器右下角文件编码显示为 UTF-8。第三步，打开Settings > Editor > File Encodings，确认 Global Encoding 和 Project Encoding 是 UTF-8。第四步，在Run > Edit Configurations里给实际使用的运行配置加环境变量PYTHONIOENCODING=utf-8。第五步，运行诊断脚本，检查sys.stdout.encoding输出是否为utf-8。第六步，如果输出正常但显示仍然有问题，就点击 Run 窗口左侧齿轮区域，或者右键控制台窗口，找 “Change encoding”，手动切换 UTF-8；同时检查Settings > Editor > Font中控制台字体是否使用支持中文的字体，比如微软雅黑或 Consolas（Consolas 本身不含中文，但通常会字体回退），如果不放心，直接选 “Microsoft YaHei UI” 或者 “SimHei”。

这套组合拳打完，那台电脑上的 Run 窗口中文输出恢复正常。做完这些步骤后你不需要额外写任何代码，也不要每次都在脚本里塞# -*- coding: utf-8 -*-这种声明，这个声明只在 Python 2 时代以及 Python 3 源码文件编码非 UTF-8 时才有意义，在 Python 3 默认 UTF-8 源码编码的时代基本属于无效劳动。

3.3 应急方案与永久方案的选择

这里要区分“应急”和“永久”两层方案。应急方案就是出了乱码，你正在调脚本、正在验证结果，没时间慢慢改配置时，最快能看上正常字的办法。最简单的是在 Run 窗口用鼠标选住那段乱码文本，复制到任何一个支持编码切换的编辑器里，手动切换编码方式查看，但这么做效率太低。

更推荐的应急办法，是在脚本最开始临时加一段强制输出编码的代码：

import sys sys.stdout.reconfigure(encoding='utf-8')

这段代码在三行以内，能立刻让 Python 解释器后续输出全走 UTF-8。如果你不想为了应急污染代码，也可以临时在 PyCharm 的 Python Console 里先执行这行代码，再执行你的脚本逻辑，不过实际项目里控制台是分进程的，这种方式对 Run 窗口脚本无效，只对 Console 有效。还有一招，直接把你的输出结果写到一个 UTF-8 编码的日志文件里，然后换一个支持编码切换的文本编辑器查看，保证这个输出文件内容以 UTF-8 写入，但是你的代码里open()要显式声明encoding='utf-8'，比如：

with open('out.txt', 'w', encoding='utf-8') as f: f.write('你好，世界')

文件里如果能正常显示，说明代码逻辑没问题，就是控制台显示层的问题，那就可以放心去折腾 PyCharm 配置了。永久方案就是上面那一整套配置调整，核心集中在File Encodings、VM options、运行配置环境变量、以及PYTHONUTF8环境变量这几个方面。

根据我的实测经验，彻底搞一次永久方案配置，以后再遇到乱码的概率会大幅下降。但有一点要提前告诉你：同一个小项目，可能你本地正常，发给同事后他那边乱码。因为他的系统编码环境、PyCharm 版本、运行配置都可能和你不同。所以项目里能统一 UTF-8 的地方，尽量全部统一，包括数据库存储、文本文件读写、接口传输等环节。

4. 进阶问题：日志中文乱码、中文写入数据库乱码

4.1 日志文件中文乱码，问题往往不在控制台

有段时间我排查一个线上接口的日志，发现日志文件里的中文全是乱码，但 PyCharm 控制台里同一个接口打出来的中文又是正常的。很多人第一反应是日志框架的编码没有设置好，但真正的原因往往很简单：日志框架写文件时没有指定编码，Python 在 Windows 上调用open()家族函数时默认编码跟随系统区域，中文系统下是 GBK。日志文件用 GBK 编码写入后，而你在 PyCharm 打开这个文件时，PyCharm 默认按 UTF-8 解码，自然乱码。

所以，在用 Pythonlogging模块写文件时，建议在FileHandler里显式指定编码：

import logging handler = logging.FileHandler('app.log', encoding='utf-8') logger = logging.getLogger() logger.addHandler(handler) logger.info('中文日志测试')

有一点要注意，这两个“中文乱码”的本质不同：控制台乱码往往是“解码端不对”，而日志文件乱码往往是“写入端编码与读取端编码不一致”。一个是出口问题，一个是存储问题。处理方式也不同：控制台乱码你可以在显示端切换编码或者改变 Python 标准输出编码；而文件乱码，必须保证写入编码和读取编码一致，否则你把文件发给别人，别人用另一个编码打开，看到的还是乱码。

4.2 Python 写入 MySQL 等数据库中文变乱码的排查链

数据库中文乱码是另一类高频问题，而且它的表现形式不一定是“控制台乱码”，也可能是“数据存进去之后查出来是问号”。有一个我踩过的典型坑：用 PyCharm 的 Database 面板连接 MySQL 时，连接串或者 JDBC URL 里没有指定字符集，而 MySQL 服务端默认字符集是 latin1，结果写入的中文直接变成??。

排查数据库乱码，要沿着三条线走。第一条线是客户端连接编码：使用 PyMySQL 连接时，在connect()参数里指定charset='utf8mb4'，这一步非常关键，很多人只写charset='utf8'，其实 MySQL 的utf8对应的是utf8mb3，只能存基础平面的字符，遇到 emoji 会失败或乱码，强烈建议直接写utf8mb4。第二条线是表字段字符集，用 SQL 查一下：

SHOW CREATE TABLE your_table;

确认表中 varchar 字段的 charset 是否为utf8mb4。第三条线是写入数据时 Python 侧的编码：如果你在代码里手动encode或者用bytes去拼接 SQL，就可能造成二次编码错误。正常情况下，PyMySQL 连接层设置了utf8mb4，Python 侧直接用字符串类型传参，SQL 参数用%s占位符传给数据库，不要手动拼字符串，就能避免绝大多数编码错乱。

如果你写了 SQL 后，在数据库客户端里SELECT '中文';能正常显示，但程序插入后查询是??，先查连接编码，再看表结构编码，这俩是高频根因。如果表和连接都是 UTF-8，但插入后仍然是问号，还要检查 MySQL 服务端配置文件的character_set_server和启动参数，是否被全局设置成别的字符集，这种慢性的“默认值”问题排查起来最费神。可以用下面这条命令直接查看当前所有相关编码设置：

SHOW VARIABLES LIKE 'character_set_%';

把character_set_client、character_set_connection、character_set_results、character_set_database、character_set_server这几项统一成utf8mb4，基本就稳妥了。注意，这里的统一指的是在 MySQL 连接初始化阶段自动转换，而不是要求你手工逐个修改配置文件，因为有些项目没有权限修改数据库服务器的全局配置。

4.3 归档：一份可直接复用的编码检查清单

遇到中文字符乱码问题，先别急着改代码，按下面这张表从上到下快速排查一遍，能节省大量时间。我将常见现象、可能原因、解决方向对应起来，你可以直接当作速查表用。

这张表最核心的一句话：出现乱码，永远先判断是“输出端编错”还是“显示端解错”。输出端编错的典型特征是字节已经不对；显示端解错的典型特征是用另一套编码查看时能还原出原文。字节错乱和你眼里的乱码不是一回事，我们在编辑器里看到的乱码字符本身，已经是“错误解码后的结果”，所以排查时才需要借助sys.stdout.encoding、字节打印等手段来定位。

5. 实战答疑：日常开发中常遇到的几个编码“凶手”

5.1 为什么同一个脚本别人不乱我就乱

这个问题我回答过很多次。技术前提是 Python 3 在 Windows 上的sys.stdout.encoding不一定固定是 UTF-8，它和 Python 解释器启动时打开的终端设备有关。如果 PyCharm 给你的 Run 控制台传入一个主流的虚拟终端句柄，Python 会认为标准输出支持 UTF-8；如果 PyCharm 在某些模式下传入的是传统管道或者系统终端句柄，Python 就会沿用 Windows 默认 ANSI 代码页，也就是 GBK。不同人的 PyCharm 版本不同、运行配置不同、系统区域和版本不同，就可能导致同一个脚本在不同机器上有完全不同的编码行为。

还有一个非常容易忽略的点是：PyCharm 的安装目录、项目目录、系统用户名如果包含中文，也可能触发部分旧版 JVM 的默认编码识别异常，从而间接影响控制台输出。不过在实际项目中，这个影响比较隐性，优先级没有上面几类高。

话说回来，判断“别人不乱我就乱”这类跨环境问题，不能只看表面。你应该让朋友把他的sys.stdout.encoding打印结果发给你，和你本机做一次对比。两份结果如果都是utf-8但输出一个正常一个乱码，那问题就不在 Python 进程，而在 PyCharm 控制台接收端；如果一份是utf-8一份是cp936，那直接拷贝对方的环境变量配置或者统一到 UTF-8 就行。排查跨环境问题，永远要“拿数据说话”，不能靠感觉。

5.2 修改代码页和系统区域对 PyCharm 有没有用

这问题我也被问过。Windows 上执行chcp 65001修改的是控制台代码页，它只影响当前这个控制台窗口对字节的解释方式。对 PyCharm 内置的 Run 窗口，这个命令没有任何作用，因为 Run 窗口不是 Windows 控制台窗口，它由 IntelliJ 平台直接接管。在 PyCharm 内置的 Terminal 标签页里执行chcp 65001倒是有效的，因为那个 Terminal 走了 Windows/Cmder 的终端通道。所以如果你在 Run 窗口乱码，去命令行改代码页是改不到点上的。

至于系统区域设置里的“Beta 版：使用 Unicode UTF-8 提供全球语言支持”，勾选后整个系统默认代码页会变成 65001，这确实能在一定程度上让 Windows 控制台和旧软件更容易兼容 UTF-8，但副作用不少：一些老的中文软件界面会变成乱码，某些安装程序、字体渲染、右键菜单都可能异常。PyCharm 的 JVM 在这种环境下可能被系统区域影响而采用不同的默认编码，反而不如不勾选时稳定。所以我的个人建议是，不要为了专门解决 PyCharm 乱码去修改操作系统级别的区域设置，这是拿大炮打蚊子，还容易误伤别的软件。

5.3 我踩过的几个坑和最终建议

第一个坑是只改了 PyCharm 的File Encodings，没有改vmoptions，结果 Run 窗口部分文件正常，部分历史文件还是乱码。后来发现历史文件本身保存成了 GBK，而项目编码是 UTF-8，这是历史遗留问题。如果你接手了一个老项目，项目文件里混有 GBK 和 UTF-8 两种编码，不要一刀切地全改成 UTF-8，建议用 PyCharm 的File > File Properties > File Encoding逐个查看，并统一保存，否则 Git Diff 会变得极其巨大，无法 review。

第二个坑是sys.stdout.reconfigure(encoding='utf-8')在 Python 3.7 以下版本不存在。如果项目用的是老版本 Python，或者某些剥离版解释器，这段代码会直接报AttributeError。做一个简单的兼容处理会更好：

import sys if hasattr(sys.stdout, 'reconfigure'): sys.stdout.reconfigure(encoding='utf-8')

第三个坑是文件读写时没有显式指定编码。很多人只关注控制台输出，忽略了open()的默认编码。Windows 中文环境下，open('data.txt')默认用 GBK 读取或写入。Linux 服务器上默认是 UTF-8，所以同一个脚本本地正常、上服务器后读文件就乱码。统一在所有open()调用里显式加encoding='utf-8'是性价比最高的习惯，不要依赖系统默认值。

第四个坑比较隐蔽：PyCharm 的日志文件路径里如果带有非 ASCII 字符，而且 macOS 或 Windows 的文件系统使用了不同的规范化方式，可能导致日志文件写入编码判断异常，进而显示乱码。这个概率较低，但如果你做了上面所有步骤仍然乱码，可以考虑把项目路径改成纯英文路径试试。不是玄学，是 Python 某些版本在纯 ASCII 路径下的编码判断更稳定。

根据我的经验，解决 PyCharm 控制台中文乱码最稳健的组合是：IDE 的 File Encodings 全部 UTF-8，VM options 加-Dfile.encoding=UTF-8，运行配置加PYTHONIOENCODING=utf-8，同时在 Windows 用户环境变量里设置PYTHONUTF8=1。这四件事做完，不管是在 Run 窗口、Python Console、Terminal 标签页，还是项目的文件读写场景，中文出现乱码的概率都会降到非常低。

这套组合可以解决大多数场景，但你最好还是记住一个核心原则：任何环节都不要依赖系统默认编码，显式声明编码永远是最安全、最可控的。无论是读文件、写文件、连数据库、打印日志，都在代码里明确说出“我要用 UTF-8”，而不是让 Python 和操作系统帮你猜。做到这一点，以后不只是 PyCharm 控制台，你会少遇到一大半和中文乱码相关的坑。