字符串转义
按 JS、JSON、Java、Python、Shell、SQL 六种规则转义或还原，一次并列全部结果。
这个工具把转义与还原两种操作都做成「一次全列」：上方用「转义/还原」切换方向，粘贴文本后，JS、JSON、Java、Python、Shell、SQL 六张结果卡同时刷新，不用一颗一颗点。卡头是方言名和读数（输入几个字符、输出几个字符、几处转义），卡体是结果，卡尾是该方言的注意点；还原方向遇到的非法写法会标出第几行第几列，JSON、Java 的非法转义按编译错误对待，卡头会给出硬问题的数量。「方言」下拉只是过滤器，默认六张并列。
两个方向互逆：对每个方言，还原(转义(x)) 都等于 x，包括引号、反斜杠、控制符、孤立代理和 emoji。同一个反斜杠在不同语言里含义不同，六种方言各自的转义与还原规则逐条列在下方的用法说明里。粘贴进输入框的 CRLF 会先被归一成 LF。全部逻辑在你的浏览器里完成，不发任何网络请求；本页没有复制按钮，结果请自行选中取用，或用「下载 .txt」把当前可见的卡一次导出。
字符串转义怎么用
- 写进代码：选「转义」、粘贴原始文本，六张卡直接给出各语言带首尾引号的字面量，按你所在的语言选一条替换掉手工加反斜杠的写法；只想看某一种时用「方言」下拉过滤。
- 读回原文：选「还原」，把日志、JSON 字段或配置里那串带 \n、\uXXXX 的文本粘进来；只在整段以引号开头时才把引号当定界符，非法写法在卡上标出第几行第几列，标了「硬问题」说明输入里有该语言会拒绝的写法，读回的文本别当已验证的结果直接用。
- 比对语言差异：默认视图就是比对：同一段输入下六张卡并列，看控制符分别变成 \xHH、\u00XX、八进制，以及引号与反斜杠各自怎么处理；「下载 .txt」会把当前可见的卡连读数一起导出。
- 六种方言的规则：同一个反斜杠在不同语言里含义不同：JSON 只认 " 、\ 和 \uXXXX，换行写成 \n；Java 的 \u 在词法分析之前就被展开，想表达字面的 \u0041 必须写 \\u0041；Python 的 repr 会自己挑引号，只转 \t、\n、\r 和引号；POSIX shell 的单引号里没有转义这回事，唯一的例外是单引号本身，要用 '\'' 这四个字符拼；SQL 的标准做法是把单引号写成两个连续单引号，只有 MySQL 默认模式仍然把反斜杠当转义符。
常见问题
\u 在 Java 里为什么和 JS、JSON 不一样？
JS 和 JSON 的 \uXXXX 只是字符串字面量内部的一种写法，由词法分析器在读字符串时才解释。Java 把 \uXXXX 放在「源码字符流」这一层：编译前整个文件先统一展开，不管它在字符串、注释还是任何位置。于是写 "\u000a" 会在字面量中间塞进一个真换行，编译当场报错；想在字符串里留下字面的 \u0041 六个字符，必须写成 \\u0041（本工具的转义输出就是这样：先转掉反斜杠，u0041 原样跟着）。所以这个工具给 Java 的控制符优先用 \n、\t 这类短写法，其余走三位八进制 \NNN，只有非 ASCII 才用 \uXXXX——这也是 .properties 文件 native2ascii 的老传统。
为什么 SQL 转义不能用来防注入？
因为转义规则是「方言 × sql_mode × 连接字符集」三者决定的：同样一段输入，在标准 SQL（PostgreSQL、SQLite、SQL Server）里反斜杠是普通字符，在 MySQL 默认模式里却是转义符，开了 NO_BACKSLASH_ESCAPES 又变回普通字符；GBK 这类多字节编码还能构造出「半个宽字符吃掉你补的反斜杠」的组合。本工具按最保守的标准 SQL 口径输出（只把单引号写成两个，反斜杠原样保留，并提示 MySQL 的差别），它解决的是「把带引号的文本写成合法字面量」。防注入要用参数化查询/预编译占位符，让数据永远不进语法结构，这是任何转义工具都替代不了的。
Shell 里那个四字符写法是什么，为什么不直接用反斜杠转义单引号？
POSIX 规定单引号内所有字符都是字面量，反斜杠也不例外，所以「在单引号里写反斜杠再加单引号」不但得不到单引号，还会让字符串提前结束、后面的内容被当成命令去解析。唯一的通用办法是拆开拼：用一个单引号闭合当前段，在引号外写一个反斜杠紧跟单引号取到字面的单引号，再用一个单引号重开下一段，合起来就是 '\'' 这四个字符。这样 $ 、反引号、反斜杠、通配符全部保持原样，比改用双引号安全得多——双引号里 $ 、反引号、反斜杠和双引号本身仍然有效。另外 ANSI-C 引用 $'…' 的规则不同，它自己会展开 \n、\xHH，本工具不展开这种写法，检测到时会提示。
对应功能编号 #21无需安装，手机端同样可用按 Ctrl + K 换工具