Navicat Linux版打开.sql文件显示问号或方块，根本原因是其默认用系统locale（如zh_CN.GBK）猜测文件编码，而SQL文件多为UTF-8无BOM，导致误判为GBK或ISO-8859-1；须右键选“重新以编码打开…→UTF-8”，并设默认编码为UTF-8、勾选“新建查询时使用默认编码”，同时配置连接初始化命令SET NAMES utf8mb4、表字符集为utf8mb4、结果网格字体为Noto Sans CJK SC等，四层编码与字体统一方可解决。
Navicat Linux版打开.sql文件显示问号或方块
根本原因是 navicat for linux 默认用系统 locale 编码（如 zh_cn.gbk 或 en_us.utf-8）猜测文件编码，而你手里的 sql 文件大概率是 utf-8 无 bom —— 它不带 bom 头，navicat 就容易误判为 gbk 或 iso-8859-1，一打开就全乱。
实操建议：
- 右键已打开的 SQL 文件标签 → “重新以编码打开…” → 显式选
UTF-8（不是“自动检测”，也不是GBK） - 永久生效：菜单栏 工具 → 选项 → 常规 → 默认编码 改为
UTF-8；同时勾选“新建查询时使用默认编码” - 若文件来自 Windows 记事本，它实际是
UTF-8 with BOM，此时要选UTF-8 with BOM，否则开头三字节会被当普通字符解析 - 不确定原始编码？终端执行
file -i your_script.sql，看输出里charset=后面是什么
执行后 INSERT 中文报 ERROR 1366 或显示 ??
编辑器能正常显示中文 ≠ 执行时不出乱码。Linux 下 Navicat 连接 MySQL 时，默认仍可能协商 latin1，导致服务端把 UTF-8 字节流当 latin1 解析，存进去就是错的字节。
必须同步做三件事：
- 编辑连接 → “高级” → “初始化命令”栏填入：
SET NAMES utf8mb4; - 确认目标表字段定义含
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci（不是utf8，MySQL 的utf8是残缺版） - 执行
SELECT @@character_set_client, @@collation_connection;，返回值必须都是utf8mb4相关，否则初始化命令没生效
结果网格里中文显示为空格或小方块
这是字体 fallback 导致的渲染失败，不是编码问题。Linux 下 Navicat 默认用 DejaVu Sans 等西文字体，遇到中文就找不到字形，直接画空格或方块。
解决方法很直接：
- 菜单栏 工具 → 选项 → 界面 → 字体 → 把“结果网格字体”改成支持中文的字体，例如：
Noto Sans CJK SC、WenQuanYi Micro Hei或Source Han Sans SC - 改完必须完全退出 Navicat（不只是关窗口），再重开才生效
- 额外检查系统 locale：
locale | grep -E "LANG|LC_CTYPE"，如果不是zh_CN.UTF-8或类似 UTF-8 locale，界面控件本身也可能乱码
导出的 SQL 文件在其他工具里打开又乱了
Navicat 导出时若没指定编码，会按系统 locale 写入，比如导出成 GBK，你用 VS Code 打开就崩；或者导出成 UTF-8 无 BOM，但别人用 Excel 双击就全是方块——这不是文件坏了，是解码链断了。
导出时务必注意：
- 导出向导最后一步，“编码”下拉框明确选
UTF-8（不是Unicode，不是留空） - 取消勾选“添加 CREATE DATABASE 语句”，除非你手动确保语句里写了
CHARACTER SET = utf8mb4 - 导出后立刻用
file -i your_export.sql验证实际编码，别信界面上写的“UTF-8” - 如果要给 Excel 用户用，导出后用
iconv -f utf-8 -t utf-8-bom your_export.sql -o your_export_bom.sql补 BOM
真正卡住人的从来不是单点配置，而是「文件保存编码」、「Navicat 打开时用的编码」、「连接初始化声明的编码」、「服务端表结构编码」这四层里有一层没对齐 —— 尤其在 Linux 下，locale 和字体这两环最容易被跳过。
