常见问题
空格该编码成 %20 还是 +？
本工具用 %20，这是 RFC 3986 的标准写法。加号只属于表单编码（application/x-www-form-urlencoded），两者不能混用。
为什么中文变成一串 %E4 开头的东西？
一个汉字按 UTF-8 拆成 3 个字节，每个字节写成 %XX。解码时会自动还原。
解码后还是乱码怎么办？
多半原文不是 UTF-8（例如 GBK）。本工具按 UTF-8 解码，这种情况会显示乱码而不是报错。
关于这个工具
编码规则就是浏览器里的 encodeURIComponent：字母、数字和 - _ . ! ~ * ' ( ) 原样保留，其余字符先按 UTF-8 拆成字节，再逐字节写成 %XX。所以一个汉字是 3 组（中 → %E4%B8%AD），一个 Emoji 是 4 组（%F0%9F%98%80）；反过来说，看到 3 组一循环就是汉字。
空格编码成 %20，不是 +，而且解码时 + 不会被还原成空格 —— 从查询字符串里复制的 a+b 解出来还是 a+b。这是两套规则的历史遗留：+ 表示空格只属于表单编码（application/x-www-form-urlencoded）。要按表单规则解，先自己把 + 换成空格再解码。
它不能直接编码整条 URL：https://a.com/p 里的 : / 也会被转义成 %3A%2F%2F，链接就废了。正确做法是拆开处理 —— 协议、域名、路径按原样保留，只把查询参数的键和值各自编码。本工具是纯粹的百分号编解码器，不做这层拆分。
解码遇到非法序列（%zz、末尾单个 %、被截断的多字节 UTF-8）会报「转换失败」而不是静默吞掉，这是有意为之：乱码比报错更难排查。另外从 GBK 页面复制来的 %XX 在本工具里按 UTF-8 解，结果会是乱码而不是报错 —— 这类内容需要先确认原始编码。