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，就会因编码声明缺失导致问号。

navicatmysql

Navicat For MySQL

下载

• 导出时进入格式设置页 → 找到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没设对，剩下两成是路径截断或导出编码漏勾。真正难排查的是字体渲染问题，它看起来像乱码，实际数据完全正常。