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。试图混合使用（部分字段引号、部分不引，或只对路径字段启用转义）只会放大解析不确定性。