优先使用encoding='utf-8-sig'，它能自动处理BOM并兼容有无BOM的UTF-8；若仍乱码，需根据文件真实编码尝试gbk、gb18030等，不可盲目依赖记事本显示或硬试latin-1。
Python用pandas.read_csv读取CSV时中文显示为，是不是encoding设成utf-8就完事了？
不是。直接写 encoding='utf-8' 很可能还是乱码，尤其当文件是Windows Excel另存为的CSV——它默认用BOM头的UTF-8编码，即utf-8-sig。这个BOM（ufeff）会被普通utf-8当成真实字符读进来，导致第一列列名开头多出一个怪符号，或者整行偏移。
实操建议：
- 优先试
encoding='utf-8-sig'，它会自动跳过BOM，对带BOM的UTF-8和无BOM的UTF-8都兼容 - 如果仍报错
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0，说明根本不是UTF系编码，得换其他编码排查 - 别依赖“记事本里看着正常”来判断编码——记事本自动识别常不准，用VS Code右下角编码标识或
file -i filename.csv命令确认真实编码
除了utf-8-sig，还有哪些encoding值值得试？
Windows环境生成的CSV，尤其是从Excel、WPS导出的，大概率不是UTF-8。常见真实编码和对应encoding值如下：
-
gbk：简体中文Windows系统默认编码，覆盖绝大多数老Excel导出文件 -
gb2312：gbk子集，兼容性略差但更轻量，可作备选 -
gb18030：国标最新版，兼容gbk且支持更多汉字（如生僻姓名、古籍字），但pandas读取稍慢 -
cp936：Windows代码页名，等价于gbk，部分旧脚本里会出现
不推荐盲目试latin-1或iso-8859-1——它们虽不会报错，但会把中文转成毫无意义的拉丁字符，掩盖真实问题。
立即学习“Python免费学习笔记（深入）”；
pandas.read_csv指定encoding后仍报错：'charmap' codec can't decode byte
这是Windows Python默认用cp1252（即charmap）解码，而你传了encoding参数却没生效——大概率是因为用了engine='python'，它在某些版本中会忽略encoding参数；或者文件路径含中文，触发了底层open逻辑异常。
解决方法：
- 显式加上
engine='c'（默认值，但明确写出更稳） - 确保路径字符串是raw string或双反斜杠，比如
r'C:data est.csv'或'C:\data\test.csv' - 如果文件真有损坏或混合编码（如某几行是gbk，其余是utf-8），pandas无法自动修复，得先用
codecs模块逐行读取清洗，再喂给pd.DataFrame
用open()手动读取CSV再给pandas，有必要吗？
一般没必要。pandas.read_csv本身已封装好编码处理逻辑，加一层open()反而容易出错：比如忘记传newline=''导致Windows下空行增多，或误用io.StringIO引发类型不匹配。
只有两种情况值得手动读：
- 需要预处理——比如删掉前3行说明文字、替换特定乱码字符、按行过滤再加载
- 编码极不规则——例如每列用不同编码，或BOM位置异常（不在开头），这时必须用
open(..., encoding='xxx', errors='replace')配合正则清洗
多数乱码问题，根源就在没分清“文件实际编码”和“程序解码方式”的匹配关系。utf-8-sig不是万能钥匙，但它确实是打开Windows系CSV乱码锁的第一把正确钥匙。
