根本原因是Navicat在Windows下用GBK解码UTF-8 BSON字符串，非MongoDB乱码；解决方法包括添加--env=LANG=en_US.UTF-8启动参数、勾选Use UTF-8 for file encoding或导出为Unicode转义JSON。
Navicat 连 MongoDB 时中文显示为问号或方块
根本原因不是 mongodb 本身乱码——它默认用 utf-8 存储，也不需要设置字符集。问题出在 navicat 的连接层对 bson 字符串的解码逻辑上，尤其在 windows 系统下默认用了系统本地编码（如 gbk）去解析本该按 utf-8 解码的字段值。
- 只在 Navicat 查看数据时乱码，用
mongosh或程序读取正常 → 确认是客户端解码问题 - 新建集合插入中文正常，但查询结果里中文变
???或空格 → 典型 UTF-8 字节被当 GBK 解码 - Mac/Linux 版 Navicat 通常不显式乱码，Windows 版高频出现 → 和系统区域设置强相关
Navicat MongoDB 连接配置里没有「字符集」选项怎么办
和 MySQL 不同，Navicat 对 MongoDB 的连接配置界面压根没提供 charset、collation 或类似输入框——因为 MongoDB 驱动协议不走 SQL 字符集协商流程。所谓“调整字符集”，其实是绕过 UI，强制让 Navicat 启动时使用 UTF-8 环境。
- Windows 用户：右键 Navicat 快捷方式 → 「属性」→ 「快捷方式」选项卡 → 在
目标栏末尾追加--env=LANG=en_US.UTF-8（注意前面有个空格） - 更稳妥的做法是改启动脚本：找到 Navicat 安装目录下的
navicat.exe，用命令行带环境变量启动：cmd /c "set PYTHONIOENCODING=utf-8 && start navicat.exe" - 如果用的是 Navicat Premium 16+，尝试在「工具」→「选项」→「环境」里勾选
Use UTF-8 for file encoding（这个开关会影响 BSON 字符串渲染路径）
用 mongosh 或程序验证是否真乱码
别只信 Navicat 界面显示。MongoDB 服务端几乎从不存非 UTF-8 数据，只要插入时是合法字符串，底层就是 UTF-8 字节流。关键看驱动怎么读、客户端怎么解。
- 在
mongosh中执行db.collection.findOne()，中文正常 → 说明数据没问题，是 Navicat 渲染问题 - Node.js 用
mongodb驱动查出来是乱码 → 检查process.env.NODE_OPTIONS是否含--inspect导致编码继承异常（少见但存在） - Python 用
pymongo出现UnicodeDecodeError→ 多半是文件保存成 ANSI 编码后又用 UTF-8 读，和 Navicat 无关
真正起效的临时 workaround：导出再导入
如果你只是想快速看清数据、导出报表，又不想动系统环境变量，可以跳过连接层直接操作 BSON 流。
- 在 Navicat 中右键集合 → 「导出向导」→ 格式选
JSON→ 勾选Export data with Unicode escape（这会把中文转成\u4f60\u597d，确保 JSON 文件可读） - 用 VS Code 打开导出的 JSON，它默认识别 UTF-8，中文就回来了
- 反向操作（导入 JSON 到新集合）时，Navicat 会自动把
\u序列还原为 UTF-8 字符，不会二次乱码
复杂点在于：Navicat 的环境变量覆盖行为不稳定，不同版本对 --env 参数支持程度不同；而导出 JSON 虽然绕路，但每次都能保底看到原文。别指望一次设置永久生效，Windows 区域设置、用户权限、甚至杀毒软件都可能干扰编码环境加载。
