乱码根源在写入前编码处理或客户端解码逻辑，非MongoDB存储问题；Python需确保文件UTF-8保存、显式指定open编码；Java需JVM设-Dfile.encoding=UTF-8；Navicat/Compass显示异常属客户端渲染问题，mongosh正常即数据无误。
乱码不是 MongoDB 本身的问题，它默认用 UTF-8 存储字符串；真正出问题的环节在「写入前的编码处理」或「驱动/工具的解码逻辑」。只要插入时字节流是合法 UTF-8，服务端就没错。
Python pymongo 写入中文乱码
常见现象：用 pymongo 插入中文后，在 Navicat 或 Compass 里显示为 ??? 或方块，但用 mongosh 查却正常。
- 检查 Python 文件保存编码：必须是 UTF-8（Notepad++ 或 VS Code 右下角确认），不是 ANSI/GBK
- 读取外部文件时显式指定编码：
open('data.txt', 'r', encoding='utf-8') -
MongoClient连接字符串无需加?charset=UTF-8—— pymongo 不识别该参数，加了也无效 - 避免手动 encode/decode：不要写
str.encode('utf-8').decode('utf-8')，pymongo 自动处理 Unicode 字符串
Java Driver 插入中文显示异常
典型错误：控制台打印正常，但数据库里存的是 \u4f60\u597d 或问号，说明字符串被双重编码或转义了。
- 确保 JVM 启动参数含
-Dfile.encoding=UTF-8，而不是依赖系统默认编码 - 连接 URI 中可加
?charset=UTF-8，但实际生效取决于驱动版本；MongoDB Java Driver 4.x+ 已忽略该参数，重点在 JVM 环境 - 不要对字符串做额外
getBytes("GBK")转换再塞进Document，pymongo 和 Java Driver 都要求传入原生String - 如果用 Spring Data MongoDB，检查
@Document实体类字段类型是否为String，而非byte[]或自定义序列化器
Navicat / Compass 查看时中文变问号
这是纯客户端渲染问题，数据本身没问题。Windows 下尤其高发，因为 Navicat 默认用 GBK 解析 BSON 中的 UTF-8 字节流。
- Navicat：右键快捷方式 → 属性 → 快捷方式 → 目标栏末尾追加
--env=LANG=en_US.UTF-8（前面空一格） - Navicat Premium 16+：菜单「工具」→「选项」→「环境」→ 勾选
Use UTF-8 for file encoding - Compass：无全局编码设置，靠系统终端环境；Windows 用户可在启动 Compass 前运行
chcp 65001 - 验证方法：直接用
mongosh连接执行db.collection.findOne()，中文正常 → 说明服务端和驱动都没问题
mongoimport 导入 CSV 出现乱码
导入工具没声明源文件编码，就把 GBK 编码的 CSV 当 UTF-8 解析，导致入库字节错乱。
- 先确认源文件真实编码：
file -i data.csv（Linux/macOS）或用 VS Code 查看右下角编码标识 - 若为 GBK，先转 UTF-8：
iconv -f GBK -t UTF-8 data.csv > data_utf8.csv - 导入命令必须指定
--encoding UTF-8：mongoimport --db test --collection users --file data_utf8.csv --type csv --headerline --encoding UTF-8 - 注意：
--encoding参数只影响文件读取阶段，不改变 BSON 存储格式 —— MongoDB 始终存 UTF-8
最容易被忽略的是：乱码往往跨多个环节，但每个环节只负责自己那段编码转换。你得逐层验证 —— 文件编码、程序读取方式、驱动传输行为、客户端解码逻辑 —— 不能只改一处就以为全好了。
