URL 解码失败：%zz、结尾的 % 与非法 UTF-8 序列

解码器只做两件事：把 %XX 还原成字节，再把字节按 UTF-8 还原成字符。这两步各对应一类失败——前者是格式错（% 后面不是两位十六进制），后者是编码错（字节拼不出合法 UTF-8）。第三类更简单：结尾孤零零一个 %。

第一类：% 后面不是两位十六进制

合法写法只有 % 加两位 0-9 / A-F。出现 %zz、%G1、%2（只有一位）都会失败。

最常见的原因是双重编码没解干净：原文里的 % 本身就是数据，被编码成 %25 才对；如果直接拼进去，解码器会把 % 当成转义起始符。

另一个来源是手工拼接：从文档里复制了一段含 % 的文本（如「增长 50%」）直接放进 URL。

第二类：结尾多出一个 %

URL 在传输中被截断，最后一个 % 后面的两个字符丢了。常见于：日志系统按长度截断、复制时少选了两个字符、消息队列字段长度不够。

修法是找回完整原文；如果原文已经丢了，只能把结尾的 % 当普通字符处理（编码成 %25），接受末尾数据缺失。

第三类：%XX 组合不是合法 UTF-8

每个 %XX 单独看都合法，但拼起来的字节序列不符合 UTF-8 规则。典型情况：

• GBK 数据用 UTF-8 解：%D6%D0 在 GBK 里是「中」，但 D6 不是合法的 UTF-8 起始字节。
• 字节被截断：一个汉字 3 个字节，只传了前 2 个。
• 二进制数据：图片、加密串被当成文本编码，字节序列本来就不是文字。

这一类最容易被误判成「工具坏了」，其实是数据本身不是 UTF-8 文本。

提示只说明原因，不改写输入

三类错误都会指出问题出在第几个字符，并给出中文原因。提示不会改写、也不会清空你的输入——原文保留，你可以对照位置自己改。

这一条很重要：很多在线工具遇到非法输入会「尽力修复」，把非法字节替换成问号或 U+FFFD，结果你看到的是一段被改过的文本，反而找不到原问题。