根本原因是Navicat在Windows下默认导出含UTF-8 BOM（\xEF\xBB\xBF）和CRLF换行的CSV，Linux工具如awk、sed、pandas.read_csv()遇BOM即报“line contains NULL byte”错误；解决需导出后用sed删BOM再dos2unix转LF，或改用mysqldump等服务端工具直接生成无BOM、纯LF的CSV。
Navicat导出CSV在Linux脚本里报“line contains NULL byte”怎么修
根本不是换行符本身的问题，而是navicat在windows下默认写入utf-8 bom（\xef\xbb\xbf）+ crlf（\r\n），而linux工具如awk、sed、pandas.read_csv()遇到bom就直接中断，报null byte错误。
- 勾选「UTF-8 BOM」= 一定会写入BOM；不勾选=无BOM——但多数人没注意这个开关，默认是勾选的
-
Line ending设为Unix (LF)只改物理换行，对已存在的BOM完全无效；BOM在文件开头，优先级更高 - Python脚本可用
encoding='utf-8-sig'自动吞BOM，但cat、head、grep等基础命令无法跳过它 - 真正可靠的做法：导出后立刻在Linux端执行两步清洗：
sed '1s/^\xEF\xBB\xBF//' file.csv > clean.csv（删BOM），再dos2unix clean.csv（转LF）
字段内含换行符导致CSV列错位，必须怎么设
不是Navicat导错了，是下游解析器按RFC 4180规则“合法地读崩了”：字段含\n但没加引号，就被当成新记录分隔符。
- 必须勾选
Enclose fields in quotes——这是硬性前提，不勾选时，含\n、,或"的字段不会被包裹，Excel和pandas都会错切 -
Line ending必须手动设为Unix (LF)，不能信“Default”；Windows下Navicat默认输出\r\n，混在字段内\n中会触发解析器异常 - 验证别靠Excel双击打开——它自带容错，常“勉强对齐”；用
head -n 5 data.csv | cat -A看结尾是$（LF）还是^M$（CRLF） - 字段里同时存在
\r和\n（比如从Word复制进数据库的文本），即使加引号+LF，某些老旧解析器仍可能行为异常——这种场景下，数据库层预处理比依赖导出设置更可控
为什么改了换行符，Linux脚本还是读不了
因为Navicat导出路径和定时任务运行环境割裂：你在Windows桌面用Navicat导出CSV，再scp到Linux服务器，但BOM和CRLF已在本地生成，Linux端只是被动接收者。
- 所谓“Linux定时任务跑Navicat”根本不存在——Navicat没有Linux服务端，命令行工具也仅限Windows/macOS
- 真定时方案必须绕过Navicat GUI：用
mysqldump或psql直接从数据库服务端生成CSV，天然无BOM、纯LF - MySQL示例：
mysqldump --no-create-info --skip-extended-insert --fields-terminated-by=',' --lines-terminated-by='\n' db table > data.csv；注意--lines-terminated-by='\n'必须显式写出，否则默认用系统换行（Windows为\r\n） - 导出路径必须是数据库服务端可写的目录（如
/tmp），再用scp拉回调度机——不能写成本地路径
Navicat导出SQL文件还原失败，换行符只是表象
SQL文件里的CRLF、BOM、Windows路径注释才是Linux导入失败的主因，换行符问题只是冰山一角。
- Navicat Windows版导出的SQL默认带CRLF、可能含BOM、注释里还有
C:\path\to\file.sql这类路径——MySQL客户端不会自动转换 - 用
dos2unix转LF，用VS Code保存为UTF-8（no BOM），再全局替换掉所有Windows路径注释 - 确保首行是
/*!40101 SET NAMES utf8mb4 */;，前面不能有空行或BOM；否则Linux MySQL客户端执行时字符集未初始化，中文全变? - Linux版Navicat导入时，右下角「编码」下拉菜单只控制文件读取解码，不改变执行字符集——必须在连接「高级」页填
SET NAMES utf8mb4;到Initial command框
xxd或head -c 5检查开头三字节是否为\xEF\xBB\xBF，用file -i确认换行符类型，而不是凭界面判断。 
