URL 编解码
把中文参数转成 %E4%B8%AD%E6%96%87，或把乱码的链接还原。
encodeURIComponent 会转义 / ? & = 等分隔符，适合单个参数值；encodeURI 保留它们，适合整条链接。上面的「整段」用第一种（最常用），「只编码参数值」会按 ? 和 & 拆开逐个处理。
什么时候用
- 链接里带了中文、空格，或参数值里有已编码的 %26：用「只编码参数值」，? 和 & 的分隔结构保持不动，值里已有的百分号编码会先解码再编码、不会被叠加成 %2526，整条链接仍然点得开。
- 从日志、埋点或邮件里拿到 %E4%B8%AD%E6%96%87 这类串，需要还原成人能读的文本；emoji 这种 4 字节 UTF-8 序列也能正确还原。
什么时候不用
- 要构造 application/x-www-form-urlencoded 的表单体或待签名字符串：那套规则把空格写成 +，本工具输出 %20，严格实现里两者并不等价，请用 URLSearchParams 生成。
- 要整体编码一条 URL 但保留 https:// 和路径分隔符：那是 encodeURI 的活；本工具的整段模式和 encodeURIComponent 一样，会把 :// 也变成 %3A%2F%2F。
编解码在浏览器本地完成，输入不上传。限制：走原生 encodeURIComponent/decodeURIComponent，空格是 %20 而非 +；参数模式只按 ? 和 & 拆分，不管 # 片段与 ; 分隔；非法百分号序列会整体报错。
常见问题
为什么空格变成 %20 而不是 +？
encodeURIComponent 按 RFC 3986 处理，空格一律写成 %20；把空格写成 + 的是 HTML 表单那套 application/x-www-form-urlencoded 规则。查询串里多数框架两种都收，但严格实现只认自己那套：签名算法、OAuth、部分老网关会把 + 当成字面的加号。需要 + 时用 URLSearchParams 生成，别手工做字符替换——那样会把已经正确的 %2B 也一起弄坏。
解码提示「含有非法的百分号转义」怎么办？
decodeURIComponent 一旦遇到孤立的 %、%ZZ，或者 %E4 这种被截断的序列就直接抛错。常见原因有三个：链接被二次编码、被聊天软件按字数截断、原文里本来就有 100% 这种写法。先检查每个 % 后面是不是跟着两位十六进制；字面的百分号应该写成 %25。工具遇到非法序列会整体失败，不会给你一个解码了一半的结果，所以不会出现「看着像对、其实已经错位」的输出。
解码一次还是乱码，是不是要点两次？
是，那说明原文被编码了两次，常见于回调地址被塞进另一个跳转参数里。每次解码只剥一层：%25E4%25B8%25AD 变成 %E4%B8%AD，再变成「中」。连点是可以的，但要知道自己在剥第几层；更该做的是在源头改成只编码一次，双重编码还会让 + 和 & 的语义变得难以预测，排查时很容易误判。