速查在线工具箱Base64 与各类编码对照速查
Base64 不是加密、体积为什么会涨三分之一、URL 编码和 HTML 实体又各管什么——三种「编码」的区别一次说清。
Base64 常被误以为是一种加密方式，这是最需要先纠正的一点：它只是把二进制数据换成可打印字符的「搬运」手段，任何人都能立刻还原，没有任何保密能力。它真正解决的问题是——某些通道只允许传输文本。
同样容易被混在一起的是另外两种编码：URL 里看到的 %E4%B8%AD 是百分号编码，HTML 里看到的 & 是实体编码。它们和 Base64 的目标各不相同。这篇先讲 Base64 本身，再把三者放在一起对照。
1Base64 的基本规则
核心思想很简单：把每 3 个字节（24 位）切成 4 组 6 位，每组映射到一个可打印字符。因为 6 位能表示 64 种取值，所以叫 Base64。
| 要素 | 内容 | 说明 |
|---|---|---|
| 字母表 | A-Z + a-z + 0-9 + + + / | 共 64 个字符，顺序固定，不能自行调整 |
| 填充符 | = | 数据长度不是 3 的倍数时补齐，使输出长度恒为 4 的倍数 |
| 输出长度 | 输入字节数 × 4 ÷ 3 | 因为每 3 字节变 4 字符，所以体积约增加 33% |
| 是否可逆 | 完全可逆 | 编码与解码是确定的双向映射，不涉及密钥 |
| 是否加密 | **不是加密** | 任何人拿到编码结果都能直接还原，切勿用它保护敏感数据 |
体积膨胀是 Base64 的固有代价：100 KB 的文件编码后约 133 KB。所以在传输大文件时，直接传二进制（multipart 表单、原始请求体）比 Base64 更高效；Base64 更适合「必须嵌在文本里」的场景。
2变体：URL-safe、无填充
标准字母表里的 + 和 / 在 URL 中有特殊含义，直接放进地址会出问题。于是出现了几种变体，对接时务必确认对方用的是哪一种。
| 变体 | 与标准的差别 | 出现场景 |
|---|---|---|
| 标准 Base64 | 含 + / 与填充 = | 邮件附件、data URI |
| URL-safe Base64 | + 换成 -，/ 换成 _ | JWT、URL 参数、文件名 |
| 无填充变体 | 去掉末尾的 = | 部分 API 与库的默认行为，如 JWT |
| MIME Base64 | 每 76 个字符插入换行 | 邮件正文传输 |
| Base64url（严格） | URL-safe + 去填充 | RFC 4648 定义的 URL 与文件名安全形式 |
对接 JWT 或第三方 API 时，最常见的坑就是「用标准 Base64 去解一个 URL-safe 的结果」——遇到 `-` `_` 会直接失败。解析前先把这两个字符替换回 `+` `/` 再补上填充，是稳妥的做法。
3与其他进制的横向对比
Base64 不是唯一的选择。字母表越大，体积越接近原始数据，但可读性与容错性越差。
| 编码 | 字母表大小 | 体积膨胀 | 特点 |
|---|---|---|---|
| Base16 / Hex | 16（0-9A-F） | 约 +100% | 体积翻倍，但最易读，常见于哈希值与颜色值 |
| Base32 | 32（A-Z2-7） | 约 +60% | 不区分大小写，适合人工抄录与部分二次验证码 |
| Base64 | 64 | 约 +33% | 最常用的折中方案 |
| Base58 | 58（去掉了易混字符） | 约 +37% | 比特币地址使用，避免 0OIl 与 +/ 混淆 |
| Base85 / Ascii85 | 85 | 约 +25% | 体积更小，但字母表包含大量符号，可读性差 |
4三种「编码」别混：Base64 / 百分号 / HTML 实体
它们都叫「编码」，但目标、字母表、使用位置完全不同。选错的后果是数据被多解一次或少了关键转义。
| 编码 | 解决什么问题 | 典型样子 | 常见场景 |
|---|---|---|---|
| Base64 | 让二进制数据能走纯文本通道 | 5Lit5paH | data URI、JWT、邮件附件、图片内联 |
| 百分号编码 | 让任意字符能安全放进 URL | %E4%B8%AD%E6%96%87 | URL 参数、表单提交 |
| HTML 实体 | 让字符不被当成 HTML 标签解析 | &、' | 页面输出用户内容、防止 XSS |
| Unicode 转义 | 在源码里表示无法直接输入的字符 | \u4e2d | 编程语言字符串、JSON 内容 |
| 三者关系 | 互不替代 | 同一段文字经三种编码会得到三种完全不同的结果 | 选错编码是最常见的「看起来对、用起来错」 |
5HTML 实体的两种写法与安全意义
HTML 实体有具名与数字两种写法，效果等价。它在安全上的作用比在显示上更重要——这是防 XSS 的第一道处理。
- 具名实体
&（&）、<（<）、>（>）、"（"）、 （不换行空格）- 数字实体
- 十进制
'、十六进制'，都能表示单引号 - 为什么必须转义
- 用户输入里的
<>如果不转义，浏览器会把它们当作标签解析；把一段脚本注进评论区就能执行，这就是 XSS - 至少转义四个
&<>"，属性值里还要处理单引号。顺序上必须先转&，否则会把已经生成实体的&再转一次- 上下文的差别
- HTML 正文、属性值、URL、JavaScript 字符串里需要的转义规则各不相同，不能一套规则到处用
- 编码与转义不是加密
- 它们都完全可逆，只提供「表达」上的安全，不提供「保密」上的安全
6Base64 在真实系统里的四个出现位置
- data URI
- 把图片、字体直接嵌进 CSS 或 HTML，减少请求数。代价是体积增大且无法单独缓存，只适合小图标
- JWT
- 头部与载荷分别用 Base64url 编码后拼接，再附上签名。注意载荷只是编码、并未加密，任何人都能读出内容
- HTTP Basic 认证
- 把「用户名:密码」Base64 后放进
Authorization头。这只是编码，必须依赖 HTTPS 才有意义 - 接口传二进制
- 把文件转成字符串放进 JSON 字段。方便但有体积开销，大文件应改用 multipart 上传
看完就能用的站内工具
全部工具总览 →Base64编码 - Base64 加密与解密，支持文本和文件的编解码
Base64与文件互转工具，支持任意格式文件与Base64编码的相互转换，纯浏览器本地处理
Hex与Base64编码互转工具，支持文本和十六进制数据转换，纯浏览器本地处理
图片与Base64编码互转工具，支持图片转Base64和Base64转图片，纯浏览器本地处理，不上传服务器
URL编码 - URL 加密与解密，编码特殊字符，处理中文路径
HTML实体编码 - HTML特殊字符与实体编码互转，支持命名实体和数字编码
关于「Base64 与各类编码对照速查」的常见问题
Base64 是一种加密吗？
不是。Base64 只是编码，把二进制数据映射成可打印字符，任何人都能直接还原，不需要密钥，也不提供任何保密能力。它解决的问题是「某些通道只允许传文本」（例如邮件正文、URL 参数、JSON 字段）。真正的加密需要密钥，且不掌握密钥就无法还原。所以把敏感信息做一次 Base64 就当「已加密」处理，是相当危险的做法——必须配合 HTTPS 或使用真正的加密算法。
为什么 Base64 编码后文件变大了？
因为 Base64 把每 3 个字节（24 位）重新切成 4 组 6 位，每组用一个字符表示，所以每 3 字节变成 4 个字符，体积约增加三分之一（实际约 33%）。再加上不足 3 字节时要用 = 补齐，最终长度总是 4 的倍数。这是 Base64 的固有代价，无法通过压缩消除。所以大文件传输应优先使用二进制方式（multipart 上传、直接传请求体），Base64 只用在「必须嵌进文本通道」的场景。
标准 Base64 和 URL-safe Base64 有什么区别？
字母表有两个字符不同：标准版用 + 和 /，URL-safe 版换成 - 和 _，因为 + / 在 URL 里有特殊含义（前者在查询串中可能被解释成空格，后者是路径分隔符）。此外 JWT 等场景还会去掉末尾的 = 填充。两者不能用同一个解析器直接互解——拿到一段 Base64url 结果用标准解码器处理，遇到 - _ 就会失败。稳妥做法是先替换回 + /、补上填充再解码。
HTML 里 & 和 ' 有什么区别？
两者都是 HTML 实体，效果完全等价，只是写法不同：& 是具名实体，' 是十进制数字实体（' 是它的十六进制写法）。具名实体更好记、可读性更强；数字实体则不受实体名列表限制，任何字符都能表示。实际做转义时，最常用的五个是 &（&）、<（<）、>（>）、双引号（"）、单引号（'），顺序上必须先处理 &，否则会把其它实体里的 & 重复转义。
继续查：相关内容
全部速查 →内容说明：本页速查数据由本站自行整理，事实性内容以对应官方规范与文档为准，未复制第三方速查表或百科的表述。数据最后核对日期：2026-10-05。若发现错误或已更新的标准，欢迎通过页脚反馈入口告知。