根本原因是mac版navicat默认导出utf-8无bom，而windows excel（2019及更早）不识别，误按gbk解码致乱码；必须在导出向导中明确选择“utf-8 with bom”，并用hexdump验证ef bb bf存在，且需通过excel“数据→从文本/csv”手动导入并指定utf-8编码。
mac版navicat导出的csv在windows上打开乱码，根本原因不是“跨平台不兼容”，而是**编码声明缺失 + windows excel默认解析逻辑不同**：mac版navicat默认导出的是utf-8（无bom），而windows版excel（尤其2019及更早）完全不识别无bom的utf-8，直接按系统ansi（通常是gbk）解码字节流——结果就是“æ个æ±å”这类典型乱码。
导出时必须选UTF-8 with BOM，不能只信“UTF-8”选项
Navicat for Mac 的导出向导里，“编码”下拉菜单中UTF-8和UTF-8 with BOM是两个独立选项：
-
UTF-8= 无BOM，纯字节流，Mac Numbers/Excel for Mac靠BOM识别，Windows Excel则无视它 -
UTF-8 with BOM= 文件开头写入EF BB BF三字节，Windows Excel（2016+）会据此强制用UTF-8解码 - 部分老版本（v15.0.30之前）菜单里不显示
UTF-8 with BOM，只显示UTF-8-BOM或Unicode (UTF-8)，选那个即可 - 如果菜单里根本没有带BOM的选项，说明版本太旧，升级到v17.0+是最省事的解法
别被“文件名”或“Navicat界面提示”骗了，用hexdump验证BOM真实存在
很多人点了UTF-8 with BOM就以为万事大吉，但实际导出文件可能仍是无BOM——常见于插件冲突、缓存未刷新或导出中途异常中断。
- 终端执行：
hexdump -C your_file.csv | head -n 1 - 输出首行是
00000000 ef bb bf→ BOM真实存在 ✅ - 输出首行是
00000000 e6 9d ad（“杭”的UTF-8编码）→ 仍是无BOM ❌，Excel必然乱码 - 不要用文本编辑器“另存为UTF-8 with BOM”来补救：如果原始导出时数据库连接字符集是
latin1或GBK，那文件内容本身已是错的，加BOM只是给错误编码“贴标签”
Windows端打开方式比编码选择更重要
即使你导出了带BOM的UTF-8 CSV，双击打开依然大概率乱码——因为Windows资源管理器调用的是系统默认CSV关联程序（通常是Excel），而它走的是ANSI fallback路径，压根不读BOM。
- 正确做法：打开Excel → 数据 → 从文本/CSV → 选择该文件 → 在导入预览界面右下角手动选
UTF-8 - 务必关闭“自动检测分隔符”，手动确认字段分隔符是
,、文本限定符是" - 如果导入后仍有乱码，问题不在Excel端，而在Navicat导出前：检查数据库连接属性里的
character_set_client和character_set_results是否设为utf8mb4；否则源数据从MySQL读出来就已经是乱码字节
真正容易被忽略的点：Mac版Navicat的“连接字符集”设置对CSV导出完全无效，它只影响SQL查询时的通信协议；导出编码唯一生效位置，只有导出向导里的高级 → 编码。哪怕你把整个MySQL服务都设成utf8mb4，只要这里没选对UTF-8 with BOM，Windows用户拿到的就是一份“看起来正确、实际无法直读”的文件。
