url编码解密：把%20还原成空格的过程
看到一串带着%20、%E4%B8%AD的链接，很多人第一反应是“这怎么读”。url编码解密要做的，就是把这类被转义的字符还原成原本可读的文本。读者最常问的是：为什么需要编码、什么时候该解码、以及自己动手还原时怎么避免把加号或百分号弄错。
在线工具URL编码
先搞清楚：谁把字符变成了百分号
URL 里能直接出现的字符有限，空格、中文、引号、斜杠这些都得先转义才能安全传输。编码规则本身不复杂：把字符按字节拆开，每个字节写成百分号加两位十六进制。于是空格成了 %20，中文“中”成了 %E4%B8%AD。
麻烦在于，不同场景下空格还可能被写成加号。表单提交时加号常被当作空格处理，但放在路径里加号就是加号本身。所以做 url编码解密 之前，先判断这段字符串来自查询参数还是路径，结果会不一样。
手动还原时最容易翻车的两个地方
第一个坑是连续百分号。看到 %2520 别急着一次解完，它很可能是 %20 又被编码了一遍。多层嵌套在跳转链接里很常见，解一层后要再检查是否还有 % 后跟两位十六进制。
第二个坑是字符集。早期系统可能用 GBK 编码中文，现代页面多用 UTF-8，同一串百分号序列按不同字符集解出来完全不同。如果解出来是乱码，先确认原始页面的编码声明，再决定用哪种方式还原。拿不准时，用本站的 URL编码工具 反向验证一下，比反复猜字符集省事。
什么时候需要解密，什么时候不必
调试接口时，看到请求参数里全是百分号，解一下能快速定位传了什么值。排查日志时也一样，把转义后的路径还原出来，才看得出用户实际访问了哪个页面。
但并非所有百分号都值得还原。签名串、加密后的 token 里出现百分号是正常现象，硬解反而破坏结构。另外，解码后的文本如果准备再次拼进 URL，记得重新编码，否则空格和特殊字符又会引发问题。
一个容易被忽略的细节：保留字符
斜杠、问号、井号这些字符在 URL 里有语法含义。编码时它们可以被转义，但解码时是否还原要看上下文。比如路径里的 %2F 解成斜杠后，可能改变路由层级；查询参数里的 %26 解成 & 后，可能被误认为参数分隔符。
所以做 url编码解密 不光是字符替换，还得想清楚还原后的文本会不会影响原本的结构。稳妥的做法是只对值部分解码，保留分隔符原样。
总结
url编码解密的核心是把百分号转义序列还原成可读字符，但字符集判断、加号含义、多层编码和保留字符这几个细节决定了结果对不对。先弄清来源，再动手还原，比盲目替换更可靠。
相关文章
- 极客解码base64：为什么解出来的常是乱码
从乱码、填充符到字符集差异，讲清解码 Base64 时容易踩的坑，以及排查思路。
- 易语言base64解码怎么用才不容易出错
面向易语言开发者的Base64解码说明，讲清字符串与字节集转换、编码识别和乱码排查的实用思路。
- 文件转换为base64编码：为什么需要以及如何正确使用
了解文件转换为base64编码的含义、典型场景与常见误区，掌握在开发中处理二进制文件编码的实用思路。
- 文件base64解码：为何解码后还是乱码？
文件base64解码后出现乱码或打不开？本文从文件类型、字符集、二进制处理等角度分析原因，并给出排查思路与工具选择建议。
- 文件base64在线编码和解码：如何避免传输乱码？
了解文件base64在线编码和解码的用途与操作要点，避免文件在传输中损坏或乱码，并掌握常见问题的处理方法。
常见问题
Q1url编码解密后出现乱码是怎么回事？
多半是字符集不匹配。百分号序列本身只是字节的十六进制表示，按 UTF-8 解和按 GBK 解结果不同。确认原始内容的编码方式后再还原，乱码通常就消失了。
Q2加号到底代表空格还是加号？
在 application/x-www-form-urlencoded 的表单数据里，加号通常代表空格；在 URL 路径或其他上下文里，加号就是加号。判断来源再决定是否把加号替换成空格。
Q3为什么有的字符串要解码好几次？
因为内容可能被多次编码。比如原始空格先变成 %20，又被整体编码成 %2520。每解一层，检查是否还存在百分号转义序列，直到没有为止。
Q4解码后的内容能直接放回链接里吗？
不建议。解码得到的是可读文本，其中可能包含空格、斜杠等需要转义的字符。放回链接前应重新编码，否则链接结构可能被破坏。