Navicat导出的CSV在Linux脚本中报“line contains NULL byte”错误，根本原因是Windows下默认写入UTF-8 BOM（\xEF\xBB\xBF）和CRLF换行符，而Linux工具如awk、sed、csv.reader遇BOM即中断；解决需显式禁用BOM、设行结束符为LF，或改用mysqldump/psql等原生命令直接生成无BOM、纯LF的CSV。
navicat本身不支持linux服务端运行，所谓“linux环境下的定时任务”实际是：你在windows/macos桌面端用navicat手动导出csv，再把文件传到linux服务器上处理；或通过脚本调用navicat的命令行工具（仅windows/macos可用）生成csv，再scp到linux。真正的定时任务必须脱离navicat gui，改用数据库原生命令。
为什么Navicat导出的CSV在Linux脚本里报错“line contains NULL byte”或解析中断
根本原因不是换行符本身，而是Navicat在Windows下默认用CRLF（\r\n），且可能悄悄写入UTF-8 BOM头（\xEF\xBB\xBF）。Linux下多数命令行工具（如awk、sed、Python csv.reader）遇到BOM或混合换行会直接卡住，报NULL byte错误，而非单纯列错位。
- Navicat导出时若未勾选「UTF-8 BOM」，BOM不会出现；但若勾选了，即使你选的是UTF-8，BOM也一定会写入——而Linux工具普遍不认这个头
- 「行结束符」设为Unix (LF) 仅影响物理换行，不清理已有BOM；BOM在文件开头，优先级更高
- 某些ETL脚本（如用
pandas.read_csv()）加encoding='utf-8-sig'能自动吞掉BOM，但cat、head、grep等基础命令完全无法跳过它
绕过Navicat：用mysqldump或psql直接生成Linux友好的CSV
这才是真正可控的定时方案。Navicat只是前端，数据源在数据库，直接从服务端生成CSV，天然适配Linux环境。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- MySQL：用
mysqldump指定--fields-terminated-by=','和--lines-terminated-by='\n'，确保纯LF且无BOM - PostgreSQL：用
psql -c "COPY (SELECT ...) TO STDOUT WITH CSV HEADER"，输出默认就是LF+UTF-8无BOM - 关键点：所有参数必须显式写出，不能依赖默认值；例如MySQL的
--lines-terminated-by不写就是系统默认（Windows为\r\n），必须强制设为'\n' - 导出路径必须是数据库服务端可写的目录（不是你本地电脑），再用
scp或rsync拉回调度机
如果非得用Navicat导出，如何让Linux脚本稳定读取
不是修Navicat，而是修文件。导出后立刻在Linux端做两步清洗，比反复调Navicat设置更可靠。
- 先移除BOM：
sed -i '1s/^\xEF\xBB\xBF//' data.csv（只对UTF-8 BOM有效） - 再统一换行符：
dos2unix data.csv或sed -i 's/\r$//' data.csv（后者更轻量，只删行尾\r） - 验证是否干净：
file -i data.csv应输出charset=utf-8；head -n1 data.csv | od -c开头不应有\357 \273 \277 - 别用
iconv转编码来“顺带”去BOM——它可能把内容也转坏；BOM必须单独、精准剥离
真正容易被忽略的是：Navicat导出对话框里的「UTF-8 BOM」开关和「行结束符」是两个独立控制项，关掉BOM不等于换行符就变LF，反之亦然。定时任务里任何一步依赖GUI交互或Windows默认行为，都会在无人值守时失败。
