Navicat中SQLite中文乱码的主因是连接编码未设为Auto，应将Encoding设为Auto而非UTF-8；其次检查绝对路径是否被空格或中文截断；导出SQL时须手动勾选Use UTF-8 encoding；查询窗口显示方块则是字体不支持中文所致。
Navicat里SQLite中文显示乱码，先看连接编码是不是Auto
navicat对sqlite的编码处理很特殊：它不走mysql那种character_set_client协商机制，也不依赖数据库文件本身的pragma encoding设置。实际生效的是连接配置里的encoding下拉框——而**唯一稳定兼容utf-8中文的选项是auto**。
填UTF-8反而容易乱码，尤其在macOS上（Navicat Premium 17.x已验证）。这是因为SQLite驱动在UTF-8模式下会强制做一次冗余转码，把原本正确的UTF-8字节流当GBK解再重编，结果双乱。
- 新建连接时，
Encoding必须选Auto，别碰UTF-8、GBK等具体编码项 - 已有连接乱码？右键连接 →
Edit Connection→ 修改Encoding为Auto→ 保存并重新连接 - 如果连
Auto都无效，说明数据本身可能存的就是GBK（极少见），需用sqlite3命令行确认：sqlite3 your.db "PRAGMA encoding;"
SQLite文件路径含中文或空格，Navicat会截断后半段
Navicat内部路径处理链（Qt QString → sqlite3_open_v2）不加引号直接传参，遇到空格或中文就丢掉后面部分。比如C:\我的项目\data.db可能只读到C:\我的项目\data，然后静默创建一个新空库，你看到的“乱码”其实是新库的默认schema。
- Windows：右键文件 →
属性→ 复制位置栏完整路径，手动拼上文件名（如C:\Users\Alice\我的项目\data.db） - macOS/Linux：终端执行
realpath /path/to/你的.db，复制输出结果 - 验证路径有效性：在终端运行
ls -l "粘贴的完整路径"，确保返回真实文件信息
导出SQL时中文变问号，是因为导出向导没设UTF-8编码
Navicat 17的SQLite导出向导默认用系统编码（Windows是GBK，macOS是UTF-8但不显式声明），导出含中文的INSERT语句时，若目标环境是MySQL/PostgreSQL，就会因编码声明缺失导致问号。
- 导出时进入
格式设置页 → 找到Export Options区域 → 勾选Use UTF-8 encoding（不是“Auto”，必须明确打钩） - 生成的
.sql文件开头应有-- Encoding: UTF-8注释，没有则说明没生效 - 若导出后仍乱码，用VS Code打开该SQL文件，右下角确认编码显示为
UTF-8 with BOM或UTF-8，不是GBK或ISO-8859-1
表里中文正常，但Navicat查询结果窗口显示方块，是字体问题
这和数据库无关，纯属Navicat UI渲染缺陷。它用系统默认等宽字体渲染查询结果，而某些中文字体（如Windows的Consolas、macOS的SF Mono）缺中文字符集，就画方块。
- macOS：Navicat →
Preferences→Fonts→ 把Grid Font改成Menlo或Monaco - Windows：同路径 → 改成
Microsoft YaHei Mono或NSimSun - 改完重启Navicat，方块立刻变中文——注意这不是乱码，只是字体没覆盖汉字区间
Navicat连SQLite的乱码问题，八成卡在Encoding=Auto没设对，剩下两成是路径截断或导出编码漏勾。真正难排查的是字体渲染问题，它看起来像乱码，实际数据完全正常。
