在 Web 开发中，我们经常需要处理各种数据格式的传输。Base64 就是其中一种绕不开的编码方式，它能将任意二进制数据转换成一串由 ASCII 字符组成的文本，从而确保数据在只能处理文本的通道中安全传输。
你很可能在项目里见过形如 data:image/png;base64,iVBORw0K... 的长字符串，这就是 Base64 的一个典型应用。本文将带你彻底搞懂 JavaScript 中 Base64 的编码与解码，覆盖浏览器和 Node.js 环境，并点明其中的关键要点和常见陷阱。
浏览器中的基础操作：btoa() 和 atob()
在浏览器环境中，全局作用域（window）提供了两个原生函数来处理 Base64：
btoa(): (binary to ASCII) 用于将字符串编码为 Base64。atob(): (ASCII to binary) 用于将 Base64 字符串解码回原始字符串。
这两个 API 使用起来非常直接。比如，我们想编码一条简单的信息：
const message = 'Hello World!';
// 编码
const encodedMessage = btoa(message);
console.log(encodedMessage); // 输出: SGVsbG8gV29ybGQh
// 解码
const decodedMessage = atob(encodedMessage);
console.log(decodedMessage); // 输出: Hello World!
看起来很简单，对吧？但这里隐藏着一个巨大的陷阱，也是无数新手踩过的坑。
Unicode 字符的噩梦
btoa() 和 atob() 的设计初衷是处理单字节的 Latin1 (ISO-8859-1) 字符集的字符串。如果你试图用它们处理包含多字节字符（如中文、emoji 等）的字符串，事情就会变得糟糕。
// 尝试编码一个包含中文字符的字符串
try {
btoa('你好，世界！');
} catch (e) {
console.error(e);
}
这段代码会立即抛出一个 DOMException 异常，提示 “The string to be encoded contains characters outside of the Latin1 range."。这是因为像“你”这样的字符无法用单个字节表示，btoa 不知道如何处理它。
现代浏览器的正确解法：TextEncoder 与 TextDecoder
为了正确处理 Unicode 字符串，我们需要一个中间步骤：先将 UTF-8 字符串转换为字节序列，然后再将这个字节序列进行 Base64 编码。现代浏览器为此提供了 TextEncoder 和 TextDecoder API。
下面是处理 Unicode 字符串的正确姿势：
// 编码函数：UTF-8 字符串 -> Base64
function utf8ToBase64(str) {
// 1. 将字符串转为 UTF-8 编码的字节 (Uint8Array)
const encoder = new TextEncoder();
const utf8Bytes = encoder.encode(str);
// 2. 将字节数组中的每个字节转为字符
// 注意：这里我们是在"欺骗" btoa，让它以为处理的是单字节字符序列
const binaryString = String.fromCharCode.apply(null, utf8Bytes);
// 3. 使用 btoa 进行编码
return btoa(binaryString);
}
// 解码函数：Base64 -> UTF-8 字符串
function base64ToUtf8(b64) {
// 1. 使用 atob 解码
const binaryString = atob(b64);
// 2. 将解码后的二进制字符串转回字节数组
const bytes = new Uint8Array(binaryString.length);
for (let i = 0; i < binaryString.length; i++) {
bytes[i] = binaryString.charCodeAt(i);
}
// 3. 使用 TextDecoder 将 UTF-8 字节解码为字符串
const decoder = new TextDecoder();
return decoder.decode(bytes);
}
// 测试一下
const unicodeString = '你好，世界! 😊';
const encoded = utf8ToBase64(unicodeString);
console.log('Encoded:', encoded); // Encoded: E+aOp+S4lueVjCEg8J+YgA==
const decoded = base64ToUtf8(encoded);
console.log('Decoded:', decoded); // Decoded: 你好，世界! 😊
这套方案才是处理现代 Web 应用中多语言文本的稳妥方法。
Node.js 中的标准实践：Buffer
在 Node.js 环境下，情况就完全不同了。请忘掉 btoa 和 atob。虽然较新版本的 Node.js 为了与 Web API 兼容而在全局引入了它们，但在 Node.js 中处理二进制数据和编码转换的标准、高效且唯一推荐的方式是使用内置的 Buffer 对象。
Buffer 天生就是为了处理二进制数据而设计的，它能轻松地在不同编码之间切换。
const originalString = '你好，世界! 😊';
// 编码: string -> Buffer -> base64 string
const buffer = Buffer.from(originalString, 'utf-8');
const encodedString = buffer.toString('base64');
console.log('Encoded:', encodedString); // Encoded: E+aOp+S4lueVjCEg8J+YgA==
// 解码: base64 string -> Buffer -> string
const decodedBuffer = Buffer.from(encodedString, 'base64');
const decodedString = decodedBuffer.toString('utf-8');
console.log('Decoded:', decodedString); // Decoded: 你好，世界! 😊
代码不仅简洁得多，而且性能也更好。在 Node.js 中进行 Base64 操作，Buffer 是你唯一的选择。
什么时候应该使用 Base64？
理解了如何实现，我们再来聊聊更重要的问题：什么时候用它？
-
Data URIs：这是最常见的场景，用于将小图片、图标或字体直接嵌入 HTML 或 CSS 中，从而减少 HTTP 请求。
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">注意：这只适用于非常小的资源。因为 Base64 会使数据体积增大约 33%，并且无法被浏览器独立缓存。
-
在文本格式中传输二进制数据：当你想在 JSON、XML 或其他纯文本格式中嵌入一个文件（比如用户头像）时，Base64 是标准做法。
{ "username": "coder", "avatar": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD..." } -
HTTP Basic Authentication：这是一种古老的认证机制，它将
username:password字符串通过 Base64 编码后放在Authorization请求头中。但请注意，Base64 不是加密，任何人都能解码，所以这种方式必须在 HTTPS 下使用。
必须警惕的陷阱与最佳实践
最后，谈谈几个关键的注意事项，避免滥用 Base64 导致问题。
-
Base64 不是加密！ 这是最大的误解，没有之一。Base64 是一种编码，其算法是公开的、可逆的。它不提供任何保密性。千万不要用它来“保护”密码、API Key 或任何敏感数据。需要保密请使用真正的加密算法，如 AES。
-
性能开销 Base64 编码会使数据体积增大约 33%。对于大文件（如高清图片、视频），这会带来巨大的带宽和存储浪费。此外，编码和解码过程也需要消耗 CPU 资源。对于大文件传输，永远优先选择
multipart/form-data这样的二进制传输方案。 -
缓存问题 如前所述，通过 Data URI 嵌入的资源会成为宿主文件（HTML/CSS）的一部分。这意味着它无法被浏览器单独缓存。如果 CSS 文件中只有一行代码变了，整个文件（包括所有内嵌的 Base64 资源）都得重新下载。
总结
总的来说，JavaScript 中的 Base64 操作根据环境有不同的最佳实践：
- 浏览器端：
btoa()和atob()是基础，但只能处理 Latin1 字符。对于包含 Unicode 的现代应用，必须配合TextEncoder和TextDecoder使用。 - Node.js 端：始终使用
Buffer。它功能强大、API 简洁，并且原生支持 UTF-8 和 Base64 之间的转换。
下次当你需要使用 Base64 时，花几秒钟想一想：这是不是最合适的场景？有没有更好的替代方案？确保你的应用跑的稳定又高效。
关于
关注我获取更多资讯
