根本原因是客户端、连接层、服务端字符集不一致；需在Navicat连接高级设置中手动指定utf8mb4，SSH隧道下补充LANG环境变量，导入SQL前确认文件编码并执行SET NAMES utf8mb4。
Navicat 连接 Linux MySQL 时中文显示为问号或乱码
根本原因是客户端、连接层、服务端三者字符集不一致，navicat 默认用 latin1 或系统 locale 发送请求，而 linux 上的 mysql 服务端常配为 utf8mb4，但连接未显式声明编码，导致中间环节丢字节。
实操建议：
- 在 Navicat 新建连接时，点击「高级」选项卡 → 勾选「使用 MySQL 字符集」→ 在「字符集」下拉框中手动选
utf8mb4 - 若已建好连接，右键编辑 → 「高级」→ 修改字符集并「测试连接」，成功后务必点「确定」保存（只点「测试」不保存设置）
- 连接成功后，执行
SHOW VARIABLES LIKE 'character_set%';确认character_set_client、character_set_connection、character_set_results全部是utf8mb4 - 避免依赖「自动检测」——Navicat 的自动检测在 SSH 隧道或跳板机场景下大概率失效
通过 SSH 隧道连接时中文仍乱码
SSH 隧道本身不处理字符编码，但 Navicat 会复用本地终端的环境变量（如 LANG），若 Linux 服务器的 shell 环境没设 UTF-8，Navicat 可能误判连接层编码。
实操建议：
- 登录服务器，检查
locale输出中LANG是否含UTF-8（例如en_US.UTF-8），不是则临时设置：export LANG=en_US.UTF-8 - 更稳妥的是在 Navicat 的 SSH 设置页 → 「环境变量」区域，手动添加：
LANG=en_US.UTF-8和LC_ALL=en_US.UTF-8 - 不要依赖服务器全局
/etc/locale.conf—— Navicat 的 SSH 子进程不一定读它
Navicat 导入 SQL 文件后中文变问号
导入动作绕过了连接时的字符集协商，Navicat 会按文件自身 BOM 或默认编码读取内容，再以当前连接字符集写入。若文件是 UTF-8 无 BOM，但 Navicat 误判为 GBK，就会双倍错乱。
实操建议：
- 导入前先确认 SQL 文件真实编码：用 VS Code 或 Sublime 打开，右下角看编码标识；Linux 下可用
file -i your.sql - 在 Navicat「运行 SQL 文件」窗口中，点击右上角「编码」按钮，明确选
UTF-8（不是「自动」） - 导入前执行一次
SET NAMES utf8mb4;，确保本次会话的 client/connection/results 三者对齐 - 如果原 SQL 文件含
SET NAMES latin1这类语句，必须手动删掉，否则会覆盖连接层设置
多设备切换（Windows/Mac/Linux 客户端）时乱码重现
不同系统默认字体、终端 locale、Navicat 版本内置编码策略有差异。Mac 版 Navicat 有时默认用 utf8（非 utf8mb4），而 Windows 版可能继承控制台代码页（如 GBK）。
实操建议：
- 所有设备统一在连接「高级」页强制指定
utf8mb4，不依赖系统默认 - 禁用 Navicat 的「从操作系统获取字符集」选项（该选项在 Mac 上易读成
UTF-8，但 MySQL 实际要求utf8mb4） - 导出数据时，勾选「导出为 UTF-8 编码」并加 BOM（兼容性更好）；导入时也优先选带 BOM 的 UTF-8
- 别共享 .ncx 连接配置文件——不同系统下路径、字体、编码策略字段可能被静默改写
最容易被忽略的是：MySQL 5.7+ 默认 character_set_server=utf8mb4，但老版本或 Docker 镜像可能仍是 latin1，连对了客户端也没用。每次换环境，先 SELECT @@character_set_server; 看一眼。
