URL 在线编码解码
在线 URL 编码解码工具，把中文、空格与特殊字符转成 %E4%B8%AD 这样的百分号编码，也能反向还原；支持参数值与整条网址两种编码口径，解码会指出出错位置并区分 UTF-8 与 GBK，全部在浏览器本地完成，内容不上传。
| 原始字符 | 码点 | UTF-8 字节 | 编码结果 |
|---|
这个工具能做什么
它把「不能在网址里直接出现的字符」换成可以安全传输的写法，也能把这种写法还原回原文。所有计算都在你自己的浏览器里完成，输入的内容不会发到任何服务器。
- 编码：把中文、空格、换行和各种符号换成百分号编码，例如「中」变成 %E4%B8%AD。
- 解码：把 %E4%B8%AD%E6%96%87 这样的内容还原成「中文」，小写十六进制（%e4%b8%ad）一样能解。
- 两种编码口径：编一个参数值，还是编一整条网址，保留的字符范围不一样，选错了会出真问题。
- 逐字符对照：编码后可以一行一行看清楚哪个字变成了哪几个字节，不用再猜。
- 出错能定位：百分号写错、字节不完整、编码不是 UTF-8，都会告诉你出错的位置和原因。
三种常见场景，口径该怎么选
场景一：要给某个参数配一个值（搜索词、文件名、令牌、带中文的查询条件）。用默认的「参数值」口径。它会把和号、等号、问号、斜杠这些符号也一起编码，这样服务器解析时才不会把一个参数错拆成两个。这是最常用的场景，拿不准就选它。
场景二：手上是一条完整网址，只想把里面的中文和空格处理掉。选「整条网址」口径。它会保留冒号、斜杠、问号、和号、等号、井号这些网址自身的语法符号，只处理中文和空格这类不能直接出现的字符，整条链接贴到浏览器里仍然能打开。
场景三：拿到一串看不懂的百分号编码要还原。切到解码方向。如果这串来自表单提交或查询串（常见特征是里面出现了加号），把「加号的含意」切到「加号代表空格」；如果是网址路径或一段普通文本，保持默认的「加号就是加号」，以免把真实的加号吃掉。
为什么中文会变成 %E4%B8%AD 这样的东西
网址里只允许出现一小部分 ASCII 字符，其余字符必须换一种写法。以一个常用汉字为例，过程分两步：先把「中」按 UTF-8 编成三个字节 E4、B8、AD，再把每个字节写成「百分号 + 两位十六进制」，得到 %E4%B8%AD。所以一个汉字编码后是 9 个字符（3 个字节，每个字节占 3 个字符），emoji 通常占 4 个字节，编码后是 12 个字符。这也是为什么把一段中文放进网址后链接会突然变得很长——它没有变复杂，只是换了一种写得更长的表示法。
逆向操作要做两件事：先把每三位一组还原成字节，再把字节按 UTF-8 解回文字。解码失败通常就卡在这两步中的一步，所以本工具把两类错误分开提示：百分号后面不是两位十六进制，属于写法问题；字节拼起来不是合法 UTF-8，属于编码来源问题。后者在国内很常见，因为不少老系统用的是 GBK，「中」在 GBK 里是 %D6%D0，和 UTF-8 的 %E4%B8%AD 完全不同。
常见字符对照
- 空格 → %20（表单提交里也常写成加号）
- 加号 + → %2B（注意：查询串里的加号常常代表空格，不是真加号）
- 斜杠 / → %2F，问号 ? → %3F，等号 = → %3D
- 和号 & → %26，井号 # → %23，百分号 % → %25
- 换行 → %0A，制表符 → %09
- 中文「中」→ %E4%B8%AD（3 字节），中文「好」→ %E5%A5%BD（3 字节）
- emoji 😀 → %F0%9F%98%80（4 字节），中间点 · → %C2%B7（2 字节）
一个实用习惯：如果一段文本里本来就有单独的百分号（例如「增长了 100%」），要编码时先把那个百分号写成 %25，否则解码方看到百分号后面不是十六进制就会报错。
关于数据安全
编码和解码全部由页面里的 JavaScript 完成，输入内容不会上传，也没有账号和登录。这一点对处理接口返回、调试参数、临时查看一串可疑链接尤其重要：可以直接粘进来，关掉页面后不会留下记录。唯一需要注意的是，本页面本身是公开可访问的网址，请不要把密码、身份证号等敏感信息粘到任何在线工具里——包括本站。
常见问题
URL 编码和 Base64 有什么区别？
两者要解决的问题不同。URL 编码（百分号编码）解决的是「这些字符不能直接出现在网址里」，它把每个字节写成百分号加两位十六进制，结果仍然保留了原文的结构，像 %E4%B8%AD 一眼就知道是三个字节；Base64 解决的是「二进制数据要塞进纯文本通道」，它按 3 字节一组重新映射到 64 个字符上，体积变成约 1.33 倍，但看不出原文结构。两者都不是加密，拿到字符串谁都能还原，所以都不能用来保存密码。
为什么中文编码后变成 %E4%B8%AD 这样的东西？
因为网址里只允许出现一小部分 ASCII 字符，中文必须换一种写法。过程分两步：先把「中」按 UTF-8 编成三个字节 E4 B8 AD，再把每个字节写成百分号加两位十六进制，于是得到 %E4%B8%AD。一个常用汉字在 UTF-8 里正好是 3 个字节，所以中文编码后长度大约是原来的 9 倍（3 个字节，每个字节写成 3 个字符）；emoji 通常占 4 个字节，编码后是 12 个字符。页面上的逐字符对照表会把这笔账一行一行列出来。
编码后的加号变成了空格（或空格变成了加号）是怎么回事？
这是表单编码留下的历史习惯：在老式的表单提交（application/x-www-form-urlencoded）里，空格被写成加号，而真正的加号必须写成 %2B。所以同一个加号在两种语境下含义正好相反，查询串里它常常代表空格，而路径里它就是加号本身。本工具默认把加号当普通字符处理，不会悄悄还原成空格；如果你解的是表单提交或查询串，请在「解码时加号的含意」里切到「加号代表空格」。最稳妥的做法是编码时就用 %20 表示空格、用 %2B 表示加号，这样谁都不会误解。
解码提示「不是合法的 UTF-8 序列」是什么原因？
意思是这一串里的百分号编码写法都对（每个百分号后面确实是两位十六进制），但这些字节拼起来不构成一个合法的 UTF-8 字符，所以没有对应的文字。最常见的原因有两个：一是原文用 GBK 编码，例如「中」在 GBK 里是 %D6%D0，在 UTF-8 里是 %E4%B8%AD，前者用本工具解不出来；二是字符串被截断了，末尾少了一个字节，比如 %E4%B8 只有两个字节，凑不成一个汉字。这两种情况都要回到源头改编码或补全字符串，本工具不会硬猜一个结果给你。
encodeURI 和 encodeURIComponent 有什么区别，该用哪个？
区别在于保留哪些字符。encodeURI 会保留井号、美元号、和号、加号、逗号、斜杠、冒号、分号、等号、问号、at 号这些在网址里有语法含义的符号，适合编码一整条已经拼好的网址；encodeURIComponent 会把它们全部编码，适合编码某个参数的值。判断标准很简单：这段内容如果是网址结构的一部分（协议、主机、路径分隔符、参数分隔符），就用它自己的符号原样保留；如果是用户填的一个值（搜索词、文件名、令牌），就用默认的「参数值」口径整个编码。用反了会出真问题：把带和号的参数值按整条网址编码，和号不会被转义，服务器会把一个参数拆成两个。