Base64、Hex、百分号编码与 Base85：按传输场景选择

编码必须由两端共同约定才有意义。字符最少的表示不一定最好：接收方可能只接受特定字母表，人可能需要手工输入，外层语法也可能赋予某些标点特殊含义。先检查目标协议。

Hex 易读，但体积更大

十六进制每个字节使用两个字符。FF 00 41 写成 ff0041，每两个字符都有明确的字节边界，适合查看文件头、校验和与网络报文。字符数量翻倍，但小型字母表容易进入日志和调试工具。

Base64 每三个字节对应四个字符。标准版使用加号与斜杠，Base64URL 按协议替换它们。两端仍需约定填充和空白规则。它们都不会说明解码后的内容究竟是文本、图片还是压缩数据。

百分号编码把需要转义的字节写成 %HH。哪些字符需要转义取决于 URL 组件。文本先转为 UTF-8，再编码。斜杠可能分隔路径，问号可能开始查询；把整个 URL 当成一个组件，会改变含义。

console.log(encodeURIComponent('a+b / 中文'));
// a%2Bb%20%2F%20%E4%B8%AD%E6%96%87

许多 Base85 方案用五个字符表示四个字节，但字母表、分隔符和特殊缩写不同。ASCII85 与 Z85 不能直接互换，Z85 还有块长度要求。外层格式如果需要再次转义标点，密度优势也可能缩小。

这些字节编码与把整数 255 转为不同进制不是一回事。文件可以有前导零字节，整数表示却可能丢弃前导零。无损文件编码必须定义长度与前导零的保存方式。

检查字节用 Hex，通用二进制传输使用协议规定的 Base64 变体，URL 使用组件编码，专用方案则要求双方实现相同契约。应比较转义和压缩后的总成本。Base16、Base32、Base64 的标准见 RFC 4648。