JSON 字符串转义与反转义
把 JSON 转义成能塞进 Java、JS、Python 源码的字符串字面量，或把转义文本还原成可读 JSON。
在代码里硬编码一段 JSON 时，最麻烦的往往不是内容本身，而是引号：JSON 用双引号包住 key 和字符串，放进 Java 或 C# 的字符串字面量里就必须全部转义，手工改一遍几乎必然漏掉几个。这个工具把整段文本转义成单行字面量，双引号变成 \"、反斜杠变成 \\、换行变成 \n，粘贴进源码即可编译通过。
反向操作同样常用：从日志、数据库字段或消息队列里拿到一段转义文本，读起来全是反斜杠，需要还原成带换行的正常 JSON 才能看懂。去转义在本页一次完成，所有处理都在浏览器里进行，涉及内部接口结构、密钥字段的文本不会被上传或转发。
转义处理了哪些字符
转义依据 JavaScript 字符串字面量规则执行，会改写这些字符：双引号写成 \"、反斜杠写成 \\、换行写成 \n、回车写成 \r、制表符写成 \t、退格与换页写成 \b 和 \f，其余字符原样保留。结果整体用一对双引号包起来，因此它是一个字符串字面量，本身不再是 JSON 文档。Java、C#、JavaScript、Python 的双引号字符串都接受这套转义，可以直接粘贴；Python 中也可以改用三引号或原始字符串后再手工调整。
去转义是怎么还原的
去转义支持两种输入：带外层引号的完整字面量，以及没有引号的裸片段。带引号时先尝试按 JSON 字符串解析，这是最准确的一条路径；不满足条件时按转义表逐字符还原，\uXXXX 会还原成对应字符。扫描是单次从左到右完成的，所以 \\n 这样的组合会正确还原成「反斜杠加字母 n」，而不会被二次解释成换行，这是不少在线转义工具容易出错的地方。
常见误用与操作顺序
最容易犯的错误是对已经转义过的文本再转义一次，得到层层叠加的反斜杠，读起来像 \\\"。判断办法是看结果开头：正确输出应该只有一对最外层双引号。另外，如果一段文本里本来就写着 \u4e2d 这样的转义序列，转义后它会变成 \\u4e2d，也就是反斜杠被当作普通字符保留，并不会变成汉字；要真正还原成中文，应该用 Unicode 转中文功能，而不是去转义。建议的处理顺序是：先修复并格式化让 JSON 合法，最后再做转义。
常见问题
- 转义后的内容还能当 JSON 用吗？
- 不能。转义结果是一整行被双引号包裹的字符串字面量，它是给源码用的，不是 JSON 文档。要放回 JSON 里当字段值，可以保持转义形态作为字符串值使用；要还原成结构化 JSON，则应该用去转义把它拆回原文。
- 为什么转义后粘进 Java 仍然编译报错？
- 多数情况是操作范围不对。转义工具处理的是编辑区里的整段文本，如果只手工替换了其中一部分，剩下的双引号仍会打断字符串。另外 Java 的字符串字面量有常量池长度限制，很长的内容建议改用文本块、放进资源文件，或拆成多个字符串拼接。
- 转义和去转义能反复来回用吗？
- 单次往返是可靠的：转义再去转义会得到与原文一致的内容。但不要在已转义的文本上再点一次转义，那会形成多重转义，反斜杠数量成倍增加，很难凭肉眼还原。如果不小心点多了，连续执行相同次数的去转义即可恢复。