A. 痛点描述（Problem）#
JSON 的“转义问题”往往是最折磨人的：
- 你拿到一个字段，表面是字符串，里面却装着一段 JSON
- 日志里满屏
\\\"、\\\\、\\n，你不知道它到底代表什么 - Windows 路径
C:\new\test一放进 JSON 就炸 - 你把 JSON 放进环境变量/配置里，读取后解析失败，却看不出来哪里错
这些问题的根因几乎都一样：你在“字符串字面量层”和“JSON 数据层”之间来回切换，每切换一次，转义规则就会再叠一层。
工具入口：JSON 转义 / 反转义
👉 立即使用：JSON 转义 / 反转义
B. 核心原理（Deep Dive）——你其实在处理“多层字符串”#
1）一层：JSON 字符串内部的转义#
在 JSON 中，字符串需要转义：
"→\"\→\\- 换行 →
\n - 制表 →
\t
2）两层：把 JSON 当作“字符串值”嵌进另一个 JSON#
当你把一段 JSON 放进字段值里（嵌套 JSON 字符串），你会看到典型形态：
- 外层 JSON：合法
- 内层 JSON：以字符串形式存在，因此内层的
"、\都必须再次转义
很多“看起来像 JSON”的内容其实只是一个字符串，必须先反转义一次，再作为 JSON 解析。
C. 操作指南（Step-by-step）——判断层级，再决定转义/反转义#
第一步：判断你手里的内容属于哪一种#
常见三类输入：
- 原始文本（包含引号、换行、反斜杠），你要把它变成“可嵌入 JSON 的字符串”
- 已转义文本（包含大量
\\n\\\"），你要还原成可读文本 - 字符串里嵌套 JSON（先反转义，再解析/格式化）
第二步：用工具做转义或反转义#
- 你要“生成可嵌入的字符串” → 转义
- 你要“还原可读文本” → 反转义
第三步（嵌套 JSON）：反转义后立刻去 JSON 工作台格式化#
当你怀疑“字符串里装的是 JSON”时：
- 先反转义得到真实文本
- 再把结果粘贴到 JSON 工作台校验/格式化
👉 立即使用工具
D. 高频坑位与示例#
1）Windows 路径导致解析失败#
错误示例：
{ "path": "C:\new\test" }
原因：
\n会被当成换行转义
正确示例：
{ "path": "C:\\new\\test" }
2）日志里出现的 \\n 到底是换行还是两个字符？#
这取决于它处在第几层：
- 如果你看到的是字符串字面量（已经逃逸了一层），
\\n还原后才是\n - 如果你看到的是 JSON 原始字符串内容，
\n才代表换行
工程建议：不要凭肉眼猜，直接用反转义工具还原一次，再看结果。
3）字符串里嵌套 JSON 的排错套路#
典型输入（外层 JSON 的某字段）：
"{\"a\":1,\"b\":[2,3]}"
正确处理：
- 先反转义得到：
{"a":1,"b":[2,3]} - 再到 JSON 工作台格式化/校验
E. 常见问题（FAQ）#
1）为什么反转义后还是解析失败？#
常见原因：
- 文本被截断（少了引号或括号）
- 混入了不可见字符
- 实际内容不是 JSON，只是“看起来像”
建议：反转义后先当纯文本观察，再决定是否需要 JSON 解析。
2）转义是不是“加密”？#
不是。转义只是表示层变换，完全可逆，不具备安全性。
3）什么时候应该用 Base64 而不是转义？#
当你需要传输/存储二进制（或非常复杂的文本且跨系统容易被破坏）时，Base64 更合适；但它会膨胀体积。
Base64 工具入口：工具页面
工具推荐#
- JSON 转义/反转义：立即使用：JSON 转义 / 反转义
- JSON 工作台（反转义后校验/格式化）：立即使用工具