Base64 编码解码工具
在线 Base64 加密解密工具，支持文本与 Base64 互转。基于标准 Web API 实现 UTF-8 安全编解码，中文无乱码。浏览器本地处理，数据不上传服务器。
描述：
什么是 Base64 编码？
Base64 是一种基于 64 个可打印字符来表示二进制数据的编码方式。它广泛用于电子邮件附件（MIME）、网页中嵌入图片（Data URI）、API 数据传输、JSON Web Token (JWT) 等场景。Base64 将每 3 个字节编码为 4 个字符，编码后数据大小约为原始数据的 133%。
本工具使用浏览器内置的 TextEncoder 和 TextDecoder API 实现 UTF-8 安全编解码，确保中文、日文、韩文等非 ASCII 字符在编码和解码过程中不会出现乱码问题。
Base64 编解码的常见场景
- 数据 URI 嵌入图片 — 将图片转换为 Base64 嵌入 HTML/CSS，减少 HTTP 请求
- API 数据传输 — 在 JSON 中安全传输二进制数据
- JWT Token 解析 — 解码 JWT 的 Payload 部分查看内容
- 配置文件加密 — 简单混淆配置中的敏感信息（注意：不是真正的加密）
- 邮件附件 — MIME 协议使用 Base64 编码邮件附件
注意事项
Base64 编码不是加密算法，它只是一种数据表示方式。任何人都可以轻松解码 Base64 数据，因此不要把 Base64 当作密码保护手段。如果你需要保护数据安全，请使用 AES、RSA 等标准加密算法。
为什么中文编码后是一串"乱码"？
很多人第一次用 Base64 处理中文时，会看到一串完全不认识的字符，比如把"你好"编码成更长的文本。这其实是正常的。因为 Base64 操作的对象是"字节"，而中文这类非 ASCII 字符在计算机里以 UTF-8 等多字节编码存储。工具先把中文转成对应的字节序列，再把这些字节按 Base64 规则映射成可打印字符，所以结果看起来像"天书"，但解码后又能还原成原来的中文。
这就是为什么"UTF-8 安全"很重要——如果工具没按 UTF-8 处理，而是按单字节去转，中文编出来的结果再用标准解码器解，就会出现乱码。本工具使用浏览器标准的 TextEncoder/TextDecoder，能正确处理中文、日文、韩文、Emoji 等，避免这类乱码问题。
Base64 为什么体积会变大？
因为 Base64 把每 3 个字节（24 位）重新拆成 4 个 6 位单元，每个单元对应一个可打印字符。3 字节变成 4 字符，等于在总长度上多出了约 1/3，所以编码后的数据大约增大到原来的 133%（常用说法是 1.37 倍）。这也是为什么大文件一般不适合整体转成 Base64——体积膨胀明显，且要额外消耗处理时间。对小数据、配置片段、图片缩略图这类场景，这个膨胀是可以接受的。
结果怎么用？
编码得到的 Base64 字符串可以直接用于 Data URI 嵌入图片、API 传参、JWT Payload 查看，或作为配置的简单文本表示；解码则能把 Base64 还原成可读文本，用于查看 JWT 内容、解析接口返回或调试。若你还需要处理 URL 参数或 JSON，可配合「URL 编解码」「JSON 格式化」一起使用。
先厘清一个常见误解：Base64 是编码，不是加密
Base64 的准确称谓是「Base64 编码」（Binary-to-Text Encoding），它的唯一职责是把任意二进制数据翻译成由 64 个可打印字符组成的文本。很多人第一次接触这个工具时，会把它与「加密」混为一谈，甚至误以为它能保护密码——这是一个需要首先纠正的危险误解。编码解决的是「传输与存储兼容性」问题：电子邮件、JSON、URL、HTML 等环境对允许出现的字符有严格限制，二进制字节（例如图片、压缩包、非 ASCII 文字）如果直接放进去，常常会被网关、解析器或编辑器破坏。于是人们先用 Base64 把这些字节变成纯文本，到达目的地后再原样还原。整个过程没有任何密钥，也不提供任何保密性；任何拿到 Base64 字符串的人，都能在瞬间把它还原成原始内容。如果你真正需要的是「让别人看不懂」，那应该去用 AES、RSA 这类加密算法，而不是 Base64。
另一个容易忽略的事实是：Base64 操作的最小单位从来不是「字符」或「字母」，而是「字节（byte）」。对于纯英文 ASCII 文本，一个字母恰好占用一个字节，所以编码结果看起来像是逐字替换；但一旦涉及中文、emoji、日语等非 ASCII 字符，情况就完全不同了——这些字符在计算机内部以 UTF-8 等多字节编码存储，一个常用汉字通常占用 3 个字节，一个 emoji 可能占用 4 个字节。Base64 会先把整段文本按照 UTF-8 规则转换为字节序列，再对这些字节做编码。这就是为什么「你好」编码后会变成一长串看似无关的字符：工具编码的是这三个汉字背后对应的 6 个 UTF-8 字节，而不是「你」和「好」这两个字形本身。
Base64 字母表：64 个可打印字符与它们的索引
下面这张表是 Base64 的核心。任何一个被编码的字节，最终都要映射到这 64 个字符之一。索引从 0 开始连续编号，编码时本质上就是把二进制数据按每 6 位一组重新编号，再用编号去查表换成对应字符。
| 字符组 | 索引区间 | 具体字符与对应关系 |
|---|---|---|
| 大写字母 A 到 Z | 0 – 25 | A=0、B=1、C=2 …… 一直到 Z=25 |
| 小写字母 a 到 z | 26 – 51 | a=26、b=27、c=28 …… 一直到 z=51 |
| 数字 0 到 9 | 52 – 61 | 0=52、1=53、2=54 …… 一直到 9=61 |
| 加号 + | 62 | 索引 62 对应的字符 |
| 斜杠 / | 63 | 索引 63 对应的字符（字母表最后一个） |
怎么读这张表：有两个细节值得记住。第一，大写 A 的索引是 0 而不是 1，这意味着 Base64 本质上是一种「以 6 比特为单位的重新编号」；第二，标准 Base64 的最后两个字符是 + 和 /，它们虽然是可打印字符，却在某些运行环境里并不「安全」，这正是后文 URL-safe 变体要专门解决的问题。
填充规则：为什么末尾会出现等号
Base64 每次固定处理 3 个字节（共 24 位），正好可以拆成 4 个 6 位单元、得到 4 个字符。但原始数据的长度往往不是 3 的整数倍，尾部凑不齐一组时，就需要用等号 = 来占位：
| 原始字节数 | 编码后字符数 | 填充等号 | 说明 |
|---|---|---|---|
| 3 字节（正好一组） | 4 个字符 | 无 | 24 位完整，无需填充 |
| 2 字节 | 3 个字符 + 1 个 = | 补 1 个 = | 只差 1 字节凑满 3 字节，补 1 个等号 |
| 1 字节 | 2 个字符 + 2 个 = | 补 2 个 = | 只差 2 字节凑满 3 字节，补 2 个等号 |
怎么理解等号：等号 = 本身不属于那 64 个字符，它只是一个占位符，用来告诉解码器「这一组不完整，最后少了几字节」。关键在于，填充等号纯粹是格式需要，它不包含任何实际信息；去掉或加错等号不会改变真实数据，只会让解码器报错或丢弃尾部。这也是为什么同一个内容在不同工具里有时带等号、有时不带——只要双方约定好是否保留填充，编码结果是等价的。
URL-safe 变体：把 + 和 / 换成 - 和 _
标准 Base64 里的 + 和 / 在 URL 与文件名中具有特殊含义（+ 常被当成空格处理，/ 是路径分隔符），直接塞进链接里会被错误解析。RFC 4648 第 5 节定义的 URL-safe Base64 把这两个字符替换掉：
| 标准 Base64 | URL-safe Base64 | 替换原因 |
|---|---|---|
| + | - | + 在 URL 查询与表单中可能被解释为空格，必须替换 |
| / | _ | / 是 URL 路径分隔符，会破坏路径结构，必须替换 |
| =（填充） | 通常省略 | = 在查询参数中也可能引起歧义，URL-safe 场景常直接去掉 |
怎么选：URL-safe 与标准 Base64 仅仅是字符层面的替换，编码出的信息完全等价，互相转换不会改变解码结果。如果你要把 Base64 放进链接、Cookie 或文件名，务必使用 URL-safe 变体；如果只是嵌入 JSON 字段或 Data URI，用标准版即可。需要强调，替换字符不等于加密，任何人都能把 - 和 _ 换回 + 和 / 后正常解码。
真实算例：从明文一步步算出 Base64
算例 1：英文单词 Man。它包含三个字节：M=77、a=97、n=110。先写成二进制：M=01001101，a=01100001，n=01101110；按顺序拼接成 24 位：01001101 01100001 01101110。再把它按每 6 位切开，得到四组：010011=19 映射为 T，010110=22 映射为 W，000101=5 映射为 F，101110=46 映射为 u。于是 Man 编码为 TWFu。因为正好 3 个字节，整除无余数，末尾没有等号。你可以用本工具输入 Man 验证，结果应当完全一致。
算例 2：英文单词 Hello。它包含五个字节：H=72、e=101、l=108、l=108、o=111，共 40 位。按 6 位分组后，前 36 位得到 S、G、V、s、b、G，剩下 4 位 1111 不足一组，补两个 0 凑成 111100=60 映射为 字符 8，由于最后只差 1 个字节（5 除以 3 余 2），末尾补 1 个等号。最终 Hello 编码为 SGVsbG8=。同样可以输入 Hello 到本工具核对。
常见问题（Base64 专属）
为什么编码结果末尾会出现等号（=）？因为 Base64 每次处理 3 个字节，凑成 4 个字符；当原始数据长度不是 3 的整数倍时，尾部不足的字节就用等号占位。缺 1 个字节补 1 个等号，缺 2 个字节补 2 个等号。等号只是格式占位符，不含数据，但解码时通常需要保留它才能正确还原字节长度。
URL-safe Base64 和标准 Base64 有什么区别，应该在什么场景下使用？标准版用 + 和 / 作为最后两个字符，但这两个字符在 URL、文件名与查询参数中有特殊含义，直接放入会被错误解析。URL-safe 变体把 + 换成 -、/ 换成 _，并通常省略末尾等号。需要把编码结果放进链接、Cookie 或文件名时，应使用 URL-safe 变体；嵌入 JSON 或 Data URI 时用标准版即可。
Base64 是加密算法吗，能不能用来保护密码或敏感数据？不是。Base64 只是一种编码，没有任何密钥与保密性，任何人拿到字符串都能瞬间还原原文。它不能替代加密。真正需要保密时，应使用 AES、RSA 等标准加密算法，而不是用 Base64 做混淆。把密码只做 Base64 处理就存储或传输，等于明文暴露。
中文等非 ASCII 字符在 Base64 里是按什么规则编码的？Base64 操作的最小单位是字节而非字形。中文、emoji 等非 ASCII 字符会先按 UTF-8 规则转换成字节序列（一个常用汉字通常占 3 字节，一个 emoji 可能占 4 字节），再对这些字节做 6 位分组编码。因此「你好」编码后变长，是因为工具编码的是其背后的 6 个 UTF-8 字节，而非「你」「好」两个字形。使用 UTF-8 安全的编解码（如浏览器标准的 TextEncoder、TextDecoder）能确保中文编码解码后完整无损、不会出现乱码。
如果你还需要处理 URL 参数里的特殊字符，可以配合 URL 编解码 工具一起使用；清理从网页或聊天记录里复制来的隐藏空白与零宽字符，可以先用 文本清理；而从 HTML 源码里抽取纯文本，则可参考 HTML 标签清除。