根本原因是Windows版Navicat默认用UTF-8无BOM导出，而Linux终端或编辑器未显式指定编码时误判为ISO-8859-1，导致中文显示为问号；需用file -i确认编码，VS Code中重存为UTF-8（无BOM）或UTF-8 with BOM，并确保MySQL表字符集为utf8mb4、连接初始化执行SET NAMES utf8mb4。
Navicat导出SQL文件在Linux打开全是问号
根本原因是windows版navicat默认用utf-8无bom导出，而linux终端或编辑器（如vim、nano）若未显式指定编码，会按locale默认编码（如en_us.utf-8）尝试解析——但一旦文件开头没bom，部分工具就误判为iso-8859-1，中文立刻变???。
- 用
file -i backup.sql确认实际编码：输出含charset=utf-8才可信，别信后缀 - VS Code打开后右下角看编码标识，如果不是
UTF-8或显示UTF-8 with BOM，点它 →Save with Encoding→ 选UTF-8（无BOM）或UTF-8 with BOM（兼容Excel） - 绝对不要用Windows记事本另存：它会偷偷转成ANSI，且无法还原
- 批量处理用
iconv -f utf-8 -t utf-8//IGNORE input.sql > output.sql可过滤非法字节，但慎用——可能删掉真实数据
Linux版Navicat导入SQL时报Incorrect string value
错误信息Incorrect string value: '\xF0\x9F\x98\x80' for column说明MySQL服务端收到的是UTF-8四字节字符（如emoji），但表字段用的是utf8（即utf8mb3），不支持四字节。Navicat连接层没生效，导致插入时被截断。
- 检查连接属性 →
高级→ 必须勾选Use Unicode UTF-8，并在Initial command填SET NAMES utf8mb4; - 确认目标表已用
utf8mb4建好：SHOW CREATE TABLE t1;里字段定义要带CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 如果表已存在，
ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;必须执行，仅改连接没用 - Navicat导入弹窗里的「编码」下拉菜单只影响文件读取，不影响执行——哪怕选了UTF-8，没
SET NAMES照样失败
查询结果正常但导出CSV在Excel里是乱码
Navicat查出来的中文在界面里显示正确，导出CSV后双击用Excel打开却变成æ个æ±å，这是Windows Excel默认用ANSI（GBK）解析UTF-8文件导致的典型错位。
- 导出时在「导出向导」→「格式设置」中，编码必须选
UTF-8 with BOM（不是UTF-8无BOM） - 或者直接选预设模板
CSV for MS Excel，它内部自动加BOM - 别信「自动检测」：Navicat v16/v17在Linux下对BOM识别不稳定，手动指定更可靠
- 如果已导出无BOM文件，用VS Code打开 → 右下角编码 →
Reopen with Encoding→UTF-8→ 再Save with Encoding→UTF-8 with BOM
Navicat连OceanBase/PostgreSQL时注释乱码
数据字典导出PDF时字段注释为空或显示???，不是字体问题，而是Navicat读information_schema.columns.column_comment时，连接没强制UTF-8，服务端按默认字符集（如latin1）返回内容，一转就废。
- 连接属性 →
高级→Initial command填SET NAMES utf8mb4;（OceanBase）或SET client_encoding = 'utf8';（PostgreSQL） - PostgreSQL用户注意：
pg_description需pg_catalog权限，低权限账号查不到注释，换owner账号重连 - 达梦数据库要加连接参数
characterSet=utf8mb4，不能只靠初始化命令 - Navicat 17读取字段类型时会fallback到
varchar(255)，但注释乱码一定是连接层没设对，和类型映射无关
