表结构显示乱码不是数据损坏，而是Navicat用错误字符集解码元数据；必须手动设连接层编码为utf8mb4（MySQL/MariaDB）或client_encoding=UTF8（PostgreSQL），禁用Auto，配合SET NAMES utf8mb4初始化命令，并重新连接生效。
表结构显示乱码（如表名、字段名、注释变成???或æ）不是数据坏了，而是 navicat 解码元数据时用了错误字符集——必须手动指定连接层编码为 utf8mb4，不能依赖 auto。
MySQL / MariaDB：改连接高级设置 + 强制初始化命令
Auto 字符集在 Navicat 里会 fallback 到 latin1 或 gbk，但 MySQL 5.5.3+ 默认用 utf8mb4 存表名和注释，字节一错位就全乱。
- 右键连接 →「编辑连接」→「高级」→ 找到「MySQL 字符集」下拉框，选
utf8mb4（注意不是utf8，也不是UTF-8） - 勾选「使用初始化命令」，填入：
SET NAMES utf8mb4;（这条同步设character_set_client、connection、results） - 改完必须重新连接，否则不生效；如果连接后执行
SHOW VARIABLES LIKE 'character_set_client';仍返回latin1，说明设置没生效 - 旧版 Navicat 若无该下拉框，在「其他选项」里加：
characterEncoding=utf8mb4
PostgreSQL：补 client_encoding 参数 + 检查数据库实际编码
PostgreSQL 不走字符集自动协商，Navicat 连接字符串里漏了 client_encoding，就会按系统 locale（比如 Windows 的 GBK）去解 UTF-8 元数据。
- 编辑连接 →「SSH/SSL」页签 → 在「连接字符串」末尾追加：
options=-c%20client_encoding%3DUTF8（URL 编码不能错） - 或者在「运行前执行命令」里填：
SET client_encoding TO 'UTF8'; - 先确认数据库本身是 UTF8：
SELECT pg_encoding_to_char(encoding) FROM pg_database WHERE datname = current_database();，如果不是，重建库 - 避免用
ALTER DATABASE SET client_encoding—— 这个语句无效，PostgreSQL 不支持运行时改 client_encoding
SQLite：手动指定 Character set，别信 Auto
SQLite 文件没内置强制编码声明，Navicat 默认按 UTF-8 解，但如果建库时用的是 GBK 工具（如旧版 DB Browser），字节就是 GBK 编码的，硬解必乱。
- 编辑连接 →「高级」→ 找到
Character set下拉框，选UTF-8（不是Auto，也不是GBK） - 若仍乱码，用命令行验证：
sqlite3 your.db→ 执行PRAGMA encoding;，看返回值是否为"UTF-8" - 更可靠方式：用十六进制查看器打开 .db 文件，找中文字段对应位置，看字节是否以
E4–E9开头（UTF-8 中文特征） - 如果确认是 GBK 存的，不要强行在 Navicat 里设 UTF-8，得用工具导出再以 UTF-8 重导入
MongoDB：绕过 UI，改启动环境变量
MongoDB 本身不涉及字符集配置，乱码纯属 Navicat 在 Windows 下用 GBK 解 UTF-8 BSON 字符串。连接配置界面里根本找不到字符集选项。
- Windows 用户：右键 Navicat 快捷方式 →「属性」→「快捷方式」→ 在「目标」末尾加空格 +
--env=LANG=en_US.UTF-8 - 或用命令行启动：
cmd /c "set PYTHONIOENCODING=utf-8 && start navicat.exe" - Navicat Premium 16+ 可试「工具」→「选项」→「环境」→ 勾选
Use UTF-8 for file encoding - 验证真伪：用
mongosh连同一库执行db.collection.findOne()，中文正常 → 就是 Navicat 渲染问题，不是数据问题
表结构乱码一旦发生，改连接只能解决后续新建对象的显示；已存在的乱码表名不会自动修复，因为 information_schema 里存的就是错解后的字节。这时候得靠 RENAME TABLE 用正确编码重命名，或者导出建表语句手动修正后再重建。
