urldecode · 关于我们

新手快速上手三步

第一步，找到需要处理的字符串。通常它长这样：%E4%BD%A0%E5%A5%BD。第二步，粘贴到解码框里，点击解码。第三步，核对结果是否符合预期。如果结果不对，先别急着换工具，往下看坑点部分。

判断一段内容是否需要解码有个简单方法：看有没有连续的 % 加两个十六进制字符。有，大概率就是编码过的。但要注意，% 本身也可能是正常字符，比如在百分数里。所以看到 % 不要条件反射，先确认上下文。

坑点一：双重编码

有些系统会对已经编码的内容再编码一次，结果就是 %25E4%25B8%25AD 这种形式。这里的 %25 其实是 % 的编码结果。遇到这种情况，解码一次不够，需要连续解码两次。判断方法是看结果里是否还残留 %XX 结构。

坑点二：字符集不匹配

同样的编码字符串，用 UTF-8 解和用 GBK 解，结果可能完全不同。中文环境下尤其常见。如果解出来是乱码，先确认原始内容用的是什么字符集。大部分现代网站用 UTF-8，但老系统不一定。

坑点三：空格与加号

在 application/x-www-form-urlencoded 格式里，空格有时被编码成 + 而不是 %20。解码时如果没处理这个差异，结果会多出加号或者少掉空格。看到 + 的时候，先判断它是字面加号还是空格占位符。

坑点四：大小写不敏感但别乱写

百分号编码的十六进制字符大小写都合法，%2F 和 %2f 等价。但有些严格校验的系统只认大写，拼接 URL 时保持统一更稳妥。

老手经验：先看源头再动手

处理编码问题最有效的方法不是反复试，而是先搞清楚数据从哪来、经过了哪些环节。是浏览器地址栏、是接口返回值、还是日志文件？不同来源的编码规则可能有细微差别。搞清楚源头，大部分问题不用试就能定位。

另外，我们不会在站内展示无法核实的数据或来源不明的统计。上面提到的坑点都来自实际处理经验，能复现、能验证。如果你的场景不在其中，欢迎反馈，我们会核实后补充。