我应该在将文件发送到后端之前还是之后将文件转换为 Base64？

Question

首先，我知道在数据库中保存 Base64 字符串并不是保存图像的最有效方法，但我没有很多图像并且很少加载它们，所以这应该不是问题。

所以让我们开始吧，我有一个 SQL 数据库，其中有一个表“图片”，它有两列，一个唯一的名称和一个代表 base 64 文件的字符串：

@Entity
public class Picture {

  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  private long id;

  @Column(unique = true)
  private String name;
  private String imageInBase64;
}

用户可以在用户界面中 select 图像，然后通过 REST 发送到后端。 我的问题是，我应该在将文件/图片发送到后端之前将其编码为 Base64 还是应该在收到后在后端对其进行编码？ 目前我只是在前端对其进行编码并发送一个 JSON 代表图片 class。

Answer 1

这是来自这篇文章...https://stackoverflow.com/questions/9722603/storing-image-in-database-directly-or-as-base64-data

我认为图像（文件）通常不会存储在 base64 编码的数据库中。 相反，它们以原始二进制形式存储在二进制（blob）列（或文件）中。

Base64 仅用作传输机制，不用于存储。 例如，您可以将 base64 编码图像嵌入到 XML 文档或 email 消息中。

Base64 也是 stream 友好的。 您可以即时编码和解码（不知道数据的总大小）。

虽然 base64 适合传输，但不要存储 base64 编码的图像。

Base64 不提供校验和或任何用于存储的任何值。

Base64 编码比原始二进制格式增加了 33% 的存储需求。 它还增加了必须从持久存储读取的数据量，这通常仍然是计算中的最大瓶颈。 读取更少的字节并动态编码它们通常更快。 仅当您的系统受 CPU 限制而不是 IO 限制，并且您经常在 base64 中输出图像时，才考虑将图像存储在 base64 中。

内联图像（嵌入在 HTML 中的 base64 编码图像）本身就是一个瓶颈——您通过网络发送的数据增加了 33%，并且是串行执行的（web 浏览器必须等待内联图像才能完成下载页面HTML）。

如果您仍希望存储 base64 编码的图像，无论您做什么，请确保不要将 base64 编码的数据存储在 UTF8 列中，然后对其进行索引。