必须启用引号包裹字段，即在导出向导「格式设置」页勾选“Enclose fields in quotes”并设文本限定符为"，否则含\n的字段会被误判为新行，导致列错位、数据偏移。
Navicat导出时如何让含换行符的字段不破坏CSV结构
navicat默认能正确处理字段内换行符，但前提是必须启用文本限定符（即用双引号包裹字段）。否则，哪怕只有一处字段含\n，整个csv解析就会错行——后续所有列都会偏移，看着像乱码，实则是结构塌陷。
关键操作只有两步：
- 在导出向导「格式设置」页，必须勾选
Enclose fields in quotes（文本限定符设为"） - 确保字段分隔符不是
"本身（比如别用双引号当分隔符），否则会和限定符冲突
注意：Enclose fields in quotes不是可选项，是字段含换行、逗号、引号时的强制前提。不勾它，Navicat不会自动加引号，也不会转义，直接把\n当行结束符处理。
Navicat导入时识别不了字段内的换行符？检查引号和转义设置
导入失败常表现为：某行突然中断、字段数对不上、报错column count doesn't match value count。根本原因往往是CSV里有换行字段，但Navicat没按RFC 4180规则解析——它只在字段被"包裹且启用转义时，才把引号内的\n视为内容而非换行。
导入向导第二步需确认：
-
Fields enclosed by必须填"（不能留空或填其他字符） -
Escaped by可留空，除非字段里真有"或\需要转义；若留空，Navicat仍能识别"...text\nmore text..."为单字段 - 不要勾选
First line contains column names后再手动删首行引号——这会让Navicat误判字段边界
如果CSV是别人给的，先用head -n 5 your.csv | hexdump -C看是否有22 0a 22（即"\n"字节序列），确认换行确实在引号内。
为什么用Excel打开看起来“有换行”，但Navicat导入却错位
Excel双击打开CSV时，会渲染引号内的\n为视觉换行，但这只是显示效果；实际文件仍是单行、靠引号界定字段。Navicat导入时若没识别引号，就会把那个\n当成真实行结束符——于是后半段被当新行，列数立刻对不上。
验证方法很简单：
- 用
notepad++或vscode以UTF-8无BOM打开，关掉「自动换行」，看原始字节 - 搜索
"，确认每个字段是否成对出现；不成对说明CSV本身损坏，Navicat无法修复 - 字段内换行应表现为
"abc\ndef"，而不是"abc"\n"def"
最容易被忽略的是：Navicat导入时Fields enclosed by和Fields terminated by必须严格匹配CSV实际格式。哪怕导出时用了"，导入时设成空或'，都会让换行字段失效。
