一、前言
在当今大模型（LLM）主导的AI时代，多模态交互已成为标配——从DALL·E生成图像到GPT-4o处理语音，海量的图片、音频、视频数据需要在前后端之间高效流转。然而，当大模型返回一个Base64编码的2MB图片时，你是否思考过：这种看似便捷的文本化传输，真的是最优解吗？
二、为何大模型普遍传输Base64格式的多模态数据
在我们分析这个问题之前，我们要数一数主流的多模态数据传输有哪几种形式——
- 1.Base64
- 2.二进制数据
- 3.URL
这里简单聊一聊为何二进制数据和URL并不适合大部分情况下的大模型数据传输
-
1.二进制数据
许多网络传输协议，如 HTTP，本质上是基于文本的，难以直接传输二进制数据。而Base64 编码可以将二进制数据转换为文本形式，使得大模型生成的图片、音频等二进制数据能够在这些协议中顺利传输。 -
2.URL
大模型在处理数据时，可能未将结果以文件形式存储在服务器上，因此没有对应的 URL。例如一些临时生成的图片、音频等数据，只是在内存中处理后直接返回，不存在服务器上的存储路径，无法提供 URL。
而Base64格式便可以规避掉上述的问题
三、前端应该直接使用大模型传输的Base64数据吗？
Base64格式的数据虽然在大模型的多模态数据传输中脱颖而出，但它并不是我们前端处理的最佳数据格式
1.相比于二进制数据，它体积更大
- Base64 是将二进制数据转换为 ASCII 字符的编码方式，每 3 字节二进制数据会被编码为 4 字节的 Base64 字符串（理论上体积增加约 33%）。 一张 10KB 的 PNG 图片转换为 Base64 后，大小可能接近 14KB。
2.相对于URL，性能太差
- URL 指向的资源可被浏览器缓存（通过
Cache-Control等头字段），下次访问直接从本地读取。Base64 数据嵌入在 HTML 或 JS 中，属于文档内容的一部分，无法单独缓存，导致重复加载。
种种原因表明，我们应该对大模型传输的Base64数据进行处理之后再使用
四、前端对Base64格式数据的处理方案——Blob+URL
使用字节tts时返回的音频文件便是Base64格式数据，我们可以对其进行以下的处理
const getAudioUrl = (base64Data) => {
// 创建一个数组来存储字节数据
var byteArrays = [];
// 使用atob()将Base64编码的字符串解码为原始二进制字符串
// atob: ASCII to Binary
var byteCharacters = atob(base64Data);
// 遍历解码后的二进制字符串的每个字符
for (var offset = 0; offset < byteCharacters.length; offset++) {
// 将每个字符转换为其ASCII码值（0-255之间的数字）
var byteArray = byteCharacters.charCodeAt(offset);
// 将ASCII码值添加到字节数组中
byteArrays.push(byteArray);
}
// 创建一个Blob对象
// new Uint8Array(byteArrays)将普通数组转换为8位无符号整数数组
// { type: 'audio/mp3' } 指定Blob的MIME类型为MP3音频
var blob = new Blob([new Uint8Array(byteArrays)], { type: 'audio/mp3' });
// 使用URL.createObjectURL创建一个临时的URL
// 这个URL可以用于<audio>标签的src属性
// 这个URL在当前页面/会话有效，页面关闭后会自动释放
// 创建一个临时 URL 供音频播放
return URL.createObjectURL(blob);
}
这个操作可以将Base64的大小还原为相应的二进制数据的大小，而且兼具了URL的可重复使用等优势，可谓一举两得。
五、结语
在大模型驱动的多模态交互时代，Base64 如同连接前后端的 “数字桥梁”，以文本化特性解决了二进制数据的传输困境，却也因体积膨胀、缓存受限等问题埋下性能隐患。前端通过Blob+URL的转换方案，既保留了 Base64 的跨平台兼容性，又借由二进制数据的原生操作和 URL 的资源复用能力，在 “传输便捷性” 与 “性能优化” 间找到了平衡。
