2026-02-10 14:09:54 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文系统解析Base编码家族，从Base2到Base256，按2的幂次、优化型、压缩型三类阐述核心原理与场景。重点详解Base16/32/64等常用编码及Base45/58/62/85等特殊变体，提供效率对比表与选择指南。文末提及Base编码在免杀木马中的混淆应用，但指出现代EDR需结合多层技术对抗。 综合评分： 78 文章分类： 渗透测试,代码审计,恶意软件,安全开发,CTF

Base85 变种

Base85 用 ASCII 33(!) 到 ASCII 117(u) 共85个可打印字符，把每4字节编码为5个字符，膨胀率仅 25%（优于 Base64 的 33%）。

Standard（Ascii85 / btoa）

字符范围：! " # $ % & ' ( ) * + , - . / 0-9 : ; < = > ? @ A-Z [ \ ] ^ _ ` a-u
即 ASCII 33-117

Adobe PostScript/PDF 中使用，格式以 <~ 开头 ~> 结尾。特殊优化：4个 \x00 编码为单个 z。

<~87cURD]j7BEbo80~> &nbsp; &nbsp;← "Hello World"

Z85（ZeroMQ）

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-:+=^!/*?&<>()[]{}@%$#

专门为 ZeroMQ 消息帧 设计。刻意避开了 '(单引号) 和 "(双引号)，这样编码结果可以安全地放在 JSON 字符串或各种编程语言的字符串字面量里，不需要转义。

IPv6 Base85（RFC 1924）

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz!#$%&()*+-;<=>?@^_`{|}~

把 128-bit 的 IPv6 地址编码为 恰好20个字符：

标准: &nbsp;2001:0db8:85a3::8a2e:0370:7334
Base85: 9R}vSQ*E5@FLbBxBP54

不过这个 RFC 是 1996年愚人节发布的（April 1st RFC），从未被正式采用，但算法本身是可用的。

Base91

基本信息

• 字符数: 91
• 字符集: 可打印ASCII (去除 \, ', ")
• 效率: ~81-82%

字符集

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!#$%&()*+,./:;<=>?@[]^_`{|}~"

应用场景

• 数据压缩后的编码
• 网络传输优化

Base91 的核心巧妙之处在于变长取位：

缓冲区够13bit时:
&nbsp; 低13bit值 >= 88 → 取13bit → 2字符表示 &nbsp;(91²=8281 能覆盖 8191-88+1=8104种)
&nbsp; 低13bit值 < 88 &nbsp;→ 取14bit → 2字符表示 &nbsp;(91²=8281 能覆盖 88×91+剩余 种)

这样每2个输出字符承载 13~14 bit，平均约 6.5 bit/字符，比 Base85 的 6.4 bit/字符再好一点。至于 Base92 只是多了1个字符，原理完全一样，91 变 92，收益微乎其微（理论极限 log₂(92)=6.52 vs log₂(91)=6.51），实际没什么人用。

Base92

基本信息

• 字符数: 92
• 字符集: 92个可打印字符
• 效率: ~82%

字符集

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!#$%&()*+,-./:;<=>?@[]^_`{|}~"

Base100 (Emoji编码) 😄

推荐仓库：https://github.com/AdamNiederer/base100 推荐仓库：https://github.com/stek29/base100

基本信息

• 字符数: 100
• 字符集: 100个Emoji表情
• 特点: 视觉友好，趣味性

Base100 很有意思，它把每个字节映射成一个 emoji。

🎨 核心原理

每个字节（0-255）编码为一个 UTF-8 的 4 字节 emoji：

固定前缀: F0 9F &nbsp;(所有emoji都以这两个字节开头)
第3字节: &nbsp;(b + 55) // 64 + 143
第4字节: &nbsp;(b + 55) % 64 + 128

本质就是把 字节值+55 拆成高6位和低6位，塞进 UTF-8 的编码结构里。

逐步演示

字符 'H' = 72

&nbsp; 72 + 55 = 127
&nbsp; 第3字节: 127 // 64 + 143 = 1 + 143 = 144 = 0x90
&nbsp; 第4字节: 127 % 64 + 128 &nbsp;= 63 + 128 = 191 = 0xBF

&nbsp; → F0 9F 90 BF → UTF-8解码 → 🐿 (花栗鼠)

字符 'i' = 105

&nbsp; 105 + 55 = 160
&nbsp; 第3字节: 160 // 64 + 143 = 2 + 143 = 145 = 0x91
&nbsp; 第4字节: 160 % 64 + 128 &nbsp;= 32 + 128 = 160 = 0xA0

&nbsp; → F0 9F 91 A0 → 👠 (高跟鞋)

"Hi" → 🐿👠

为什么 +55？

这个偏移量让字节值 0-255 刚好映射到 Unicode 中一段连续的 emoji 区域（U+1F300 附近开始），确保每个输出都是合法的 emoji 字符。

和其他 Base 的本质区别

| | 其他Base编码 | Base100 | | — | — | — | | 目的 | 压缩/传输 | 纯娱乐 | | 映射 | 多字节→少字符 | 1字节→1 emoji | | 膨胀率 | 23-33% | 300% (1字节→4字节) | | 效率 | 越高越好 | 完全不在乎 |

这是所有 Base 编码里膨胀率最高的，但也是最好玩的——Hello World 变成一串 emoji 🐿👜👣👣👦🐗👎👦👩👣👛，看起来就是在发表情。CTF 里偶尔出现，看到一串连续 emoji 就该想到 Base100。

🔻 比Base16更小的编码

| 编码 | 字符数 | 公式 | 效率 | 膨胀率 | 应用场景 | | — | — | — | — | — | — | | Base2 | 2 | 2^1 | 12.5% | 800% | 二进制展示、教学 | | Base3 | 3 | – | 20.9% | 478% | 三进制计算 | | Base4 | 4 | 2^2 | 25% | 400% | DNA序列 (ACGT) | | Base5 | 5 | – | 29.1% | 344% | 理论研究 | | Base8 | 8 | 2^3 | 37.5% | 267% | Unix权限 (chmod) | | Base10 | 10 | – | ~42% | ~240% | 电话号码、身份证 |

Base10 (Decimal)

基本信息

• 字符数: 10
• 字符集: 0-9
• 效率: ~42%

应用场景

人类最熟悉的进制！

常见用途：
- 电话号码
- 银行账号
- 身份证号
- 订单号
- 验证码

示例

订单号: 20240207153045
验证码: 749283

🔺 比Base100更大的编码

Base122 (UTF-8优化)

基本信息

• 字符数: 122
• 字符集: 122个UTF-8安全字符
• 效率: ~87%

编码原理

UTF-8 单字节范围是 0x00-0x7F（共128个值）。去掉6个不安全的字符：

0x00 (NULL) &nbsp; &nbsp;— 字符串终止符，C语言会截断
0x08 (退格) &nbsp; &nbsp;— 控制字符
0x09 (Tab) &nbsp; &nbsp; — 可能被HTML/编辑器吃掉
0x0A (换行) &nbsp; &nbsp;— 会被当作行结束
0x0D (回车) &nbsp; &nbsp;— 同上
0x5C (\) &nbsp; &nbsp; &nbsp; — 转义字符，各种语言都特殊处理

剩下 128 – 6 = 122 个安全字符，每个只占 1 字节。

应用场景

• 现代网络传输
• UTF-8环境优化

为什么叫”UTF-8 优化”

关键对比：

Base85 编码 "Hello World":
&nbsp; 每个输出字符是 ASCII 可打印字符 → 每字符 1 字节
&nbsp; 效率: 6.4 bit/字符 → 膨胀 25%

Base91 编码:
&nbsp; 同上 → 每字符 1 字节
&nbsp; 效率: 6.5 bit/字符 → 膨胀 23%

Base100 编码:
&nbsp; 每个输出是 emoji → 每字符 4 字节 UTF-8
&nbsp; 效率: 2 bit/字节 → 膨胀 300%

Base122 编码:
&nbsp; 每个输出字符在 UTF-8 中仍然只占 1 字节
&nbsp; 但可用字符数从91个提升到122个
&nbsp; 效率: log₂(122) ≈ 6.93 bit/字符 → 膨胀仅 ~14%

Base122 的意思是：在保证每个输出字符 UTF-8 单字节（不会被任何文本处理环节破坏）的前提下，把可用字符数推到极限。 它利用了那些不可打印但在 UTF-8 传输中完全安全的字节值（比如 0x01-0x07 这些控制字符虽然不可打印，但在 HTTP body、JSON 字符串、HTML <script> 标签内传输时不会被篡改）。

所以”UTF-8 优化”的含义是：针对 UTF-8 环境最大化单字节利用率，不像 Base85/91 只敢用可打印字符那么保守，也不像 Base100 用 emoji 那么浪费，而是精确地选出所有在 UTF-8 文本传输中安全的单字节字符。

它最初的设计场景是在 HTML 的 <script> 标签内嵌入二进制数据（如 WebAssembly），用 Base122 比 Base64 小很多，浏览器解析更快。

Base128 (已介绍)

见前文”第一类：2的幂次编码”部分

Base256 (已介绍)

见前文”第一类：2的幂次编码”部分

🤔 理论上还有更大的吗？

推荐阅读：What are Base96, Base128, Base256, and Base512? Do They Really Exist?[8]

实用最大值: Base122

✅ 使用UTF-8安全字符
✅ 效率87%（接近Base128）
✅ 可跨平台传输
✅ 兼容性好

📊 编码效率对比

效率公式

编码效率 = 原始数据大小 / 编码后数据大小

膨胀率 = 编码后数据大小 / 原始数据大小

完整对比表

| 编码 | 字符数 | 类型 | 效率 | 膨胀率 | 1KB编码后 | 分组方式 | | — | — | — | — | — | — | — | | Base2 | 2 | 2^1 | 12.5% | 800% | 8.0 KB | 1 bit/char | | Base4 | 4 | 2^2 | 25% | 400% | 4.0 KB | 2 bit/char | | Base8 | 8 | 2^3 | 37.5% | 267% | 2.67 KB | 3 bit/char | | Base10 | 10 | 特殊 | ~42% | ~240% | ~2.4 KB | 数学除法 | | Base16 | 16 | 2^4 | 50% | 200% | 2.0 KB | 4 bit/char | | Base32 | 32 | 2^5 | 62.5% | 160% | 1.6 KB | 5 bit/char | | Base45 | 45 | 优化 | ~68% | ~147% | ~1.47 KB | 数学除法 | | Base58 | 58 | 优化 | ~73% | ~137% | ~1.37 KB | 数学除法 | | Base62 | 62 | 优化 | ~74% | ~135% | ~1.35 KB | 数学除法 | | Base64 | 64 | 2^6 | 75% | 133% | 1.33 KB | 6 bit/char | | Base85 | 85 | 压缩 | 80% | 125% | 1.25 KB | 32 bit→5 char | | Base91 | 91 | 压缩 | ~82% | ~122% | ~1.22 KB | 变长 | | Base92 | 92 | 压缩 | ~82% | ~122% | ~1.22 KB | 变长 | | Base100 | 100 | 趣味 | 变化 | 变化 | 变化 | 变化 | | Base122 | 122 | 压缩 | ~87% | ~115% | ~1.15 KB | 数学除法 | | Base128 | 128 | 2^7 | 87.5% | 114% | 1.14 KB | 7 bit/char | | Base256 | 256 | 2^8 | 100% | 100% | 1.0 KB | 8 bit/char |

🎯 选择指南

场景推荐表

性能对比

编码速度 (从快到慢)

1. Base16 (最快 - 简单bit位移)
2. Base64 (很快 - bit分组)
3. Base32 (快 - bit分组)
4. Base85 (中等 - 需要除法)
5. Base58 (较慢 - 大整数除法)
6. Base91 (慢 - 复杂算法)

兼容性 (从好到差)

1. Base16 (最佳 - 所有系统支持)
2. Base64 (极佳 - 标准库支持)
3. Base32 (良好 - 标准库支持)
4. Base85 (一般 - 部分系统支持)
5. Base58 (一般 - 需要第三方库)
6. Base45 (较差 - 新标准)
7. Base91+ (差 - 需要专门实现)

💡 核心要点总结

1. 为什么Base58/Base45不是2^n？

Base58设计理念:
目标 ≠ 数学完美
目标 = 解决实际问题（避免混淆）

方法: Base64 (64字符) - 易混淆字符 (6个) = 58

Base45设计理念:
目标 ≠ 通用编码
目标 = QR码存储优化

方法: 使用QR码字母数字模式支持的45个字符

2. 2^n编码 vs 非2^n编码

2^n编码 (Base2/4/8/16/32/64/128/256)

优点:
✅ 可以直接bit操作（位移、掩码）
✅ 编码解码速度快
✅ 实现简单
✅ CPU友好

缺点:
❌ 字符集不灵活
❌ 可能包含特殊字符

非2^n编码 (Base10/45/58/62/85/91等)

优点:
✅ 字符集可定制
✅ 可优化特定场景
✅ 避免问题字符

缺点:
❌ 需要除法运算
❌ 编码解码较慢
❌ 实现复杂

3. 编码效率排行

效率最低: Base2 (12.5%) &nbsp;- 膨胀8倍
教学演示: Base16 (50%) &nbsp; - 膨胀2倍
通用平衡: Base64 (75%) &nbsp; - 膨胀1.33倍 ⭐
高效压缩: Base85 (80%) &nbsp; - 膨胀1.25倍
极限压缩: Base122 (87%) &nbsp;- 膨胀1.15倍
理论极限: Base256 (100%) - 无膨胀

4. 最常用的5种编码

🥇 Base64 &nbsp;- 通用标准，70%的场景
🥈 Base16 &nbsp;- 调试哈希，20%的场景
🥉 Base32 &nbsp;- 双因素认证
🏅 Base58 &nbsp;- 区块链专用
🏅 Base85 &nbsp;- PDF/Git专用

5. 填充字符的意义

为什么Base64需要填充'='？

3字节 = 24 bit → 4个Base64字符 (完美)
2字节 = 16 bit → 3个Base64字符 + 需要填充
1字节 = 8 bit &nbsp;→ 2个Base64字符 + 需要填充

'=' 告诉解码器: "后面的bit应该忽略"

示例:
"A" &nbsp; → "QQ==" (1字节，填充2个=)
"AB" &nbsp;→ "QUI=" (2字节，填充1个=)
"ABC" → "QUJD" (3字节，无需填充)

6. 特殊编码的独特优势

Base58:
&nbsp; 去除: 0, O, I, l, +, /
&nbsp; 优势: 人类手写友好，OCR准确
&nbsp; 应用: 比特币地址

Base45:
&nbsp; 字符: QR码字母数字模式的45个字符
&nbsp; 优势: 在QR码中节省30%空间
&nbsp; 应用: COVID健康证书

Base85:
&nbsp; 压缩: 4字节→5字符 (vs Base64的4字节→5.33字符)
&nbsp; 优势: 比Base64节省25%空间
&nbsp; 应用: PDF文件
&nbsp; 特殊: 全零→'z'压缩

7. 理论边界

最小有意义编码: Base2 (二进制)
最大实用编码: &nbsp; Base122 (UTF-8安全)
理论极限: &nbsp; &nbsp; &nbsp; Base256 (原始字节)

超过Base256？
→ 技术可行(Base65536 Unicode)
→ 实际无用(兼容性/可读性差)

📚 参考资源和🎓 学习建议

标准文档

• Base64: RFC 4648[9]
• Base32: RFC 4648
• Base16: RFC 4648
• Base45: RFC 9285[10] (2022年发布)
• Base58: Bitcoin Wiki
• Base85: RFC 1924[11], Adobe PostScript

初学者路径

1. 先理解Base16 (最简单直观)
2. 再学Base64 (最常用)
3. 了解Base32 (2FA密钥)
4. 探索Base58 (理解非2^n编码)

实践项目

项目1: 实现Base64编码器
- 理解bit分组
- 掌握填充规则

项目2: 实现Base58编码器
- 理解大整数除法
- 对比与Base64的区别

项目3: QR码生成器
- 使用Base45优化存储
- 对比不同编码的QR码大小

常见误区

❌ 误区1: "Base64是加密"
✅ 正确: Base64是编码，不是加密，所以一般在CTF分类中纯Base的题目是Misc而不是Crypto
&nbsp; &nbsp;任何人都可以解码

❌ 误区2: "更大的Base就更好"
✅ 正确: 取决于场景
&nbsp; &nbsp;Base64通用性 > Base85压缩率

❌ 误区3: "Base58去掉了8个字符"
✅ 正确: 去掉了6个字符(0,O,I,l,+,/)
&nbsp; &nbsp;58 = 64 - 6

❌ 误区4: "Base编码能压缩数据"
✅ 正确: Base编码会膨胀数据
&nbsp; &nbsp;压缩需要用gzip/brotli等

🏆 总结

Base编码家族是数据表示的基础工具，理解它们的原理和应用场景，能帮助你：

1. ✅ 选择合适的编码方式
2. ✅ 理解数据传输机制
3. ✅ 优化存储和传输效率
4. ✅ 解决实际工程问题

记住核心原则：没有最好的编码，只有最适合的编码！ 🎯

Info

写这篇文章主要是因为做到一道CTF题目做破防了，所以我来好好的打好基础[12]。

Base家族在现代免杀木马中的应用

各种 Base 编码在恶意软件的免杀（AV evasion）中被广泛使用，与普通文件使用Base的目的是压缩不同的是，免杀木马使用Base的目的主要是混淆以隐藏真实的反连地址或恶意代码。

为什么用编码做免杀

杀毒软件的静态检测本质是模式匹配——扫描文件中的特征字节序列（签名）。编码后特征消失了：

原始 shellcode (会被杀软识别):
&nbsp; \xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00...

Base64 后 (签名消失):
&nbsp; /EiD5PDowAAAA...

Base85 后 (更短,更不像恶意代码):
&nbsp; @:X`hBk;1n...

常见编码混淆手法

单层编码最基础，现在基本没用了，杀软早就能自动解码检测：

# 最原始的方式, 现在秒杀
import&nbsp;base64
exec(base64.b64decode("cHJpbnQoJ2hlbGxvJyk="))

多层嵌套稍好一点：

payload → Base85 → XOR → Base64 → 反转字符串 → Base32

自定义字母表是 CTF 里常见的：

# 用自定义字母表的 Base64, 杀软的自动解码器认不出来
CUSTOM =&nbsp;"ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcba9876543210+/"

实际免杀中编码的角色

不过要说清楚，现代免杀中单纯靠编码基本没用了。编码只是多层混淆中的一环：

完整免杀链路:
&nbsp; shellcode
&nbsp; &nbsp; → 编码/加密 (Base85, AES, XOR, RC4...) &nbsp; &nbsp; ← 对抗静态签名
&nbsp; &nbsp; → 加载器 (反射DLL注入, syscall直调...) &nbsp; &nbsp; &nbsp; ← 对抗行为检测
&nbsp; &nbsp; → 反沙箱 (检测虚拟机, 延迟执行...) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ← 对抗动态分析
&nbsp; &nbsp; → 内存规避 (加密睡眠, unhook ntdll...) &nbsp; &nbsp; &nbsp; ← 对抗内存扫描

编码只能过最基础的静态扫描，稍微像样一点的 EDR 都会做运行时行为分析，光靠编码混淆远远不够。

🔔 想要获取更多网络安全与编程技术干货？

关注 泷羽Sec-静安 公众号，与你一起探索前沿技术，分享实用的学习资源与工具。我们专注于深入分析，拒绝浮躁，只做最实用的技术分享！💻

马上加入我们，共同成长！🌟

👉 长按或扫描二维码关注公众号

直接回复文章中的关键词，获取更多技术资料与书单推荐！📚

引用链接

[1] What is base64 Encoding and Why is it Necessary?: https://www.freecodecamp.org/news/what-is-base64-encoding/ [2] what-is-base64: https://base64.guru/learn/what-is-base64 [3] Base64: https://developer.mozilla.org/en-US/docs/Glossary/Base64 [4] 深入理解短链服务：原理、设计与实现全解析: https://zhuanlan.zhihu.com/p/1912646027770585297 [5] bit.ly: https://bitly.com/pages/home [6] TinyURL: https://tinyurl.com/ [7] 短网址: https://www.urlc.cn/ [8] What are Base96, Base128, Base256, and Base512? Do They Really Exist?: https://b64encode.com/blog/base-96-base128-base256-and-base512/ [9] RFC 4648: https://www.rfc-editor.org/info/rfc4648 [10] RFC 9285: https://www.rfc-editor.org/info/rfc9285 [11] RFC 1924: https://www.rfc-editor.org/info/rfc1924 [12] 打好基础: https://hgame.vidar.club/games/9/challenges?challenge=194

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：泷羽Sec-静安泷羽Sec静安泷羽Sec静安《Base编码家族完整解析》