Mac上Navicat导出CSV中文乱码的根源是默认UTF-8（无BOM）编码与macOS工具（Numbers/Excel）不识别UTF-8 BOM导致的解码错误，必须手动选择“UTF-8 with BOM”并验证BOM存在方可解决。
Mac上Navicat导出CSV中文乱码的根源是编码默认值不匹配
navicat for mac 默认导出编码是 utf-8（无 bom），而 macos 自带的 numbers 或 excel for mac 在打开 csv 时，**不依赖 bom 识别 utf-8**，而是按系统区域设置回退到 iso-8859-1 或 mac os roman 解码。结果就是“æ些æå”这类典型乱码——utf-8 字节被当拉丁字符解析了。
这和 Windows 版 Navicat 的问题表象类似，但机制不同：Windows 下 Excel 依赖 BOM；macOS 下多数工具直接忽略 BOM，靠文件内容或元数据猜编码，而 Navicat 导出时不写任何编码声明（如 charset=utf-8 HTTP header），导致消费端完全“盲猜”。
导出时必须手动选“UTF-8 with BOM”才可能被 Numbers/Excel 正确识别
虽然 macOS 系统本身对 BOM 不敏感，但 Numbers（v12+）和 Excel for Mac 2021/365 在检测到文件开头有 EF BB BF 时，会优先采用 UTF-8 解码——这是目前最稳定、无需额外工具的方案。
- 导出向导 → 格式选
CSV→ 点「高级」→ 找到「编码」下拉菜单 - 不要选
UTF-8（它等价于无 BOM），必须选UTF-8 with BOM（部分版本显示为UTF-8-BOM） - 若下拉菜单里没有该选项，说明你用的是较老版本（
v15.0.30之前），建议升级到v17.0+ - 确认「文本限定符」设为
"，否则含换行或逗号的中文字段（如地址“杭州市,西湖区”）会错切列
用终端快速验证导出文件是否真含 BOM
别信文件名或 Navicat 界面提示，直接看字节。在 Terminal 中执行：
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
hexdump -C your_file.csv | head -n 1
如果输出首行是 00000000 ef bb bf ...，说明 BOM 存在；如果是 00000000 e6 9d ad ...（即中文“杭”的 UTF-8 起始字节），说明仍是无 BOM 的纯 UTF-8，Excel/Numbers 必然乱码。
- 若没 BOM 但又无法重导，可用命令补：
sed '1s/^/\xef\xbb\xbf/' your_file.csv > fixed.csv - 注意：此操作仅适用于纯文本 CSV，若文件含 Windows 换行符
\r\n，需先统一为\n再加 BOM，否则某些工具会把\r当作内容解析 - 避免用 TextEdit 打开再另存——它默认保存为
Unicode (UTF-16)或Mac OS Roman，反而更糟
真正容易被忽略的点：Navicat 连接层字符集不影响导出编码
很多人调了半天连接属性里的「字符集」（如把 character_set_client 改成 utf8mb4），但导出 CSV 时这个设置完全不生效。导出走的是独立的客户端编码路径，和数据库通信协议无关。
唯一影响导出编码的地方只有导出向导里的「高级 → 编码」选项。即使你的 MySQL 表是 utf8mb4、Navicat 连接也设了 utf8mb4，只要导出时没勾 UTF-8 with BOM，Mac 上打开照样乱码。
