UnicodeEncodeError: 'mbcs' codec can't encode characters 错误源于 Windows 下 Python 调用系统 API 时路径字符串编码失败，根本原因是 mbcs（类 GBK）无法编码生僻字或 emoji；正确做法是保持路径为 Unicode 字符串、禁用手动 encode、优先使用 os.path.join 拼接，并通过 sys.getfilesystemencoding() 等诊断实际编码。
open() 读写中文路径时报 UnicodeEncodeError
Windows 下用 open() 直接传入含中文的路径（如 r'C:用户文档测试.txt'），常报错：UnicodeEncodeError: 'mbcs' codec can't encode characters。这不是文件内容乱码，而是 Python 尝试把路径字符串交给 Windows API 时，内部编码转换失败。
根本原因是：Python 3 虽然内部用 Unicode 表示字符串，但在调用底层系统 API 前，会尝试用系统默认编码（Windows 是 mbcs，实际行为类似 GBK）编码路径；若路径含超范围字符（比如某些生僻字或 emoji），就可能崩。
- 最稳妥做法是确保路径字符串本身是 Unicode，并让 Python 自动处理——这在 Python 3 中默认成立，但前提是别手动 encode 成 bytes
- 绝对不要写
open(path.encode('utf-8'), ...)或open(path.encode('gbk'), ...)，这反而触发双层编码，必报错 - 用
os.path.join()拼路径，比字符串拼接'C:\' + username + '\file.txt'更安全，它能自动适配平台分隔符和编码边界
os.listdir() 返回中文文件名变成乱码
在 CMD 或 PowerShell 中运行脚本时，os.listdir() 可能返回形如 b'.txt' 的 bytes 列表，而非 str。这不是 bug，而是 Python 发现终端编码不支持当前路径字符时的降级行为——它把文件名原样当 bytes 返回，避免强行 decode 出错。
此时直接 print 或用作路径会出问题。关键判断依据是返回值类型：isinstance(name, bytes) 为 True 就说明环境编码没对上。
立即学习“Python免费学习笔记（深入）”；
- 优先检查终端编码：CMD 默认是
GBK，可用chcp查看；PowerShell 默认是 UTF-8，但旧版可能不是 - 如果确认终端是 GBK，就用
name.decode('gbk')转成 str；如果是 UTF-8 终端，用name.decode('utf-8') - 更健壮的做法是捕获
UnicodeDecodeError，并 fallback 到name.decode('utf-8-sig', errors='replace')，至少保留可读性
subprocess 调用外部命令时中文参数失效
用 subprocess.run(['notepad.exe', 'C:\用户\文档\笔记.txt']) 在非 UTF-8 终端下，Notepad 可能打不开或显示乱码路径。因为 Windows 的 CreateProcessW API 虽然支持宽字符，但 Python 的 subprocess 在某些环境下仍会走窄字符路径，依赖控制台代码页。
- 强制使用
shell=True并搭配encoding='utf-8'（Python 3.7+）：例如subprocess.run(cmd, shell=True, encoding='utf-8') - 或者绕过 shell，直接传入 list，并确保所有字符串都是 Unicode（Python 3 默认满足），同时升级到 Python 3.12+，其 subprocess 对宽字符路径支持已大幅改善
- 避免用
os.system()处理中文路径，它几乎必然失败
requests 上传中文文件名时服务端收不到原名
HTTP 协议本身不规定文件名编码，requests 默认用 latin-1 编码 form-data 中的 filename 字段。服务端若按 UTF-8 解析，就会看到乱码，比如 æµè¯.txt。
这不是 requests 的 bug，而是 RFC 7578 允许客户端自行选择编码，但多数服务端只认 UTF-8。
- 显式指定
Content-Disposition的filename*=参数：用requests_toolbelt的MultipartEncoder，或手动构造 multipart body - 简单场景下，改用
filename不带*，并确保服务端配置为接受latin-1解码（不推荐） - 更可靠的是：上传前把中文文件名 base64 编码，再拼进
filename*=utf-8''{encoded}，服务端对应解码
sys.getfilesystemencoding() 和 locale.getpreferredencoding() 打印当前环境实际生效的编码，比猜更有效。 
