navicat定时任务导出csv必须显式设置编码为utf-8 with bom，因其不继承手动导出配置，默认值常为utf-8（无bom）或系统默认编码，导致excel/numbers打开乱码；需在自动化任务编辑页→导出→高级选项中手动选择“utf-8 with bom”，并验证文件开头字节为ef bb bf。
定时任务导出 CSV 用的是哪个编码？
Navicat 定时任务（Automated Task）导出 CSV 时，不继承你在手动导出向导里设置的「UTF-8 with BOM」偏好——它只认任务配置里**显式指定**的编码，且默认值极可能是 UTF-8（无 BOM）或 System Default（Windows 下常为 GBK，macOS 下常为 UTF-8 无 BOM）。这就是为什么手动导出正常、定时导出全乱的根本原因。
验证方法：导出一个定时任务生成的 CSV 文件，用终端执行：hexdump -C your_file.csv | head -n 1
若开头不是 ef bb bf，说明没写 BOM；若开头是 ff fe 或 fe ff，说明被误存成 UTF-16；若直接是中文 UTF-8 字节（如 e6 9d ad），就是纯 UTF-8 无 BOM —— Excel/Numbers 打开必乱。
- 进入「自动化任务」编辑页 → 点击「导出」操作 → 展开「高级」选项卡
- 必须手动点开「编码」下拉框，**明确选中
UTF-8 with BOM**（v17+ 显示为该名称；v15 可能叫UTF-8-BOM） - 不要依赖「自动检测」或留空，默认值不可信
- 如果下拉菜单里根本没有
UTF-8 with BOM，说明版本太老（
定时导出时「文本限定符」没设对，也会假性乱码
CSV 里含中文地址、备注等字段时，若内容本身含逗号、换行或双引号，而定时任务又没启用文本限定符，Navicat 会把一行切碎，导致后续所有列整体右移。看起来像“字段错位”或“部分中文变方块”，实则是解析错位引发的连锁错误。
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 在同一个「高级」选项卡中，确认「文本限定符」填的是
"（英文双引号） - 勾选「使用文本限定符」——这个选项在定时任务里默认常为关闭状态
- 检查源数据：用 Notepad++ 打开原始 CSV，搜索
"和换行是否成对；不成对就说明导出时没包裹，必须补限定符
目标表字符集不匹配，让乱码“延迟发作”
即使定时导出的 CSV 文件本身编码正确（有 BOM、字段包裹完好），但如果导入的目标表用的是 latin1 或旧版 utf8（非 utf8mb4），中文插入后立刻变成 ??? 或报 Incorrect string value。这种乱码不会在 CSV 文件里体现，而是在数据库里“长出来”，容易误判为导出环节问题。
- 执行：
SHOW CREATE TABLE your_table;，确认末尾有DEFAULT CHARSET=utf8mb4 - 若没有，建表时补全：
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci - 对已有表可修改：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 注意：
character_set_server不影响定时导出，但影响新表默认字符集，建议一并检查：SHOW VARIABLES LIKE 'character_set_server';
Mac 上定时导出的 CSV 更难识别编码
macOS 的 Numbers 和 Excel for Mac 对 BOM 的识别比 Windows 更脆弱：它们虽支持 BOM，但某些版本（尤其 v12 以前）在文件头有 BOM 时仍可能回退到 Mac OS Roman 解码。此时即使你选了 UTF-8 with BOM，打开还是显示 æ些 这类乱码。
- 导出后立即用命令验证 BOM 是否真实写入：
hexdump -C file.csv | head -n 1 - 若已确认有 BOM 但依然乱码，临时方案是用
sed强制加 BOM 并统一换行：tr '\r' '\n' fixed.csv - 终极解法：改用
.xlsx格式导出（定时任务支持），绕过所有编码协商环节，Native 支持 Unicode
