字符串转义工具实战:把引号、反斜杠、换行安全塞进 JSON 与 SQL

写代码时最容易翻车的一类问题,往往不是逻辑错,而是一个引号没处理好。你想把一段文本当作"数据"放进某段代码里,可这段文本里偏偏混着引号、反斜杠或换行,于是它提前闭合了字符串、改变了语义,接口直接回你一个 400。转义,做的就是这件事:把那些会改变结构的字符,改写成"我只是普通字符"的形式。

转义和反转义到底在干什么

一个字符串字面量,靠引号界定边界。问题在于,文本内容里也可能出现引号。比如你要表示这句话:

He said "hello"

直接写成 "He said "hello"",解析器读到第二个引号就以为字符串结束了,后面全乱套。正确做法是给内部的引号加反斜杠:"He said \"hello\""。这就是最核心的一条规则:引号要转义,写成反斜杠加引号。换行同理,真实的换行符会破坏单行字面量,转义后写成 \n;而反斜杠本身因为是转义的引导符,也得转义成 \\。

反转义是反向操作:把 \" 还原成 ",把 \n 还原成真实换行,把 \uXXXX 还原成对应的 Unicode 字符。两个方向都常用,所以一个趁手的工具得双向都做。

不同上下文,规则并不通用

很多人以为转义就是"无脑加反斜杠",这是最大的误区。每种目标语言的规则不一样:

JSON:只转四个必转字符(引号、反斜杠、以及部分控制字符),控制字节统一写成规范的 \uXXXX,这样粘进请求体不会把解析器搞崩。
JavaScript:在 JSON 基础上,模板字符串还要处理反引号和竖向制表符。
SQL:单引号不是用反斜杠,而是按 ANSI 标准翻倍,' 写成 ''。
正则:. * + ( [ 这些元字符要逐个加反斜杠,否则它们会被当成模式语法而非字面文本。
Shell:干脆不靠反斜杠,而是把整串用单引号包起来。

把 SQL 的规则套到 JSON 上,或者拿反斜杠去糊弄 shell,结果都是错的。这也是我自己早年踩过的坑:有一次手搓迁移脚本,习惯性地给单引号加反斜杠,结果在那个数据库里 \' 根本不被识别,白白排查了半小时,才想起 SQL 要的是 ''。所以选对目标语言,比记住某一套规则更重要。

一个真实例子:多行日志塞进 JSON

假设你在手搓一个 curl 请求,要把下面这段三行错误信息放进一个 JSON 字段:

Error on line 3:
parse failed near "id"
column 12 unexpected

直接粘进去,换行和内嵌的双引号会立刻把 JSON 弄坏。选 JSON 目标转义后,得到的是单行字面量:

Error on line 3:\nparse failed near \"id\"\ncolumn 12 unexpected

换行变成了 \n,内部的双引号变成了 \",整段压成一行。把它放进你自己的外层引号里,接口第一次就解析成功,而不是回你一个要去 debug 的 400。这就是"把多行文本变单行字符串"最典型的场景。用字符串转义工具选好目标语言粘贴即可,不用手数每个该转的字符。

防注入:转义不是万能的

很多人把 SQL 单引号转义当作防注入手段,这是危险的误解。把单引号翻倍只能挡住最直白的逃逸,但字符集边界、数字上下文、标识符、存储过程的各种怪癖都能绕过朴素转义。唯一正确的防御是参数化查询(预编译语句):驱动把你的值当数据发送,永远不当 SQL 文本解析。

转义工具适合的是另一种场景:给迁移脚本或临时控制台查询手搓一条一次性字面量。比如工单要你更新一行,客户名是 O'Brien,直接敲进控制台会提前闭合字符串报错,转义成 O''Brien 放进引号里就对了。但凡碰真实用户输入,请走参数化查询,别拿转义当安全边界。

Shell 的思路也值得借鉴:它用单引号包裹而非反斜杠。POSIX 单引号里每个字符都是字面量,没有变量展开、没有命令替换、没有通配,这是把任意字符串传给 bash 最可预测的方式,从机制上避开了大半注入面。

顺手要用的几个工具

字符串处理常常不是孤立的一步。如果你要转的是 HTML 里的 < > &,那是另一套实体规则,用 HTML 实体编码器更合适;链接里的参数则归 URL 编码管。转义完想验证 JSON 结构是否合法,可以丢进格式化工具检查;遇到字面量里某个字形看着可疑,再用字符检查器逐码点看清楚。把这些工具串起来,一段脏文本从粘贴到落地基本不用手动数字符。

转义这件事看着琐碎,但它处在数据和代码的交界线上,一个字符没处理对,整段就跑偏。选对上下文、转一次、必要时先反转义回纯文本再重转,基本就能避开绝大多数翻车。

Made by Toolora · Updated 2026-06-13