UnicodeDecodeError 根源是读取时编码不匹配，非文件损坏；Python 3 默认 UTF-8，但 Windows 环境常因 locale.getpreferredencoding() 返回 'cp936'（GBK）而报错；应显式指定 encoding='utf-8'，禁用自动检测。
看到 UnicodeDecodeError 别急着改文件，先看 Python 版本和默认编码
Python 3 默认用 UTF-8，但 Windows 控制台、某些 IDE 或旧脚本仍可能触发 UnicodeDecodeError: 'gbk' codec can't decode byte。这不是文件本身坏了，而是 Python 读取时用了错的编码解码器。
- 用
sys.getdefaultencoding()看当前默认编码（通常是'utf-8'），但它不决定文件读取行为 - 真正起作用的是
locale.getpreferredencoding()—— 在 Windows 上常返回'cp936'（即 GBK），这就是报错根源 - 打开文件时显式指定
encoding='utf-8'是最稳做法，别依赖系统猜测：with open('data.txt', encoding='utf-8') as f: - 如果必须兼容 GBK 文件，就写
encoding='gbk'，但注意 Linux/macOS 默认没装 GBK 支持，会抛LookupError
open() 不加 encoding 参数时，Python 怎么猜编码？
不传 encoding 时，Python 调用 locale.getpreferredencoding(False) 获取编码名，再查 codecs.lookup()。这个过程在不同环境差异极大：
- Linux/macOS：通常返回
'utf-8'，相对安全 - Windows 命令行：返回
'cp936'（GBK），但 VS Code 终端可能设为 UTF-8，导致同一脚本行为不一致 - 打包成 exe（如 PyInstaller）：
locale可能失效，回退到'utf-8'，反而让原来能跑的 GBK 脚本崩掉 - 结论：永远显式传
encoding，哪怕只是写encoding='utf-8'，这是最小成本的确定性
用 chardet 自动检测编码？小心它“自信过头”
chardet 对短文本或无 BOM 的 UTF-8 文件容易误判为 'ISO-8859-1' 或 'ascii'，尤其当文件里只有英文和数字时。它不是万能探针，而是概率模型。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 只在你完全不知道源文件编码、且无法联系提供方时才用：
import chardet<br>with open('unknown.bin', 'rb') as f:<br> raw = f.read(10000) # 只读前 10KB，避免大文件卡住<br> enc = chardet.detect(raw)['encoding'] -
chardet.detect()返回的confidence值低于0.7就别信，直接 fallback 到'utf-8'或人工确认 - 生产环境禁用自动检测：它慢（尤其大文件）、不准、引入额外依赖，还可能因版本升级改变判断逻辑
- 比
chardet更轻量的选择是charset_normalizer，它对 UTF-8/BOM 更敏感，但同样不能替代明确声明
从源头控制编码：编辑器、Git、IDE 都得设对
很多编码问题其实发生在保存那一刻。Python 解释器只是“照单读取”，而文件怎么存，决定了它能不能被正确读出。
立即学习“Python免费学习笔记（深入）”；
- VS Code：右下角点击编码名（如
'UTF-8'），选'Save with Encoding'→'UTF-8'；同时在settings.json加："files.encoding": "utf8",<br>"files.autoGuessEncoding": false
- PyCharm：Settings → Editor → File Encodings → 全局设为
UTF-8，勾掉Transparent native-to-ascii conversion - Git：避免换行符和编码混在一起，在项目根目录加
.gitattributes：* text=auto eol=lf<br>*.py text eol=lf<br>*.txt text eol=lf
这能防止 Windows 换行符干扰编码识别 - 特别注意：BOM 是个陷阱。UTF-8 文件带 BOM（
\ufeff）会导致import失败或 JSON 解析错误，编辑器要关掉“UTF-8 with BOM”选项
实际排查时，最容易被跳过的环节是确认「谁写的这个文件」——是爬虫下载的？是 Excel 导出的？是别人邮件发来的？不同来源的默认编码策略完全不同。没有统一解法，只有针对性验证。
