Navicat打开本地.sql文件中文显示为问号或方块，根本原因是默认用错误编码读取文件（如将UTF-8无BOM误判为GBK）；需用VS Code状态栏或file -i命令确认真实编码，再通过“重新以编码打开”手动指定，或设默认编码为UTF-8并勾选“新建查询时使用默认编码”，但该设置不覆盖已有文件的自动判断。
Navicat 打开本地 .sql 文件后中文显示为问号或方块，**不是文件损坏，也不是字体问题，而是它默认用错误编码读取了文件内容**。Windows 中文版下尤其常见：记事本保存的 UTF-8 文件（无 BOM）常被 Navicat 误判为 GBK，一打开就乱。
怎么确认文件真实编码？
别猜，直接验证：
- 用
VS Code打开该文件，右下角状态栏看当前编码（如UTF-8或GBK） - macOS/Linux 下运行：
file -i your.sql，输出含charset=utf-8或charset=gbk - 若用 Windows 记事本另存过，大概率是
UTF-8 with BOM（开头有）
怎么让 Navicat 正确打开这个文件？
两种方式，按需选：
- 临时修复：右键已打开的 SQL 标签 →「重新以编码打开…」→ 选和文件真实编码一致的项（如
UTF-8或GBK） - 永久生效：菜单栏
工具 → 选项 → 常规 → 默认编码改为UTF-8，并勾选「新建查询时使用默认编码」 - 注意：
自动检测功能不可靠，尤其对 UTF-8 无 BOM 文件，90% 会误判成 GBK
为什么改了默认编码，新打开的文件还是乱？
因为 Navicat 的「默认编码」只影响新建查询窗口和部分导入行为，**不强制覆盖已有文件的编码猜测逻辑**。它仍会基于文件头、字节分布做独立判断——这也是为什么你改完设置，双击打开旧文件依然乱。
- 真正起作用的是「重新以编码打开…」这个手动动作
- 如果频繁处理外部传来的 SQL 文件，建议统一用
Notepad++或VS Code先转成UTF-8 with BOM再交给Navicat，BOM 能显著提升识别准确率 - 别依赖「编辑器显示正常就等于能执行正确」——显示没问题，但执行时若连接层仍是
latin1，INSERT 还是会报Incorrect string value
