URL十六进制编码解码

这里转换的是 UTF-8 字节

输入文本先转成 UTF-8 字节，每个字节再写成两位大写十六进制。默认格式给每个字节加上百分号，例如英文 Hello 变为 %48%65%6C%6C%6F；中文“你好”的六个 UTF-8 字节会显示为 %E4%BD%A0%E5%A5%BD。打开“Without %”选项后，同一结果写成连续的 48656C6C6F 或 E4BDA0E5A5BD。

解码方向会先去掉输入中的全部百分号，再按每两个十六进制字符组成一个字节，最后按 UTF-8 还原文本。因此解码输入既可以是 %48%65，也可以是 4865。

它和常见 URL 组件编码并不相同

RFC 3986 的百分号编码写作 %HH，但正常构造 URI 时，字母、数字、连字符、点、下划线和波浪线属于未保留字符，通常不应被生成器编码；冒号、斜杠、问号、井号等保留字符是否编码，还取决于它在 scheme、path、query 或 fragment 中承担的是分隔符还是数据。

当前转换会编码输入中的每一个 UTF-8 字节，连字母和 URL 分隔符也不例外。它更接近“文本的百分号十六进制表示”，适合观察字节或处理已明确要求全字节转义的数据；若把完整网址 https://example.com/a 直接编码，得到的冒号和斜杠也会变成十六进制，结果不能直接当作结构不变的网址。

规范依据与核验范围

编码和解码分别怎样操作

1. 选择方向

   普通文字转十六进制选“编码”；已有 %HH 或连续十六进制要还原文字则选“解码”。切换方向后会按当前输入重新计算。

2. 输入或粘贴内容

   文本变化时结果自动生成。也可载入页面示例：编码方向示例为 Hello，解码方向示例为 %48%65%6C%6C%6F。

3. 决定是否保留百分号

   编码时默认输出 %HH；需要纯十六进制字节串时打开“Without %”。这个选项不改变字节本身。

4. 检查错误并复制

   解码要求去掉百分号后的字符总数为偶数，且每一组都是两位 0-9、A-F、a-f。输入不合规则没有输出，并显示错误；成功后可复制结果。

两个可复现的转换例子

输入	模式	结果	说明
A 中	编码，保留 %	%41%20%E4%B8%AD	A 是一个字节，空格是 20，“中”是三个 UTF-8 字节。
F09F9880	解码	😀	四组十六进制字节组成一个 UTF-8 emoji。

若输入 %E4%B8，两组字节本身格式正确，但它不是完整的 UTF-8 中文字符序列，结果可能出现替换符号，而不一定报“十六进制格式错误”。

容易混淆的四个问题

为什么字母 H 也会变成 %48？

因为当前编码对全部 UTF-8 字节执行十六进制转换。RFC 3986 中未保留字符通常保留原样，但这里没有做那层选择。

空格会输出 %20 还是加号？

输出 %20。加号代表空格是表单编码中的约定，不是此处的全字节十六进制规则。

解码可以混用带 % 和不带 % 的写法吗？

只要删掉所有百分号后能形成连续的偶数位十六进制，就能解析，例如 %48%656C 会按 48656C 处理。为减少误读，建议整段统一一种格式。

这算加密吗？

不算。编码结果可直接逆向还原，没有密钥，也不提供机密性或完整性保护。

构造真实网址前要注意什么

不要把全字节输出直接替代完整 URL。scheme、主机、端口、路径、查询参数和片段中的分隔符承担结构含义；是否编码应按组件和接收端协议决定。

• 重复编码会把已有的百分号再次变成 %25 对应字节，造成双重编码；解码次数也应与上游编码次数匹配。
• 解码器只先校验“每两位是否为十六进制”。字节序列不是合法 UTF-8 时，结果可能含 � 替换字符；看到替换字符应回查原始字节和实际字符集。
• “Without %”输出没有分隔符，只适合偶数位字节串；丢失、插入任何一位都会让后续分组错位。
• 编码不是安全机制。敏感信息即使变成十六进制，仍能被任何人还原；传输保护应使用适当的安全协议。