Base64 转换

图片转 Base64 后体积会膨胀约 33%，因为每 3 字节二进制数据会被编码成 4 个 ASCII 字符。这对小图标（几 KB）影响不大，但一张 100KB 的 JPG 转完变成约 133KB 的字符串，直接嵌在 HTML/CSS 里会增加页面初始下载量。浏览器无法像普通图片文件那样做渐进式加载或单独缓存，每次访问都得重新下载这段字符串。建议只对 10KB 以下的小图标、装饰性元素用 Base64 内嵌，大图还是用文件链接更合理。

那不是乱码，是编码后的文本。要恢复，把整段文本复制出来，找一个支持「Base64 解码为文件」的工具（本工具也有这个功能），粘贴进去，点击解码，就能下载回原文件。关键点：编码时是什么格式（比如 PNG 图片），解码后保存时也要用相同扩展名。如果解码后打不开，检查一下复制时有没有漏掉开头的 data:image/png;base64, 前缀——有些工具只认纯编码内容，不带前缀。

等号是填充符。Base64 编码按 3 字节一组处理，如果原始数据长度不是 3 的倍数，最后一组会不足 3 字节，就用 = 或 == 补足到 4 个字符，这样解码器能知道最后一组实际有效数据是 1 还是 2 字节。去掉等号后，大多数标准解码器会报错或解码出错误数据。不过本工具提供了「URL-safe」选项，它会把 + 变 -、/ 变 _，并去掉末尾的 =，生成的是 RFC 4648 第 5 节定义的「base64url」格式，这种格式解码前需要手动补回等号，或者用支持无填充解码的库。

问题出在换行符和编码上。Windows 记事本保存的 .txt 默认是 GBK 编码，每行结尾是回车+换行（CR+LF，即 \r\n）；而 Linux/macOS 上常用 UTF-8 编码，换行只有 LF（\n）。Base64 是对原始二进制逐字节编码的，同一段文字用不同编码保存，二进制完全不同，Base64 结果自然不同。如果你想让结果跨平台一致，转码前先用 UTF-8 编码保存文本文件，或者在本工具里直接粘贴文本（不要上传文件），工具会按 UTF-8 处理文本内容。

Base64 是一种编码方案，不是加密算法。它只是把二进制数据转换成可打印的 ASCII 字符，方便在文本协议（如 HTTP、JSON）中传输。任何拿到编码字符串的人，用标准 Base64 解码器都能一秒还原出原始内容，不需要密钥。如果内容需要保密，应该用 AES、RSA 等加密算法先加密，再把加密后的二进制结果做 Base64 编码。简单说：Base64 防肉眼不防破解，别拿它当密码用。

这个前缀叫 Data URI scheme，告诉浏览器后面这段字符串是什么类型的数据。比如 data:image/png;base64, 表示后面是 PNG 格式图片的 Base64 编码；data:application/pdf;base64, 表示是 PDF 文件。浏览器遇到这个前缀，能直接解析并渲染出图片或提供文件下载，不需要发起网络请求。如果你只是想把编码存起来或传给后端，可以只取逗号后面的纯编码部分，节省存储空间。本工具结果区默认只展示纯编码，需要带前缀的可以手动拼接。

标准 Base64 编码字符集包含 + 和 /，这两个字符在 URL 中有特殊含义（+ 代表空格，/ 是路径分隔符）。如果把标准 Base64 字符串直接放在 URL 参数里（如 ?token=abc+def/ghi），服务器解析时会出错。URL-safe 模式把 + 替换成 -，把 / 替换成 _，并去掉末尾的 =，生成的字符串可以安全地放在 URL 的查询参数或路径中。如果你要把编码结果放在 GET 请求的参数里、或者作为 RESTful API 的路径段，一定要勾上；如果只是本地使用或放在 POST 请求体里，不需要勾。

常见原因有三个。第一：编码字符串里混入了换行符或空格。标准 Base64 不应该有换行，但有些工具或邮件系统会每 76 个字符自动换行，粘贴前要先把换行去掉。第二：字符串长度不是 4 的倍数。Base64 编码结果长度一定是 4 的倍数，如果复制时漏了字符或多了字符，解码器会报错。第三：包含了非法字符。标准 Base64 只包含 A-Z、a-z、0-9、+、/ 和末尾的 =，如果看到 . - _ 等字符，说明是 URL-safe 格式，要用对应的解码模式。本工具输入框会自动过滤常见干扰字符，如果还是报错，建议重新复制完整编码，检查首尾有没有多余内容。