数学上的 33% 字节膨胀惩罚
在 Web 开发中，您经常会在数据 URI 中遇到 Base64 编码的字符串（例如 data:image/png;base64,iVBORw0KGgo...）。这个承诺很诱人：将资源直接嵌入到 HTML 或 CSS 中以节省 HTTP 请求往返。
但是，Base64 带来了不可避免的物理字节损失:
- 原始二进制字节由 8 位 信息组成（$2^8 = 256$ 个可能值）。
- 文本协议（如电子邮件或早期 HTTP）无法在不破坏控制的情况下可靠地传输原始 8 位字节
- Base64 通过选择 64 个安全 ASCII 字符（A-Z、a-z、0-9、
+、/）解决了这个问题，其中每个字符代表 6位（$2^6 = 64$）。
要对 24 位二进制数据（3 个字节）进行编码，算法必须发出 4 个 ASCII 字符（24 位）。
$$\frac{4 \text{ 字符}}{3 \text{ 字节}} = 1.3333...$$
在计算传输标头之前，每个 Base64 资源都保证比源文件至少大 33.3%。
何时 Base64 数据 URI 真正有意义
尽管存在大小损失，但 Base64 内联在特定场景中在架构上是合理的：
- 关键首屏微图标：将 200 字节 SVG 徽标图标内嵌到关键 CSS 中可防止无样式图标 (FOIC) 的可见闪烁。
- 离线数据存储：将用户签名或画布导出作为文本字符串本地存储在
localStorage或IndexedDB中。相反，像 3D 网格这样的大文件应该保持二进制； STL转GCODE切片转换器 (STL to GCODE)直接读取原始二进制字节缓冲区以切片刀具路径，而不会产生文本解码损失（请参阅我们的关于在线将 STL 转换为 GCODE 的指南）。 - 通过电子邮件发送 HTML模板：许多企业桌面电子邮件客户端（例如 Outlook）默认情况下会阻止外部图像下载，但会渲染内联 Base64 图形。
当 Base64 内联破坏页面速度时
内联大于 2KB 到 5KB 的图像是现代网站上的反模式：
- 解析器阻止：浏览器的 HTML 和 CSS 解析器是单线程的。解码字符串时遇到 50KB Base64 字符串会停止 DOM 构建。
- 缓存失效：如果图像内联在主
index.html中，则修改段落中的单个拼写错误会迫使用户在下一个段落中重新下载整个嵌入图像访问。 - 内存开销：浏览器必须同时将原始解码位图和 Base64 字符串存储在内存中。
HTTP/2 和 HTTP/3：为什么多路复用改变了规则
在 HTTP/1.1 时代，浏览器被限制为每个域 6 个并发 TCP 连接。为了避免 TCP 连接握手延迟，内联图像是一种绝望的黑客行为。
现代网络标准（HTTP/2 和 HTTP/3）通过多路复用解决了这个问题：数百个静态资源通过单个 TCP/QUIC 连接同时流式传输，且零队头阻塞。 Base64 内联的历史动机实际上已经消失。
使用 ToolDolfen 的 Base64编解码工具在本地对您的资源进行编码、解码和基准测试。
