URL 在线编码解码
URL 编码解码，支持两种模式切换、加号还原空格、多行批量处理与查询参数解析。
接口联调时最常见的两个坑：拼接查询参数时把 & 和 = 一起编码掉，后端只收到一个参数；或者解码之后空格变成了加号，比对签名时怎么都对不上。URL 编码的规则本身不难，难在不同场景该选哪种模式、加号到底代表什么。
本工具在浏览器里调用原生的 encodeURIComponent、encodeURI 与 decodeURIComponent，不上传也不留存任何文本。按行批量模式适合处理日志、配置文件或一批链接；查询字符串解析会把 a=1&b=2 这类内容拆成参数表格，方便核对参数名与取值是否写错。
两种编码模式的区别与选用
encodeURI 会保留 : / ? # [ ] @ ! $ & ' ( ) * + , ; = 这些保留字符，适合处理一整条 URL，不会破坏它的结构；encodeURIComponent 会把这些字符全部转义，适合处理单个参数名或参数值。典型错误是用 encodeURI 处理参数值，值里的 & 和 = 会被后端当成分隔符，一个参数被拆成两个；反过来用 encodeURIComponent 拼整条链接，协议和路径里的斜杠会被一起编码，链接直接失效。
加号、空格与解码歧义
在 application/x-www-form-urlencoded 这种表单格式里，+ 代表空格，所以值中的空格既可以写成 + 也可以写成 %20；而 URL 路径里的 + 就是字面意义的加号。decodeURIComponent 只处理百分号转义，不会把 + 还原成空格，这就是解码结果里多出加号的原因。本工具提供把 + 还原为空格的开关，让你自己决定按哪种约定解释数据。
中文编码后为什么那么长
URL 里只能出现 ASCII 字符，中文必须先按 UTF-8 转成字节再写成百分号形式：一个汉字 3 个字节，编码后变成 9 个字符（形如 %E4%B8%AD），中文链接因此明显变长。用 GBK 编码的旧系统得到的是 %D6%D0 这类两字节结果，两边编码不统一就会出现乱码。Base64 与 JWT 里的 +、/、= 等字符放进查询串之前同样需要编码。
常见问题
- URL 编码和 URL 解码有什么区别？
- 编码是把不能直接出现在 URL 里的字符（中文、空格、#、& 等）转成百分号形式；解码是把 %E4%B8%AD 这类转义还原成原始字符。浏览器地址栏显示的是解码后的内容，把链接复制进代码时要注意别对已解码的字符串再解码一次。
- 为什么解码之后空格变成了加号？
- 有两种可能：原文里的空格本来就被编码成 +（表单约定），解码时需要手动把 + 替换回空格；或者原文中确实存在加号，而 + 在路径中是合法字符不会被转义。先判断数据来自表单还是路径，再决定要不要还原。
- encodeURIComponent 和 encodeURI 该用哪个？
- 处理单个参数名或参数值时用 encodeURIComponent，它会把 & = ? / # 全部转义，拼接后不会破坏结构；处理一整条已经写好的 URL、只想转义空格和中文时用 encodeURI。整条链接都用 encodeURIComponent 的话，协议与路径里的斜杠会被编码，链接会失效。
- 为什么中文 URL 编码后长度变成三倍？
- UTF-8 下一个汉字占 3 个字节，每个字节写成 %XX 又要 3 个字符，所以「中」会变成 %E4%B8%AD 共 9 个字符。搜索引擎和多数服务端都按 UTF-8 处理，用 GBK 编码会产生不同结果并导致乱码。