Base64 编码解码

免费在线 Base64 编码解码 工具。100% 本地计算，数据不离开您的设备，隐私安全有保障。

输出

结果将显示在这里...

输入 → 编码

使用指南

关于 Base64

Base64 是一种基于 64 个可打印字符来表示二进制数据的编码方法，广泛应用于需要在文本协议中传输二进制数据的场景。Base64 使用 A-Z、a-z、0-9、+、/ 共 64 个字符，以及 = 作为填充字符。它将每 3 个字节（24 位）的二进制数据编码为 4 个 Base64 字符，编码后的数据大小约为原始数据的 133%。Base64 不是加密算法，而是编码方式，任何人都可以解码。

Web 开发必备：Base64 是 Web 开发中最常用的编码方式，用于在 HTML、CSS、JavaScript 中嵌入图片、字体等二进制数据，也是 HTTP Basic 认证、JWT（JSON Web Token）、邮件附件（MIME）等协议的基础。推荐作为二进制数据编码的首选。

使用步骤

Base64 编码和解码非常简单：

•
1. 编码输入文本或上传文件，点击「编码」按钮，获得 Base64 编码字符串
•
2. 解码输入 Base64 编码字符串，点击「解码」按钮，恢复原始数据
•
3. 复制结果点击「复制」按钮获取编码或解码后的结果
隐私保护：所有计算在浏览器本地高速完成，数据不会上传服务器，完全离线处理。

编码原理

Base64 编码将二进制数据转换为 ASCII 字符的过程：

•
1. 分组将二进制数据每 3 个字节（24 位）分为一组
•
2. 拆分将 24 位拆分为 4 组，每组 6 位
•
3. 映射将每组 6 位（0-63）映射到 Base64 字符表（A-Z, a-z, 0-9, +, /）
•
4. 填充如果最后一组不足 3 字节，用 = 填充至 4 个字符
注意：Base64 不是加密算法，编码后的数据可以被任何人轻松解码。如果需要保护数据机密性，应使用加密算法（如 AES）加密后再进行 Base64 编码。

Base64 变体

Base64 有几种常见的变体，用于不同的场景：

•
标准 Base64使用 +、/ 字符，适用于大多数场景
•
URL 安全 Base64使用 -、_ 替代 +、/，避免 URL 中的特殊字符问题
•
无填充 Base64省略末尾的 = 填充字符，减少数据长度
•
MIME Base64每 76 个字符插入换行符，用于邮件传输

应用场景

Base64 广泛应用于需要在文本协议中传输二进制数据的场景：

•
Data URL在 HTML、CSS 中嵌入图片、字体等资源（data:image/png;base64,...）
•
HTTP 认证HTTP Basic Authentication 使用 Base64 编码用户名和密码
•
JWTJSON Web Token 使用 Base64 编码 Header 和 Payload
•
邮件附件MIME 协议使用 Base64 编码邮件附件
•
API 传输在 JSON、XML 等文本格式中传输二进制数据
•
配置文件在配置文件中存储二进制数据（如证书、密钥）

常见问题

Q: Base64 编码后数据会变大吗？

A: 是的，Base64 编码会使数据大小增加约 33%。原因：Base64 将每 3 个字节（24 位）编码为 4 个字符（32 位），增加了 8 位。例如，100KB 的文件编码后约为 133KB。影响：1）增加网络传输时间。2）增加存储空间。3）增加 CPU 编码/解码开销。优化：1）对于大文件，考虑先压缩（如 gzip）再编码。2）使用 URL 安全 Base64 并省略填充可以略微减少大小。3）对于 Web 资源，考虑直接使用二进制传输（如 Blob URL）而非 Data URL。

Q: Base64 和加密有什么区别？

A: Base64 是编码，不是加密，两者有本质区别。Base64 编码：1）目的：将二进制数据转换为文本格式，便于传输。2）可逆性：任何人都可以解码，无需密钥。3）安全性：无安全性，不能保护数据机密性。加密：1）目的：保护数据机密性，防止未授权访问。2）可逆性：需要密钥才能解密。3）安全性：提供数据保护。正确做法：如果需要保护数据，先用 AES 等算法加密，再用 Base64 编码传输。

Q: 为什么 Base64 字符串末尾有 = 号？

A: = 是 Base64 的填充字符，用于补齐编码长度。原因：Base64 将每 3 个字节编码为 4 个字符。如果原始数据长度不是 3 的倍数，最后一组会不足 3 字节，需要用 = 填充。规则：1）剩余 1 字节：编码为 2 个字符 + 2 个 =。2）剩余 2 字节：编码为 3 个字符 + 1 个 =。3）正好 3 字节：无需填充。示例：“A” → “QQ==”，“AB” → “QUI=”，“ABC” → “QUJD”。URL 安全：在 URL 中，= 可能被省略（URL 安全 Base64），解码时会自动补齐。

Q: Base64 和 Hex 编码有什么区别？

A: Base64 和 Hex 都是二进制数据的文本表示方式，但有不同的特点。Base64：1）使用 64 个字符（A-Z, a-z, 0-9, +, /）。2）编码后大小约为原始数据的 133%。3）更紧凑，适合传输。Hex（十六进制）：1）使用 16 个字符（0-9, A-F）。2）编码后大小为原始数据的 200%。3）更易读，适合调试。选择建议：1）需要紧凑传输：使用 Base64。2）需要可读性和调试：使用 Hex。3）加密算法输出：通常使用 Hex（如 SHA-256）。

Q: Data URL 是什么？如何使用？

A: Data URL 是一种在 URL 中直接嵌入数据的方式，使用 Base64 编码。格式：data:[媒体类型];base64,[Base64数据]。示例：data:image/png;base64,iVBORw0KGgoAAAANS...。优点：1）减少 HTTP 请求，提升页面加载速度。2）无需额外文件，便于分享和嵌入。缺点：1）增加 HTML/CSS 文件大小。2）无法利用浏览器缓存。3）不适合大文件。使用场景：1）小图标、Logo（< 10KB）。2）内联 SVG 图片。3）字体文件（小字体）。4）CSS 背景图片。最佳实践：仅对小于 10KB 的资源使用 Data URL，大文件应使用独立文件并利用 CDN 和缓存。

Q: 如何在 JavaScript 中使用 Base64？

A: JavaScript 提供了内置的 Base64 编码和解码方法。编码：btoa(string) - 将字符串编码为 Base64。解码：atob(base64String) - 将 Base64 解码为字符串。注意：btoa 和 atob 只支持 ASCII 字符。对于 UTF-8 字符串，需要先转换：
// 编码 UTF-8 const base64 = btoa(unescape(encodeURIComponent('中文'))); // 解码 UTF-8 const text = decodeURIComponent(escape(atob(base64)));
现代方法：使用 TextEncoder 和 TextDecoder API 处理 UTF-8。文件编码：使用 FileReader.readAsDataURL() 将文件编码为 Data URL。

使用场景

推荐：Data URL 嵌入小图片

在 HTML、CSS 中使用 Data URL 嵌入小图片（如图标、Logo）可以减少 HTTP 请求，提升页面加载速度。推荐对小于 10KB 的图片使用 Data URL，大图片应使用独立文件并利用 CDN 和浏览器缓存。Data URL 特别适合内联 SVG 图片，因为 SVG 是文本格式，Base64 编码后仍然可读。

推荐配置：
  • ✅ 小图标、Logo（< 10KB）
  • ✅ 内联 SVG 图片
  • ✅ CSS 背景图片（小图）
  • ❌ 避免大图片（> 50KB）
  • 💡 使用构建工具（如 Webpack）自动转换
推荐：JWT（JSON Web Token）

JWT 使用 Base64 编码 Header 和 Payload，用于在客户端和服务端之间安全地传输信息。JWT 由三部分组成：Header（头部）、Payload（载荷）、Signature（签名），使用 . 分隔。Header 和 Payload 使用 Base64 编码，Signature 使用 HMAC-SHA256 或 RSA 签名。

推荐配置：
  • ✅ 用户认证和授权
  • ✅ 单点登录（SSO）
  • ✅ API 访问令牌
  • ❌ 不要在 JWT 中存储敏感信息（Base64 可解码）
  • 💡 使用 HTTPS 传输 JWT
推荐：HTTP Basic Authentication

HTTP Basic Authentication 使用 Base64 编码用户名和密码，格式为 Authorization: Basic [Base64(username:password)]。虽然 Base64 编码不提供安全性，但配合 HTTPS 使用可以保护凭证在传输过程中的安全。HTTP Basic Authentication 简单易用，适合内部系统或需要快速实现认证的场景。

推荐配置：
  • ✅ 内部系统、管理后台
  • ✅ API 认证（配合 HTTPS）
  • ✅ 简单的用户认证
  • ❌ 必须使用 HTTPS，避免明文传输
  • 💡 考虑使用更安全的 OAuth 2.0 或 JWT
推荐：邮件附件（MIME）

MIME（Multipurpose Internet Mail Extensions）协议使用 Base64 编码邮件附件，将二进制文件转换为文本格式，便于在邮件系统中传输。MIME Base64 每 76 个字符插入换行符（CRLF），符合邮件协议的行长度限制。现代邮件客户端会自动处理 Base64 编码和解码，用户无需手动操作。

推荐配置：
  • ✅ 邮件附件编码
  • ✅ 邮件正文中嵌入图片
  • ✅ 符合 RFC 2045 标准
  • 💡 使用邮件库（如 Nodemailer）自动处理
推荐：API 传输二进制数据

在 JSON、XML 等文本格式的 API 中传输二进制数据（如图片、文件）时，可以使用 Base64 编码。这样可以避免处理 multipart/form-data 等复杂的二进制传输格式。但对于大文件，推荐使用专门的文件上传 API（如 multipart/form-data 或直接上传到对象存储）以提高性能。

推荐配置：
  • ✅ 小文件传输（< 1MB）
  • ✅ JSON API 中嵌入二进制数据
  • ✅ 配置文件中存储证书、密钥
  • ❌ 避免传输大文件（> 10MB）
  • 💡 大文件使用 multipart/form-data 或对象存储
推荐：配置文件存储二进制数据

在配置文件（如 JSON、YAML、XML）中存储二进制数据（如 SSL 证书、密钥、小图片）时，可以使用 Base64 编码。这样可以避免处理外部文件路径和文件读取问题，使配置文件自包含。特别适合 Docker 镜像、Kubernetes ConfigMap 等需要将配置打包的场景。

推荐配置：
  • ✅ SSL 证书、私钥
  • ✅ API 密钥、令牌
  • ✅ 小图片、图标
  • ✅ Docker、Kubernetes 配置
  • 💡 注意保护包含敏感信息的配置文件

最佳实践建议

  • Base64 是编码而非加密，不能保护数据机密性。需要保护数据时，先加密再编码。
  • Base64 编码会使数据大小增加约 33%，对于大文件应考虑先压缩再编码。
  • Data URL 适合小于 10KB 的资源，大文件应使用独立文件并利用 CDN 和缓存。
  • HTTP Basic Authentication 必须配合 HTTPS 使用，避免凭证在传输过程中被窃取。
  • JWT 的 Payload 使用 Base64 编码，任何人都可以解码，不要存储敏感信息。
  • 对于 UTF-8 字符串，使用 TextEncoder/TextDecoder 或 encodeURIComponent/decodeURIComponent 处理。

讨论与反馈

0 条评论
我