必须勾选utf-8 with bom，因navicat 17默认导出utf-8 without bom，windows excel/wps无bom时回退gbk解码，导致emoji和中文乱码；同时需确保连接层设utf8mb4、字段用双引号包裹、避免gui导出大数据量emoji表。
导出时选了 utf-8 但 emoji 和中文仍乱码？必须勾选 bom
navicat 17 默认导出的 utf-8 实际是 utf-8 without bom，而 windows excel、wps 等工具在无 bom 的情况下会回退到 gbk 解码，导致 emoji（如 ?、✅）和中文全部变成 æ–‡å— 或 ???? 这类字节级错解。这不是数据损坏，是消费端根本没用对编码读取。
解决方法非常直接：
- 在「导出向导」→「格式选项」页，点击右下角
高级按钮 - 找到
编码下拉框，**不要选UTF-8**，而是选UTF-8 with BOM（部分界面显示为UTF-8 + BOM） - 确保
文本限定符设为"（双引号），否则含换行或逗号的 emoji 字段会破坏 CSV 结构
导出后 Excel 里显示 或方块？检查字段分隔符和换行符是否被误解析
即使编码正确，CSV 中若存在未包裹的换行符（比如地址字段含 \n）或未转义的逗号（如“杭州,西湖区”），Navicat 仍会按原始分隔规则切行，导致后续所有列偏移——看起来像乱码，实则是字段错位。
验证与修复建议：
- 用
Notepad++或VS Code打开导出的 CSV，开启「显示所有字符」（¶和↵），确认换行符是否出现在非预期位置 - 若源字段含逗号/换行，导出前改用 SQL 查询模式，手动包裹字段：
SELECT CONCAT('"', REPLACE(address, '"', '""'), '"') AS address FROM table - 避免使用
;或\t作分隔符——Navicat 17 对非逗号分隔符的兼容性不稳定，尤其含 emoji 时更易触发解析异常
数据库连接层字符集不匹配也会透传到导出结果
Navicat 导出 CSV 时，底层走的是当前连接的字符集通道。如果连接属性中没设对，即使导出选了 UTF-8 with BOM，中间环节已发生一次错误转码，BOM 也救不回来。
关键检查点：
- 右键连接 →
编辑连接→高级页签 → 勾选使用 MySQL 字符集（MySQL）或手动填入utf8mb4 - 对 PostgreSQL，确认
client_encoding在连接参数中显式设为utf8 - 执行
SHOW VARIABLES LIKE 'character_set%';（MySQL）或SHOW client_encoding;（PG），确保character_set_client/client_encoding返回值是utf8mb4或utf8，不是latin1或空
导出含 emoji 的大数据量表时卡死或截断？绕过 GUI 直接用 mysqldump
Navicat 17 GUI 导出超过 5 万行且含 emoji 时，内存占用陡增，常出现假死、字段截断（如 ? 变成 ）、或导出文件末尾缺失 BOM 头——这是其 GUI 层缓存机制与多字节字符处理的已知瓶颈。
更稳的替代路径：
- 在 Navicat 查询窗口运行：
SELECT * FROM your_table INTO OUTFILE '/tmp/export.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' CHARACTER SET utf8mb4;（需 MySQL 有FILE权限） - 或调用命令行：
mysqldump -h host -u user -p --no-create-info --fields-terminated-by=',' --fields-optionally-enclosed-by='"' --lines-terminated-by='\n' --default-character-set=utf8mb4 db_name table_name > export.csv - 导出后用
file -i export.csv（Linux/macOS）或 PowerShellGet-Content export.csv -Encoding UTF8 -TotalCount 1验证 BOM 是否存在（开头应为EF BB BF）
BOM 不是可选项，是 Windows 生态下让 Excel 正确识别 UTF-8 的强制握手信号；而 emoji 的四字节特性（需要 utf8mb4）决定了从数据库连接、查询、导出到最终打开，每个环节都必须显式声明，不能依赖“自动”或“默认”。
