1. Base64
原理：将每3字节（24位）的二进制数据拆分为4个6位的块，每个块映射到64个可打印字符（A-Z, a-z, 0-9, +, /）。
优势：
兼容性高：广泛支持于HTTP、电子邮件、JSON等协议。
编码效率：原始数据体积增加约33%（4/3）。
标准化：RFC 4648定义了标准格式。
缺点：
字符冲突：
+和/可能与URL或表单参数冲突（需额外处理）。
适用场景：通用场景（如图片嵌入HTML、API数据传输）。
2. Base32
原理：将每5字节（40位）拆分为8个5位的块，映射到32个字符（A-Z, 2-7）。
优势：
字符安全性：仅使用大小写字母和数字，避免特殊字符冲突（适合URL、文件名等）。
容错性：部分字符错误时仍可能恢复数据。
缺点：
编码效率低：原始数据体积增加约60%（8/5）。
可读性差：字符较少，难以直观识别。
适用场景：需要高安全性的场景（如加密密钥存储、URL编码）。
3. Base16（Hex）
原理：将每1字节（8位）拆分为2个4位的块，映射到16个字符（0-9, A-F）。
优势：
简单直观：易于手动调试和解析。
无冲突：字符集完全由数字和字母组成。
缺点：
效率最低：原始数据体积增加100%（2/1）。
冗余度高：占用更多存储空间。
适用场景：调试、日志记录、低级数据操作（如内存地址）。
4. Base85（ASCII85）
原理：将每4字节（32位）拆分为5个8位的块，映射到85个可打印字符（!-u）。
优势：
编码效率高：原始数据体积增加约25%（5/4），比Base64更紧凑。
无填充字符：无需补零（如Base64的
=）。
缺点：
兼容性差：部分系统可能不支持（如早期邮件协议）。
字符范围有限：需确保目标环境支持全部字符。
适用场景：需要高效编码的场景（如PDF、PostScript文件）。
5. URL安全的Base64
变体：将标准Base64中的
+和/替换为-和_，避免URL编码冲突。优势：
URL兼容性：直接用于URL参数、Cookie等。
标准化：RFC 4648定义了
Base64URL格式。
缺点：
需额外处理：需在传输前后进行转换。
适用场景：Web应用中的数据传输（如JWT令牌）。
6. Base91
原理：使用91个字符（A-Z, a-z, 0-9, !#$%&'()*+, -./:;<=>?@[]^_`{|}~），通过更复杂的分组逻辑提升效率。
优势：
效率更高：比Base64更紧凑（约25%的体积增加）。
灵活性：支持自定义字符集。
缺点：
兼容性差：非标准编码，需自定义实现。
复杂度高：解码逻辑较复杂。
适用场景：特定领域（如压缩数据嵌入文本）。
7. Quoted-Printable
原理：对非ASCII字符进行编码（如
=XX），保留大部分可读文本。优势：
可读性强：大部分文本保持原样，仅对特殊字符编码。
适合邮件：RFC 2047标准。
缺点：
效率低：对纯ASCII数据无压缩效果。
依赖上下文：需结合MIME协议使用。
适用场景：电子邮件内容编码（如非ASCII字符的邮件正文）。
总结对比表
选择建议
通用场景：优先选择 Base64（兼容性最佳）。
安全性要求高：使用 Base32 或 URL安全Base64。
效率优先：尝试 Base85 或 Base91（需验证兼容性）。
调试/低级操作：选择 Base16（简单直观）。
邮件/文本内容：使用 Quoted-Printable。
根据具体需求（如兼容性、效率、安全性）灵活选择即可。
评论区