一句话概括
图片的 Base64 编码是一种将图片的二进制数据转换成纯文本字符串的方法，这样你就可以将图片直接嵌入代码中，而不用链接到单独的文件。
它解决的问题
在互联网的早期，事情很简单：你有一个 HTML 文件，如果想要一张图片，就用一个 <img> 标签指向一个单独的图片文件，比如 logo.gif。浏览器会读取 HTML，看到这个标签，然后向服务器发起第二次请求来获取 logo.gif。一个页面，两次请求。
现在，想象一个现代网页。它可能有一个 logo、导航栏里有十几个小图标、页脚有社交媒体 logo，可能还有一个背景图案。如果这些都是独立的文件，那我们谈论的就不是两次请求了，而是 20、30 次甚至更多！每一次请求，不管文件多小，都有额外的开销。这就像派了 30 辆迷你送货车去同一个仓库，每辆车只取一个小包裹。效率低下，并且会拖慢页面对用户的显示速度。
这就是 Data URI 和 Base64 编码解决的核心问题：“请求太多”的问题。如果我们可以不告诉浏览器“去那边把图标取回来”，而是直接说“图标就在这里，就在这个 CSS 文件里”，那会怎么样？
通过将图片转换成文本并直接放入 HTML 或 CSS 中，你就可以将资源与文档本身捆绑在一起。这消除了为那些图片发起的额外网络请求，使得初始页面加载感觉上快得多，特别是对于那些小而关键的图形。这是一种权衡：你的初始 HTML/CSS 文件会变大，但你节省了许多小型网络请求来回往返的时间和开销。
它的底层原理
那么，你是如何把一张漂亮、复杂的图片变成一堆无聊的、看起来像是你家猫在键盘上踩出来的文本块呢？这个过程分两步：将图片理解为数据，然后应用 Base64 编码方案。
从像素到字节
首先，忘掉“图片”，想想“文件”。你电脑上的一张 PNG、JPEG 或 GIF 文件，并不是什么神奇的色彩集合。它是一个高度结构化的字节序列——一串 1 和 0。这些二进制数据包括了元数据（比如图片尺寸）、调色板以及压缩后的像素数据本身。
问题在于，你不能直接把这些二进制数据复制粘贴到像 HTML 或 CSS 这样的文本文件里。文本文件有自己的规则。某些字节值可能表示“新行”、“文件结束”，或者干脆就是无效的，会破坏代码。我们需要一种方法，只使用一套每个系统都认识的“安全”字符来表示图片的原始二进制数据。
Base64 的魔法戏法
这就是 Base64 编码大显身手的地方。它的工作就是用仅仅 64 个常见的、传输安全的 ASCII 字符来表示任何二进制数据。这个字符集就是 A-Z、a-z、0-9、+ 和 /。就这些。
这个过程是一通巧妙的二进制杂耍：
- 读取 3 个字节： 编码器一次读取 3 个字节的二进制图片数据。一个字节是 8 位，所以我们有 3 x 8 = 24 位。
- 分成 4 个块： 它把这 24 位的块重新划分为四个 6 位的块（4 x 6 = 24 位）。
- 映射到字符： 每个 6 位的块可以表示一个从 0 (000000) 到 63 (111111) 的数字。这个数字随后被用作索引，在 64 个字符的 Base64 字母表中查找对应的字符。
让我们用一个简单的文本例子来看看，因为原理是完全一样的。我们来编码 "cat" 这个词：
| 步骤 | 描述 | 数据 |
|---|---|---|
| 1. 原始 ASCII | 'c', 'a', 't' 的 ASCII 值。 | 99, 97, 116 |
| 2. 作为 3 字节 (24 位) | 每个字符的 8 位二进制表示。 | 01100011 01100001 01110100 |
| 3. 作为 4 x 6 位块 | 这 24 位被重新组合。 | 011000 110110 000101 110100 |
| 4. 十进制值 | 每个 6 位块的十进制值。 | 24, 54, 5, 52 |
| 5. Base64 字符 | 在 Base64 表中查找每个十进制值。 | Y, 2, F, 0 |
所以，文本 "cat" 变成了 Base64 字符串 "Y2F0"。
如果数据不是 3 字节的倍数怎么办？编码器会在末尾添加填充字符 (=)，以表示原始数据不能被完美整除。一个 = 表示最后一组只有两个字节；== 表示只有一个字节。
这个过程会使数据大小增加大约 33%，因为我们用了 4 个字符（4 字节）来表示原本是 3 字节的数据。
Data URI 包装器
好了，现在我们有了一个巨大的 Base64 文本字符串。浏览器不会自动知道它是一张 PNG 图片。我们必须使用 Data URI 来告诉它这是什么。
Data URI 有一个特定的格式：
data:[<MIME-type>][;base64],<data>
让我们来分解一个真实的例子，这是一个微小的红点 PNG 图片：
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==
data:: 协议名。它告诉浏览器“数据就在这里，而不是在某个其他 URL”。image/png: MIME 类型。这至关重要。它告诉浏览器“我给你的数据是一张 PNG 图片。请这样解码。”它也可以是image/jpeg、image/svg+xml等等。;base64: 一个可选的标志，表示数据是 Base64 编码的。,: 一个分隔符。iVBORw0K...: 实际经过 Base64 编码的图片数据。
当浏览器在 <img> 的 src 属性或 CSS 的 url() 函数中看到这个字符串时，它会把 Base64 字符串解码回原始的二进制字节并渲染出图片，所有这一切都不需要发起任何额外的网络请求。
真实世界案例
界面图标抖动的案例
一位前端开发者，我们叫她 Priya 吧，正在构建一个特别炫酷的新仪表盘。界面上充满了小巧而优雅的 SVG 图标：用于设置的齿轮，用于通知的铃铛，用于搜索的放大镜。在她办公室的高速 Wi-Fi 上，一切看起来都很完美。
但当她在模拟的 3G 网络上测试时，体验就变得非常糟糕。页面布局和文本会先加载出来，但会有一两秒钟的时间，本该是图标的地方都是空白。然后，图标们才一个接一个地弹出来。这让页面看起来既廉价又残破。
问题在于，这 15 个图标中的每一个都是她 CSS 文件里的一个独立的 background-image: url(...)，这触发了 15 次单独的 HTTP 请求。Priya 的解决方案是将每个微小的 SVG 转换成其 Base64 表示，并直接嵌入到 CSS 中。
经验教训： 对于像图标这样小而关键的 UI 元素，将它们作为 Base64 嵌入到你的 CSS 中可以消除阻塞渲染的网络请求，防止那种图片缺失的“闪烁”，从而创造出更流畅、更专业的用户体验。
独立完整的项目提案
Alex，一名顾问，需要给一位重量级客户发送一份项目提案。这份提案是一个 HTML 文档，里面有一些生成为 PNG 图片的图表和公司 logo。他不能只是发送一个文件夹，然后指望客户能正确地打开那个 HTML 文件。通过邮件发送附件也很笨拙，而且一些邮件客户端默认会屏蔽外部图片。
他需要一个单一的、万无一失的文件。他用一个脚本，拿到了最终的 HTML 和生成的图表图片，将每张图片进行 Base64 编码，然后把 <img src="chart1.png"> 这样的标签替换成 <img src="data:image/png;base64,...">。
结果是一个单一、体积稍大的 HTML 文件。他可以把这一个文件作为邮件附件发送，客户无论在线还是离线都能打开它，并且完美地看到包含所有图表和 logo 的提案，毫无障碍。
经验教训： Base64 是创建可移植、自包含文档的绝佳工具。当你需要将图片打包到一个“拿到就能用”的单一文件中时，比如在电子邮件或生成的报告中，它就是完美的解决方案。
常见错误和陷阱
- 对超大图片使用。 这是头等大罪。还记得那 33% 的体积增加吗？把一张 2 MB 的主图变成你 HTML 里一段 2.66 MB 的文本块，简直是性能噩梦。它会阻塞你的页面渲染，让你的文档大小激增，对用户来说，比正常加载图片要慢得多。只对小图片使用。
- 忽略缓存的弊端。 一个独立的图片文件（
logo.png）在第一次访问后会被浏览器缓存。如果这个 logo 出现在你网站的 100 个页面上，它只会被下载一次。但如果你把这个 logo 作为 Base64 嵌入到这 100 个 HTML 页面中的每一个，用户每次都必须重新下载那些（更大的）数据。 - 忘记完整的 Data URI 语法。 你不能直接把 Base64 字符串扔进
src属性里。你必须包含data:、MIME 类型（image/png,image/jpeg等）以及;base64,这个前缀。没有这个上下文，浏览器根本不知道拿这串乱码怎么办。 - 让你的 CSS 变得难以阅读。 一个嵌入了几十张图片的 CSS 文件，维护起来简直是噩梦。文件被成千上万个字符的字符串塞得满满当当，很难滚动和找到真正的样式规则。请慎重使用，如果你在用预处理器，可以考虑把 Base64 字符串放在一个单独的文件里（比如作为 Sass 变量）。
为什么它值得你关注
每当你处理一个小而关键、且需要立即显示的图形时，就应该考虑对它进行 Base64 编码。
- 首屏（above-the-fold）图标： 对初始用户体验至关重要的小 logo、搜索图标或菜单切换按钮。
- CSS 背景图案： 微小的、可重复的图案，为其发起一次额外的 HTTP 请求感觉有点小题大做。
- 自包含文档： 当你在生成一个需要独立存在、没有外部依赖的单一 HTML 文件时（例如电子邮件、报告、离线文档）。
- API 响应： 有时候，API 在一个 JSON 载荷中直接发送一张微小的缩略图，比强制客户端为它发起第二次请求更高效。
这是一个针对特定工作的特定工具：在文件大小和网络请求数量之间进行权衡并取胜。如果使用得当，它是一种强大的优化技术。
深入了解
- RFC 4648: The Base16, Base32, and Base64 Data Encodings - 定义 Base64 工作原理的 IETF 官方规范。不能再更极客、更权威了。
- RFC 2397: The "data" URL scheme - 关于
data:协议的规范，解释了其语法和基本原理。 - MDN Web Docs: Data URLs - 来自 Mozilla 的权威开发者指南，提供了清晰的示例和浏览器兼容性信息。
- Wikipedia: Base64 - 对 Base64 编码方案的历史、用例和设计的精彩概述。
- CSS-Tricks: When to Base64 Encode Images (and When Not To) - 一篇实用且经典的文章，讨论了在 Web 开发背景下使用 Base64 的利与弊。