URL 编码解码
免费在线 URL 编码与解码（percent-encoding）：区分 encodeURIComponent 与 encodeURI 两种范围，支持表单加号与双重编码检测，全部在浏览器内完成。
等待输入
使用步骤
- 粘贴要处理的文本或整段 URL
- 选择处理方式：只编码查询参数值，或保留 URL 结构只编码非法字符
- 确认结果是编码态还是解码态，必要时再点一次反向操作
- 复制结果放回代码或地址栏
工具说明
URL 只能安全携带极少数字符，其余都要写成「百分号加两位十六进制」的形式，这就是 percent-encoding。规则来自 RFC 3986：未保留字符 A 到 Z、a 到 z、0 到 9 和减号、下划线、句点、星号可以直接出现，保留字符如斜杠、问号、井号、与号、等号在结构里各有含义，出现在数据里时就必须编码，其他一切（包括中文、空格、emoji）一律编码。真正的坑在于「编码范围」：把一个查询参数的值整个交给 encodeURIComponent，斜杠、问号这些也会被编码，这是对的；但如果拿它处理整条 URL，结构本身会被毁掉，应该改用只跳过保留字符的 encodeURI。
本工具把这两种范围做成显式选项，正是为了避免这类静默错误。
另一个常见事故是表单：application/x-www-form-urlencoded 用加号表示空格，而 encodeURIComponent 产出的是%20，两边不匹配就会出现「数据库里存着一堆加号」的脏数据。
还有双重编码：一次编码的结果再编一次，%25 会开始成片出现，解码一次也还原不回去，本工具检测到疑似双重编码会明确提示而不是默默给你一个错的字符串。
常见问题
- 空格到底该编成 %20 还是加号？
- 看上下文。URL 路径与查询里用 %20；表单提交那种 application/x-www-form-urlencoded 编码体里用加号。两者混用是中文参数变乱码的最常见原因。
- encodeURIComponent 和 encodeURI 有什么区别？
- 前者连斜杠、问号、井号、与号都编码，适合处理一个参数值；后者保留这些结构字符，适合处理整条 URL。用错方向会得到打不开的链接或没编干净的中文。
- 解码一次没还原怎么办？
- 多半是被编码了两次。结果是里层还留着 %25 开头的片段，本工具会提示疑似双重编码；对这种输入重复执行解码即可，正常输入不会因此被改动。
- 中文参数解出来是乱码，是编码错了吗？
- 百分号编码承载的是字节，不是字符，所以乱码通常是两端字节解释不一致：发送端按 GBK 或 Big5 编了表单，接收端按 UTF-8 解；或者页面声明的 charset 与实际保存的字节不符。RFC 3986 的约定是路径与查询用 UTF-8，先确认两端一致再怀疑编码本身。另一个高频原因是加号：表单体里空格是加号，查询串规范里是 %20，把加号当字面量解就会得到空格，反之亦然。
- 要把整条 URL 都编码一遍吗？
- 不要。编码的单位是「每个组件里的值」，不是整条 URL。整条交给 encodeURIComponent 会把问号、斜杠、与号一起编掉，链接直接打不开；交给 encodeURI 又不会编与号和等号，值里带这两个字符时结构会被悄悄改写。查询串最稳的写法是逐项 set 进 URLSearchParams 再取字符串，值里的井号、问号、与号、加号都会被正确编。