工具说明

关于 Base64 与十六进制互转工具

Base64 to Hex 把编码后的载荷转成底层字节的十六进制视图，让你逐字节地读一段二进制数据，而不用对着一大片 Base64 字符猜里面装的是什么。

它支持双向转换，会剥掉 data URI 前缀和 PEM 头尾行，接受带不带 0x、带不带分隔符的十六进制，并给出字节数；当开头几个字节匹配已知特征码时，还会报出识别到的文件类型。

Base64 to Hex 怎么用

把编码值粘进输入框；data:image/png;base64, 这样的前缀，或 PEM 块的 BEGIN 与 END 行都会自动去掉，空白字符也会被忽略。
用方向按钮在 Base64 转十六进制和十六进制转 Base64 之间切换。
十六进制输入不挑格式：裸数字、带 0x 前缀，或用空格、冒号、连字符分隔的字节，粘进来就行。
需要时打开大写输出或字节间加空格，以匹配你的调试器或协议文档的排版。

什么时候用得上

把证书或密钥的 PEM Base64 主体转成十六进制，手工走一遍 DER 结构，查看原始字节。
检查文件或图片开头的魔数，确认它的真实类型，而不是听信扩展名。
调试二进制协议帧、固件载荷，或那些以十六进制记录、却以 Base64 传输的密码学测试向量。
把抓包工具导出的十六进制转成 Base64，好粘进配置文件或 API 请求体。

Base64 和十六进制如何表示同一串字节

两者都是同一段字节序列的文本表示，只是在密度和可读性上各自朝相反方向取舍。

Base64 把 3 个字节压进 4 个字符，因此编码后的文本比原始数据大约大 33 个百分点。
末尾的 = 是填充，当输入长度不是 3 的倍数时补上。
十六进制是 1 字节固定对应 2 个字符，体积翻倍，但每个字节的偏移量是固定的。
这种固定映射正是调试时十六进制更好用的原因：第 12 个字节永远从第 24 个字符开始，规范里的偏移量和你眼睛看到的能对齐。

Base64 转十六进制常见问题

为什么我的 Base64 图片或证书，在普通 Base64 解码器里显示成乱码？: 多数解码器把结果按 UTF-8 文本显示。二进制载荷里含有不构成合法文本的字节值，于是渲染成替换字符或者直接被弄坏。十六进制没有这个问题。
可以直接粘一整块 PEM 或一段 data URI 吗？: 可以。BEGIN 和 END 标记行以及 data URI 前缀会在解码前被剥掉，换行也会被忽略。
反方向支持哪些十六进制格式？: 0x 前缀、纯十六进制数字，以及用空格、冒号或连字符分隔的字节都可以。分隔符会在重新编码前被去掉。
识别到的文件类型是什么意思？: 开头的字节会与 PNG、JPEG、GIF、PDF、ZIP、GZIP 和 DER 的已知特征码比对。都不匹配时就不显示类型，而不是硬猜一个。
我的数据会被上传吗？: 不会。解码、重新编码和特征识别全在你的浏览器里进行，密钥、证书和抓到的帧不会发往 wetool.site。

Base64 to Hex 与面向文本的 Base64 解码器

通用的 Base64 编解码器走的是 UTF-8 文本路径：先解出 Base64，再把结果当字符串解释。对 JSON 和可读令牌来说没问题，但 PNG 文件头、DER 编码的证书或二进制协议帧里的字节值没有合法的文本含义，输出就会变成乱码，往回转时还可能丢字节。本页根本不碰文本这一层，它在字节层面做 Base64 与十六进制的互转，所以 0x00、0xFF 以及任何不合法的 UTF-8 序列都能原样完成一次往返。

逐字节读十六进制转储

载荷一旦变成十六进制，开头几个字节通常就能告诉你手里拿的是什么。

89 50 4e 47 是 PNG 文件，ff d8 ff 标志着 JPEG 数据的开头。
25 50 44 46 是 PDF，50 4b 03 04 是 ZIP 或任何基于 ZIP 的容器，1f 8b 是 GZIP。
开头是 30 82 则是 DER 结构的 SEQUENCE 标签，证书或密钥主体的 PEM Base64 解码之后就长这样。
十六进制数字个数为奇数就凑不成完整字节，此时检查复制来的转储首尾是不是少了一位。