csv乱码与定时任务无关，根源在于导出配置未设utf-8 with bom编码及引号包裹、lf换行等参数，需在导出向导高级选项中显式设置并保存生效。
定时任务导出CSV乱码，根本不是“定时”惹的祸
Navicat 的「计划任务」本身不参与编码决策，它只是按你保存的导出配置（即“导出向导”里设好的参数）自动执行一次。所以乱码和“定时”无关，而是你当初手动导出时没配对编码，任务照搬错误配置而已。真正要改的是那个被保存下来的导出设置，不是调度逻辑。
导出配置里必须显式选“UTF-8 with BOM”，不能信默认值
在创建或编辑该定时任务关联的导出任务时，进入「高级选项」→ 找到「编码」下拉框：
• 必须选 UTF-8 with BOM（部分旧版本显示为 UTF-8-BOM），
• 不能选 UTF-8（它等价于无 BOM），
• 更不能留空或依赖 Auto。
Windows 版 Excel、macOS Numbers、甚至某些 Python 脚本，都靠开头的 EF BB BF 字节识别 UTF-8；没这个头，它们就按系统默认（GBK 或 Latin-1）硬解，中文必然变 æ个 或 ??? 。
字段含换行/逗号时，引号和换行符必须同步设对
定时导出若涉及地址、备注等含 \n 或 , 的字段，光调编码不够，还得防解析错位：
• 勾选 Enclose fields in quotes（用双引号包裹字段），
• 在「高级选项」底部把 Line ending 显式设为 Unix (LF)，别用 Default；
• 字段分隔符保持 ,，文本限定符保持 "。
否则即使编码正确，下游工具（如 pandas read_csv()）读到字段内 \n 会直接切行，数据整列偏移——看着像乱码，其实是结构塌了。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
连接层字符集对导出无效，别白调
很多人去「编辑连接」→「高级」里反复改 character_set_client 或加 SET NAMES，这完全不影响 CSV 导出。导出走的是独立的客户端编码路径，只认导出向导里那个「编码」下拉框。数据库连接用的是 utf8mb4，不代表导出文件就是 UTF-8；反过来，导出选了 UTF-8 with BOM，但源数据在查询阶段就被 latin1 连接污染了（比如 character_set_results 是 latin1），那文件开头再多个 BOM 也没用——字节流本身已是乱码。
最容易被忽略的一点：定时任务不会自动刷新导出配置。你改完编码或引号设置后，必须点「保存」或「更新任务」，否则下次跑的还是旧配置。验证方式很简单：临时取消定时，手动运行一次该任务，然后用 head -n 1 your_file.csv | xxd（macOS/Linux）或 certutil -hashfile your_file.csv MD5 配合十六进制查看器确认 BOM 是否真实写入。
