Navicat导入CSV时反斜杠“不生效”实为未触发解析逻辑：Escaped by仅在Enclosed by "启用且字段含"或时才解析转义序列；单独路径中的默认原样保留，非法转义如U会报Invalid escape sequence；应关闭Escaped by并用双引号包裹字段确保原样入库。
Navicat 导入 CSV 时反斜杠异常，不是规则“没生效”，而是你很可能根本没触发它的解析逻辑——Escaped by 只在字段被双引号包裹且内容含 " 或 时才起作用；单独出现的 （如 Windows 路径）默认不参与转义，除非你错误启用了该选项。
为什么 Escaped by 看起来“不生效”
常见误解是以为开启 Escaped by 就能“处理所有反斜杠”。实际行为是：
- 仅当字段用双引号
"包裹（即Enclosed by "已启用）时，Escaped by才会尝试解析"、\、 - 字段未被引号包裹时，哪怕设了
Escaped by，Navicat 也直接按字面量保留，不会报错也不会转换 - 若字段内有孤立
U、z这类非法组合，会直接中断并报Invalid escape sequence - 你看到的“反斜杠消失”，往往是因为字段没引号 + 错开
Escaped by，导致 MySQL 层级或中间解析把U当作无效转义丢弃了
字段含真实反斜杠（如 C:path o ile）该怎么做
目标是让 原样入库，不是还原为特殊字符。这时最安全的做法是关闭转义逻辑，而非调试它：
Knowledge Graph - Csv Graph Loader Generator
下载
从 CSV 数据集生成图数据库加载器和三元组映射。将表格 CSV 数据转换为图数据库可直接使用的节点、边和三元组。
- 在导入向导第 2 步（字段设置页），**取消勾选
Escaped by对应的复选框**（或将其下拉值留空） - 确保
Enclosed by设为"（双引号），且 CSV 中所有含的字段都用双引号包裹，例如："C:path o ile" - 如果 CSV 源不可控（比如 Excel 导出），导入前用文本编辑器全局替换：把
C:替换为"C:\"，避免单个被误判 - 别依赖
Replace功能做运行时替换——它只对字段值生效，无法修复因解析错位导致的整行截断
导入失败报 Invalid escape sequence 怎么快速定位
这个错误明确指向 CSV 数据本身含非法转义，和 Navicat 设置关系不大：
- 用 VS Code 或 Notepad++ 以 UTF-8 编码打开 CSV，搜索
，检查它后面紧跟的字符：如果是n、t、"、，属于合法；若是U、x、z，就构成非法序列 - 重点看双引号包裹的字段内部——
"C:Users"是合法的（U在引号内且Escaped by开启时会被当作无效转义）；而C:Users（无引号）则完全不触发该检查 - 若确认存在非法序列，且无法修改源文件，唯一稳妥方式是关闭
Escaped by并接受U被原样存入（MySQL 层可能再处理）
真正容易被忽略的是：Navicat 的转义解析是“全有或全无”的——要么整个 CSV 都符合 RFC 4180 引号+转义规范，要么就别碰 Escaped by。试图混合使用（部分字段引号、部分不引，或只对路径字段启用转义）只会放大解析不确定性。
