Xftp上传压缩包时文件名乱码的根本原因是客户端编码设置错误，需在上传前将Xftp连接属性中的编码设为Unicode(UTF-8)，否则Windows打包的GBK编码文件名会被错误解析为乱码，且已上传的乱码无法自动修复。
上传压缩包时文件名就乱码，Xftp 编码没设对
根本原因不是 Jupyter 本身，而是 FTP 客户端用错了字符编码读取中文文件名。Xftp 默认可能用 GBK 或 Latin-1 解析 UTF-8 编码的文件名，导致上传后显示为 文件å.ipynb 这类乱码。
解决方法很简单：右键已建立的连接 → 【属性】→ 【选项】→ 【连接】→ 【编码】→ 选 Unicode(UTF-8)。如果仍不行，可依次尝试 GBK、GB2312 —— 注意，这一步必须在上传前设置，已上传的乱码文件名不会自动修复。
解压后内部文件名乱码，tar / unzip 不识别编码
Linux/macOS 的 tar 和 unzip 命令默认不处理文件名编码转换，尤其当压缩包是在 Windows 下用 GBK 打包、传到 UTF-8 环境解压时，就会出现目录里一堆 ?????.py。
推荐用 convmv 修复（需先安装）：
-
sudo apt install convmv（Ubuntu/Debian）或brew install convmv（macOS） - 进入目标目录，先试
convmv -f gbk -t utf-8 --notest *看是否能预览正确还原 - 确认无误后，去掉
--notest执行真实转换：convmv -f gbk -t utf-8 * - 若提示 “No change needed”，说明源编码不是 GBK，换成
-f latin1或-f cp936再试
Jupyter Lab/Notebook 界面里点不开中文文件名
这不是显示问题，而是内核层面的路径解析失败。Jupyter 启动时 Python 进程若未声明系统编码，os.listdir() 可能将 UTF-8 字节序列错误解码为乱码字符串，导致点击时报 FileNotFoundError，即使文件真实存在。
临时绕过方法：
- 在终端中用
ls确认文件名实际字节（如中文.ipynb在终端显示正常，但在 Jupyter 列表里是方块） - 直接在地址栏手动输入 URL：
/notebooks/%E4%B8%AD%E6%96%87.ipynb（URL 编码后的路径） - 长期方案：启动 Jupyter 前加环境变量：
export PYTHONIOENCODING=utf-8，再运行jupyter notebook
服务器上用 Python 脚本读中文文件名报 UnicodeDecodeError
常见于 os.walk() 或 glob.glob() 遍历时，底层 C 库把文件名当作 Latin-1 处理，遇到非 ASCII 字节就崩溃。
安全读取方式（Python 3.7+）：
import os
for root, dirs, files in os.walk('.'):
for f in files:
try:
# 强制按 UTF-8 解码路径
path = os.path.join(root, f)
with open(path.encode('utf-8').decode('utf-8'), 'r') as fp:
pass
except UnicodeDecodeError:
# fallback：用原始字节路径操作
raw_path = os.path.join(root.encode(), f.encode())
# 后续用 bytes 模式打开，如 open(raw_path, 'rb')真正棘手的是跨平台协作场景：Windows 用户用 GBK 打包 → Linux 服务器解压 → Jupyter 读取。这种链路里任何一个环节编码不显式对齐，都会让文件名变成“不可见但存在”的状态。别指望 UI 自动修复，得从传输、解压、运行三处同时卡住编码入口。
