16进制转url编码：一眼看懂编码差异

先分清：十六进制字节和百分号编码不是两个世界

十六进制是数字的一种写法，一个字节通常写成两位，比如 E4、B8、AD。URL编码则是把不能直接出现在地址里的字节，前面加个百分号再跟两位十六进制。所以 %E4%B8%AD 拆开看就是三个字节 E4 B8 AD，它们按UTF-8解释恰好是「中」字。

不少人把「16进制转url编码」理解成某种进制换算，其实中间没有算术运算，只是表示形式的切换：一边是连续的十六进制串，一边是带百分号分隔的串。真正要留意的，是这段字节该按哪种字符集解释。同一串字节用UTF-8和GBK读出来，结果可能完全不同。

什么时候会真的用到这种转换

做接口联调时，签名串里常混着百分号编码，而日志工具又习惯把原始字节打成十六进制，两边对不上就得手动还原。再比如从浏览器地址栏复制一段带中文的查询参数，粘到代码里之前，先看看它到底是已编码还是原样，能省掉重复编码的坑。

还有一种场景是排查「参数看起来对、服务端却收错」的问题。把请求里的百分号串拆成十六进制字节，再和预期字符串的字节逐位比对，往往能发现多了一个空格、少了一个换行，或者某个符号被编码成了别的形式。这种对照比盯着两串乱码猜要可靠得多。

转换时容易踩的几个坑

第一个坑是大小写。十六进制里的字母用大写还是小写，不同工具输出不一致，而某些签名校验对大小写敏感。转换前先确认目标环境的要求，别想当然。

第二个坑是保留字符。像斜杠、问号、井号、与号这些在URL里有语法含义的符号，编码与否会改变解析结果。把十六进制字节还原成百分号形式时，要判断这个字节原本是不是保留字符，不能一律编码或一律放过。

第三个坑是空格。空格在URL里可以写成加号，也可以写成百分号加两位十六进制，两种写法在不同上下文中含义有别。看到加号时别急着当成普通字符，先想想它是不是空格的替身。

第四个坑是重复编码。一段已经编码的串再转一次，百分号本身会被编码成 %25，结果越滚越长。转换前先判断输入是否已经处于编码状态，比事后反复调试省事。

动手转换时的稳妥做法

先确定字符集，再动手。中文内容在多数现代场景下按UTF-8处理，但老系统、老接口仍可能用别的编码，拿不准就两边都试一下，看哪边能还原出可读文本。

接着把输入规整成统一的字节序列：去掉多余的分隔符和空白，把连续的十六进制串按两位一组切开，确认每组都是合法字节。然后逐个字节判断是否需要百分号包裹，保留字符按上下文决定去留。最后把结果拼回去，用一次解码验证能否还原，能还原就说明转换方向没弄反。

如果只是核对而不是改写，可以只做单向观察：把百分号串拆成字节列表，和预期值并排看。这样不动原始数据，排查起来更安全。

相关文章

• base64编码程序16进制：输出里为什么常看到十六进制

  解释Base64编码结果与十六进制表示的关系，说明程序输出十六进制串的原因、转换方法与常见误区。

• base64编码的二进制文件下载：从困惑到清晰

  解释base64编码如何让二进制文件通过文本传输，并实现下载，澄清常见误解，提供实用建议。

• base64编码的二进制图片数据库：存储与查询的取舍

  探讨base64编码图片在数据库中的存储方式，分析其优缺点、适用场景与查询效率，帮助开发者做出合理选择。

• base64编码的二进制图片数据：为何体积变大却仍被广泛使用

  解释base64编码的二进制图片数据为何体积膨胀却常见于网页与接口，分析其适用场景、判断方法与处理思路。

• base64编码的二进制图片：为什么图片会变成一串字符

  解释图片二进制数据转成 Base64 文本后的体积变化、适用场景与还原方法，帮助判断何时该用文本内嵌、何时该保留原文件。

常见问题