Base64编码解码器 - 免费在线Base64转换工具
Base64编码解码器可以把任意文本转换为Base64编码字符串,也可以把Base64字符串还原为原始文本,全部计算在浏览器本地完成,不需要安装软件、注册账号或上传数据到服务器。工具能够正确处理包含中文、日文等Unicode字符以及表情符号的文本,适合程序员在调试接口数据、处理配置文件和传输二进制内容时快速转换。
Base64编码/解码器
转换文本到Base64编码和从Base64编码
文档
什么是 Base64 编码?
Base64 是一种将任何数据(包括图像等二进制数据)转换为纯文本的方法,生成的内容只包含字母、数字和少量符号。Base64 编码器将数据转换为这种文本形式。Base64 解码器再将其还原为原始数据。程序使用 Base64,让二进制数据能够安全地通过要求纯文本的系统传输,例如电子邮件或 JSON。
Base64 使用包含 64 个字符的字符集:
- 大写字母 A–Z(26 个字符)
- 小写字母 a–z(26 个字符)
- 数字 0–9(10 个字符)
- 两个符号,通常是
+和/(2 个字符)
有些系统还会在输出末尾使用等号 = 作为填充。填充不属于包含 64 个字符的字符集;它只是用来补足长度。
Base64 存在的原因
许多较早的文本协议,包括电子邮件(SMTP)和 HTTP 的某些部分,都是为传输 7 位 ASCII 文本而设计的。它们可能会损坏原始二进制字节,例如 JPEG 图像中的字节。Base64 通过仅使用安全且可打印的字符表示每个字节,避免了这一问题。因此,电子邮件附件、嵌入网页的图像以及 JSON 中的二进制字段通常都会先经过 Base64 处理。
Base64 既不是压缩,也不是加密。编码后的输出总是比输入更大,而且任何人都可以在没有密码或密钥的情况下对其解码。
如何使用此工具
- 在输入框中输入或粘贴文本。
- 选择“编码为 Base64”可将文本转换为 Base64,选择“从 Base64 解码”可将 Base64 字符串转换回文本。
- 开启实时转换后,输出会在输入过程中自动更新。
- 使用复制按钮复制结果。
该工具读取和写入标准 Unicode 文本,因此带重音符号的字母、符号和表情符号都能正确编码和解码,而不仅是普通的英文字母。
Base64 编码的工作原理
Base64 将输入的每 3 个字节(24 位)转换为 4 个输出字符(每个字符包含 6 位),因为 24 除以 6 等于 4。
- 将输入字节转换为二进制形式。
- 将各个位分成每组 24 位(3 个字节)。
- 将每个 24 位的分组拆分为四个 6 位的片段。
- 在 Base64 字符集中查找每个 6 位的数字(从 0 到 63),并写下对应的字符。
如果输入长度不是 3 的倍数,最后一组就会不足。编码器会用零位填充,然后在输出中添加 = 字符,使结果仍然以每组 4 个字符的形式出现:
- 剩余一个字节会生成 2 个 Base64 字符,外加
==。 - 剩余两个字节会生成 3 个 Base64 字符,外加一个
=。
Base64 编码示例
对单词“Hello”进行编码:
- ASCII 值:72、101、108、108、111
- 二进制:
01001000 01100101 01101100 01101100 01101111 - 前 3 个字节(24 位)分成四个 6 位的分组:
010010 000110 010101 101100,对应的数字为 18、6、21、44 → 字符S、G、V、s。 - 剩余的 2 个字节(16 位)分成三个 6 位的分组,并在末尾添加 2 个零位:
011011 000110 111100,对应的数字为 27、6、60 → 字符b、G、8。 - 由于剩余了 2 个字节,末尾会添加一个
=。 - 结果:
SGVsbG8=
解码会反向执行这些步骤:每个字符映射回其 6 位的数字,将这些位连接成比特流,再将该比特流按 8 位一个字节读出。
Base64 编码长度公式
对于包含 n 个字节的输入,编码后的字符长度为:
encoded_length = 4 × ⌈n / 3⌉
其中,⌈x⌉ 表示向上取整到最接近的整数。该公式说明了 Base64 输出为何总是比输入大约多三分之一:每 3 个输入字节对应 4 个输出字符,增加了 33%。
Base64 的应用场景
- 电子邮件附件(MIME)。 电子邮件是为文本设计的,因此文件附件会在发送前转换为 Base64,使附件文件比原始文件大约增加 33%。
- 数据 URI。 小型图像可以作为文本直接嵌入 HTML 或 CSS 中,例如
data:image/png;base64,iVBORw0KGgo...,从而避免单独请求文件。这种方式最适合小文件,因为大文件会使页面膨胀,而且无法单独缓存。 - API 和 JSON。 JSON 没有原生方式存放原始二进制数据,因此通过 JSON API 发送的二进制文件通常会先进行 Base64 编码。
- HTTP 基本身份验证。
Authorization标头会将用户名和密码编码为 Base64,例如Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=。这种方式本身并不安全;拦截凭据的任何人都可以读取它们,因此基本身份验证只能通过 HTTPS 使用。 - JSON Web 令牌(JWT)。 JWT 的三个部分分别使用 Base64URL 编码,这是一种适合放入 URL 的变体。
- 将二进制数据存储为文本。 只接受文本的数据库或配置文件有时会将二进制数据保存为 Base64 字符串。
Base64 与其他编码的比较
URL 安全的 Base64 将标准字符 + 和 / 替换为 - 和 _,因为 + 和 / 在 URL 中具有特殊含义。它用于 JWT、URL 查询参数和文件名。此工具生成标准 Base64 输出;转换为 URL 安全形式只需交换这两个字符。
Base32 使用包含 32 个字符的字符集,因此每个字符携带 5 位,而不是 6 位。它将每 5 个字节转换为 8 个字符,开销为 60%(8 ÷ 5 = 1.6),而 Base64 的开销为 33%。当输出必须手动输入或通过电话读取时,会选择 Base32,因为它避免使用大小写混合的字母以及容易混淆的字符。
十六进制使用 16 个字符(0–9、A–F),每个字节需要 2 个字符,使大小翻倍(开销为 100%)。它常用于显示哈希值、颜色和 MAC 地址,因为在这些场景中,可读性比紧凑的大小更重要。
不应使用 Base64 的情况
Base64 会增加数据大小和 CPU 开销,因此不适合通过网络发送大型文件;直接发送原始二进制数据更小、更快。Base64 绝不能用于隐藏密码或 API 密钥等敏感信息,因为无需任何秘密即可对其解码。存储大型文件时,数据库的二进制列类型或文件存储服务通常比在文本字段中保存很长的这种编码字符串更合适。
常见错误
- 跳过 UTF-8 转换。 对带重音符号的字母或表情符号文本进行编码时,如果不先将其转换为 UTF-8 字节,可能会损坏输出。
- 去除填充。 某些系统会删除末尾的
=字符。如果将字符串补回到 4 的倍数长度,大多数解码器仍可正常工作,但并非所有解码器都接受这种形式,因此保留填充更安全。 - 残留的换行符。 较早的基于 MIME 的编码器会每隔 76 个字符插入一个换行符;大多数现代解码器要求字符串连续,中间不能有换行符。
- 混淆不同变体。 标准 Base64 和 URL 安全的 Base64 对字符集中的同两个位置使用不同字符;使用错误的变体进行解码会产生乱码或错误。
常见问题
Base64 是加密形式吗? 不是。它是可逆的文本编码,而不是加密。任何人都可以在没有密码的情况下立即解码 Base64 字符串。如果数据需要保密,应使用 AES 等加密算法。
为什么 Base64 会使数据变大? 因为它使用一个完整字符来承载 6 位,而原始字节可容纳 8 位。将 3 个字节(24 位)转换为 4 个字符,意味着输出是输入的 4/3 倍,即比输入大约增加 33%。
Base64 可以编码图像和其他二进制文件吗? 可以。任何二进制文件,包括图像、PDF 和音频,都可以进行 Base64 编码,并逐字节解码还原。它通常用于嵌入 HTML 或 CSS 的小型图像,但不适合大型文件。
Base64 与 Base64URL 有什么区别?
Base64URL 将标准字符 + 和 / 替换为 - 和 _,因此无需额外转义即可安全地放入 URL 或文件名中。JWT 使用 Base64URL 正是出于这个原因。
为什么我的 Base64 字符串在解码时出现“无效”错误?
最常见的原因是字符串中包含不属于 Base64 字符集的字符,例如 URL 安全变体使用的 - 和 _,或者字符串长度比 4 的倍数多一。任何有效的 Base64 字符串都不会有这样的长度。如果解码后的字节不是有效的 UTF-8 文本,解码也会失败。该工具会忽略字符串中的空格和换行符,并且即使删除了末尾的 = 填充,仍然可以解码。
Base64 从何而来? 这种技术可以追溯到 1980 年代早期用于通过纯文本邮件系统发送二进制数据的方案,并于 1996 年作为 MIME 的一部分,在 RFC 2045 中正式标准化。Base64、Base32 和 Base16 当前的参考规范是 RFC 4648。