Escape / Unescape 编解码

痛点引入

摸鱼写代码时，最怕遇到字符串编码问题！比如前端传参到后端，特殊字符直接乱码，联调时一脸懵逼；或者测试环境好好的，一上线就崩了，排查半天才发现是转义字符没处理好。没个趁手工具，只能手动敲正则，效率低还容易踩坑。

核心功能深度解析

Escape 加解密工具基于 JavaScript 的 encodeURIComponent 和 decodeURIComponent 实现，但更专注于处理特殊字符的百分号编码。它用正则表达式匹配非安全字符（如空格、中文、符号），递归替换为 %XX 格式的十六进制值。背后遵循 RFC 3986 规范，确保 URL 安全传输。比如空格变成 %20，中文“你好”变成 %E4%BD%A0%E5%A5%BD，解码时反向操作，还原原始字符串。

行业应用场景

• 联调神器：前后端传参时，快速转义 JSON 中的特殊字符，避免接口报错。
• 测试必备：模拟用户输入含特殊字符的用例，验证系统健壮性。
• 生产环境：日志记录或数据存储前，对敏感信息进行编码，防止注入攻击。

FAQ 常见问题

1. Escape 和 encodeURI 有啥区别？ Escape 只处理非安全字符，encodeURI 处理整个 URI，但都不编码字母数字，别搞混！

2. 中文字符转义后为啥变这么长？ 因为 UTF-8 编码下，一个中文字符占 3 字节，每个字节转成 %XX，所以“你”变成 %E4%BD%A0。

3. 解码失败怎么办？ 检查输入格式是否正确，比如百分号后必须是两位十六进制数，否则工具会报错提示。

4. 能处理 emoji 吗？ 可以！但 emoji 是 4 字节编码，转义后像 %F0%9F%98%80，解码时需确保系统支持 UTF-8。

5. 递归转义是啥意思？ 工具会多层处理嵌套的转义字符，比如 %2520 先解成 %20，再解成空格，避免漏网之鱼。

技术科普/延伸阅读

Escape 编码源于早期 Web 安全需求，现成标准有 RFC 3986 和 W3C 规范。但有个未解之谜：为啥不同浏览器对空格处理不一致？有的用 %20，有的用 +，历史遗留问题坑了不少人。建议开发时统一用 %20，兼容性更好。