🪢 字符串转义 / 反转义
在 HTML 实体、JavaScript 字符串、JSON 字符串、Unicode(\uXXXX) 和 URL 之间转换字符串。
完全免费
无需注册
浏览器内完成
5 种语言
深色模式
📖 示例
| Format | Raw | Escaped |
|---|---|---|
| HTML | <a> | <a> |
| JS | It's 'ok' | It\'s \'ok\' |
| JSON | tab here | tab\there |
| Unicode | 日本語 | \u65e5\u672c\u8a9e |
| URL | a b&c | a%20b%26c |
📖 常见的坑
以 HTML 实体、JavaScript 字符串、JSON、Unicode（\uXXXX）、URL、CSV、SQL、正则、Shell 等 14 种形式对字符串进行转义 / 反转义。处理全部在浏览器内完成。但转义不是「变换字符串」，而是「迎合输出目的地的语法」——这个工具并不知道你的输出目的地，因此无法判断你该选哪一种形式。而且套用错误的形式，结果比什么都不做更糟，因为它让人感觉安全，实际上却什么也没保护。
| 情形 | 会发生什么 | 怎么处理 |
|---|---|---|
| 上下文不同，正确的转义也不同 | 同一个值，落在哪里，所需的处理就不同。放在 <div> 里，做实体编码就够了；放在 href="..." 里还要求它作为 URL 是合法的；放在 onclick="..." 里则必须同时满足 JavaScript 与 HTML 两层。此外还有HTML 转义完全无效的上下文——href 中以 javascript: 开头的值，做了实体编码照样执行；而在 <style> 或 <script> 内部，< 只被当作普通文字，语法依旧是敞开的。换句话说，有些地方「先 HTML 转义再说」根本不适用。 |
请在输出的那一刻转义，并且交给模板引擎去做。正确的做法是使用能指定上下文的机制：Twig 的 |e('html_attr') / |e('js') / |e('url')、React 的 JSX、Go 的 html/template。请抛弃「输入时转义并保存」的设计——被保存的值往往不止一个去处，它会流向邮件正文、CSV 导出和 API 的 JSON。数据库里永远存原始值，每次输出时按当地上下文转义。仅此一条原则，上面列举的问题几乎全部消失。这个工具请当作用肉眼核对结果是否正确的地方。 |
双重转义（页面上出现 &lt;） |
就是屏幕上原样显示出 <strong> 或孤零零的 &。原因几乎总是「转义了两次」，典型组合是保存时应用转义了一遍，显示时模板引擎又转义了一遍。棘手之处在于它作为 bug 很不显眼——纯英数字的数据什么事都不会有，只有名字里含撇号或 & 的那些行会坏掉。而且坏掉的数据已经躺在数据库里，修显示端是修不好的。也存在反方向的事故：JSON 里的 \n 被再转义一次变成 \\n，本该是换行的地方最终以两个可见字符出现。 |
先分清是哪一侧在重复转义。把数据库里的原值粘到这里，选择「反转义」方向并指定 HTML。如果值发生了变化，说明存进去的时候就已经是转义过的——原因在输入侧。如果没有变化，那么重复发生在显示侧。修复请用只执行一次的迁移脚本，并且务必限定范围（WHERE body LIKE '%&%'）。对全表无条件执行 html_entity_decode，会毁掉那些本来就想写成 & 的行。执行前请务必备份，并先数一遍受影响的行数。 |
| 转义不是净化 | HTML 转义是「把内容作为文本安全展示」的处理，而不是「安全地渲染用户写的 HTML」的处理。在确实需要允许标签的场景（比如富文本投稿），你需要的是逐一列出允许的标签与属性的净化器。同样的误解在其他形式里也存在。SQL 字符串转义（''）不能替代占位符——表名与列名、ORDER BY 的方向、LIKE 的通配符 % 与 _，全都不在字符串转义的防守范围内。Shell 的引号同理：值形如 -rf 而被解释为选项的情形，引号是拦不住的。 |
请按目的更换工具。要允许标签，就用专门的净化库（PHP 用 HTML Purifier，JS 用 DOMPurify），不要试图用自写正则去剥离标签——这个方向的自制品无一例外会被绕过。SQL 一律使用占位符，而表名、排序方向这类无法绑定的部分，必须与允许列表比对（只放行存在于 ['name','created_at'] 中的值）。Shell 请使用以数组传递参数的 API（execve 系列，或 Python 的 subprocess.run([...])），并在用户输入之前放上 -- 来终止选项解析。 |
Unicode 转义有一个 BMP 之外的陷阱。\uXXXX 只能表达 16 位，因此表情符号和部分汉字会拆成代理对两个单元——一个表情符号变成 \ud83d\ude00 两份。在这里数字符数或者截断，就会把一个字符劈成两半而弄坏它。ES6 之后可以用单一形式 \u{1f600}。还有第二个后果：这种「非 ASCII 变成 \uXXXX」的特性会妨碍验证——本站自己就曾两次因为拿日文原文去 grep 模板为 JS 转义过的字符串，而误判「没有部署成功」。正确的做法是：搜索之前先把 \uXXXX 解码回来。最后请务必遵守一条：不要把反转义得到的字符串交给 JSON.parse 之外的执行路径，更绝不要交给 eval。解码是为了检查，不是为了执行。
📖 使用方法
-
1
选择格式和方向选择格式（HTML、JavaScript、JSON、Unicode、URL 等）和方向（转义或反转义）。
-
2
输入文本在左侧输入框粘贴或输入文本。实时完成转换。
-
3
复制或互换结果复制右侧结果,或点击互换按钮反向转换。
❓ 常见问题
HTML 转义和 URL 编码有什么区别？
HTML 转义将 & < > " 转换为 HTML 实体。URL 编码将特殊字符转换为 %20 等百分比编码。
可以转义日语等非 ASCII 字符吗？
是的。选择 Unicode（全部字符）或 Hex（UTF-8 字节）模式可转义包括日语在内的所有非 ASCII 字符。
可以用此工具防止 SQL 注入吗?
SQL 模式可将单引号转义,但生产环境请务必使用预处理语句。
🐛 此工具出现问题了吗？
免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。
✅
感谢您的反馈！
已送达运营者,将用于改进工具。