Navicat 16导出CSV必须勾选“UTF-8 with BOM”，否则Windows版Excel因无法识别UTF-8编码必然显示中文乱码；同时需设字段分隔符为逗号、文本限定符为英文双引号、勾选包含列标题，并确保数据库连接与表字符集为utf8mb4。
navicat 16 导出 csv 时必须手动勾选「utf-8 bom」，否则 excel 打开中文就是乱码或问号——这不是文件内容问题，是 excel 根本没认出这是 utf-8。
导出向导里「编码」下拉菜单选 UTF-8 ≠ 带 BOM
Navicat 16 的「格式设置」页中，「编码」下拉框里有两项容易混淆：UTF-8 和 UTF-8 with BOM。选前者导出的是纯 UTF-8（无 BOM），Excel 在 Windows 上默认按 ANSI（即 GBK）解析，中文立刻变乱码；只有选后者，文件开头才写入 EF BB BF 三个字节，Excel 才会主动识别为 UTF-8 并正确显示。
- Windows 版 Excel（含 Microsoft 365）对无 BOM 的 UTF-8 文件完全不识别，不是“偶尔错”，是“必然错”
- macOS 或 Linux 下的 LibreOffice / WPS 可能正常，但这不代表导出设置对了
- 别信「自动检测」——Navicat 的自动检测在 CSV 场景下基本失效，尤其含中英文混合字段时
导出 SQL 文件时反而要避开 BOM
导出 .sql 文件（比如结构或数据脚本）时，UTF-8 with BOM 可能导致执行失败。BOM 字节会被当作文本内容插入到 SQL 开头，使第一行变成 SET NAMES utf8mb4;，MySQL 直接报语法错误。
- SQL 文件应选
UTF-8（无 BOM），这是 VS Code、Sublime、Notepad++ 等编辑器的默认保存行为 - 若你用 Windows 记事本另存为「UTF-8」，它默认带 BOM，此时才需选
UTF-8 with BOM——但更建议换编辑器重存 - 不确定是否有 BOM？用命令行验证：
xxd your.sql | head -1，开头是00000000: efbb bf...就带 BOM
导出 CSV 时 BOM 必须和分隔符、限定符配合使用
只勾选 BOM 不够，CSV 结构本身也得稳住。Navicat 导出对话框点「高级」后，这三个设置必须同步确认：
-
字段分隔符设为,（逗号），别用;或\t，国内多数工具不兼容分号分隔 -
文本限定符设为"（英文双引号），否则含换行、逗号的字段会破坏整行结构 -
包含列标题勾选，否则中文列名可能被当成乱码丢弃（尤其连接字符集非 utf8mb4 时）
真正容易被忽略的是：BOM 只解决 Excel 读取阶段的编码识别问题，它不改变字段内容本身。如果源表字段值已经是 GBK 编码存的乱码，加 BOM 也救不回来——得先统一数据库连接与表的字符集为 utf8mb4，再导出。
