符合 RFC 3986 规范的 encodeURIComponent / decodeURIComponent 双向转换，支持自定义保留字符。数据全部在浏览器本地处理。
URL 编码（百分号编码）的规则很简单：把 URL 里不允许直接出现的字符（中文、空格、&、=、? 等）转成 %XX 的十六进制形式，传输后再解码还原。最典型的场景：给接口拼查询参数时参数值里有中文或特殊符号——不编码的话，值里的 & 会被当成参数分隔符、空格会截断请求，服务端拿到的就是错的。使用本页的步骤：在上面的输入框粘贴要处理的文本或整段 URL，选择编码模式后点「URL 编码」，结果框实时给出编码结果和字节变化统计；反向操作把编码后的字符串贴进结果框，点「URL 解码」还原。页面下方还有编码明细（原长、编码后长度、编码字符数），方便核对。
重点讲讲 encodeURI 和 encodeURIComponent 的区别——这是本工具模式切换的核心。encodeURI 设计给"编码一个完整 URL"：它保留 ://、?、&、=、# 这些结构性字符，只处理路径和参数值里的非法字符，所以编码整条 https://example.com/search?q=你好 时协议和参数结构原样保留。encodeURIComponent 则设计给"编码一个参数值"：除了字母、数字和 -_.~ 之外全部转义，包括 & 和 =，确保值里混入任何字符都不会破坏 URL 结构。经验法则：编码整条 URL 用 encodeURI，编码塞进 URL 的每一段值用 encodeURIComponent。绝大多数 bug 来自该用后者时用了前者（值里的 & 没转义，参数被拆散）。拿不准就选 encodeURIComponent，它总是"更安全"的那个。
我输入的内容会传到服务器吗？不会。本页面是纯静态页面，编码解码全部在浏览器内由 JavaScript 完成，没有任何网络请求和存储行为。URL 里可能带的 token、内部地址、调试参数都不会离开你的设备。
解码结果里 + 没变成空格，或编码时空格变成了 +，怎么回事？空格有两种合法表示：%20（RFC 3986 标准percent编码）和 +（仅 HTML 表单 application/x-www-form-urlencoded 约定使用）。本工具遵循 RFC 3986，输出 %20、不把 + 解码成空格。如果你拿到的是表单风格字符串（a+b 应为 a b），先手动把 + 替换成 %20 再解码；反过来，给传统 CGI/PHP 后端传参时可能需要表单风格。
中文是怎么被编码的？为什么一个汉字变成 9 个字符？中文先按 UTF-8 转成字节（多数常用汉字 3 字节），每个字节再编码成 %XX（3 个字符），所以一个汉字是 9 个字符，如"你" → %E4%BD%A0。如果对端按 GBK 解码就会乱码——和 Base64 一样，编码本身没问题，问题是两端字符集要一致。
哪些字符其实不需要编码？RFC 3986 规定的 unreserved 字符：字母、数字、-、_、.、~。这些在 URL 任何位置都可以直接出现，编不编码等价。另外路径分隔符 /、查询标记 ?、参数分隔 & 和 = 在"编码整条 URL"场景（encodeURI 模式）下会保留——它们是结构，不是内容。
浏览器地址栏里中文明明能直接显示，还要编码吗？那是浏览器的显示美化：地址栏把 %E4%BD%A0%E5%A5%BD 渲染回"你好"给你看，实际发送的请求里仍然是百分号编码。复制地址栏时行为因浏览器而异（可能复制出解码后的中文），所以拼接 URL、写爬虫、发请求之前，对参数值做一次显式编码永远是好习惯。