为什么不将加密数据作为二进制文件存储在数据库中？
Is there a reason why not to store encrypted data as binary in a database?
我必须将 AES-GCM 加密数据存储在数据库中。目前我们使用 MariaDB，但可以选择稍后更改为 PostgreSQL。 （但也应考虑其他数据库）
既然该算法实际上加密的不是字符串，而是字节，而且加密算法的输出也是一个字节[]，为什么不将加密后的数据直接存储在二进制列中呢？
对于 MariaDB/MySql 来说就是 BLOB。我知道 PostgreSQL 甚至有一种用于加密数据的首选特殊数据类型，称为 bytea.
然而，大多数程序员似乎将加密字节编码为 Base64，并将生成的字符串存储在 VARCHAR 中。
Base64 的编码和解码对我来说似乎违反直觉。它使数据的长度最多增加 50%，并且每次都是一个额外的步骤。它还强制数据库在存储和检索数据时应用字符编码。这是一个额外的步骤，肯定会花费额外的时间和资源，而我们真正需要存储的只是一些字节。加密数据在任何字符编码中都没有任何意义。
问题：
是否有任何充分的理由支持或反对将加密数据以二进制形式存储在数据库中？出于安全、数据完整性或性能方面的原因，我不想将加密数据直接存储为二进制文件吗？
（我想这个问题很快就会被关闭为 "opinion based" - 但尽管如此）
Is there any good reason for or against storing encrypted data as binary in a database
没有。我看不出有任何理由反对使用正确的 "blob" 类型 (BLOB, bytea, varbinary(max), ....)
一般的经验法则是：使用与数据匹配的数据类型。所以 BLOB （或等效类型）是正确的选择。
使用 base64 编码的字符串可能是因为并非所有库（混淆层，如 ORM）都能够正确处理 "blobs"，所以人们选择使用普遍适用的东西（忽略开销存储和处理）。
请注意，Postgres 的 bytea 不是 "a special type for encrypted data"。它是 二进制 数据（图像、文档、音乐...）的通用数据类型
我必须将 AES-GCM 加密数据存储在数据库中。目前我们使用 MariaDB，但可以选择稍后更改为 PostgreSQL。 （但也应考虑其他数据库）
既然该算法实际上加密的不是字符串，而是字节，而且加密算法的输出也是一个字节[]，为什么不将加密后的数据直接存储在二进制列中呢？
对于 MariaDB/MySql 来说就是 BLOB。我知道 PostgreSQL 甚至有一种用于加密数据的首选特殊数据类型，称为 bytea.
然而，大多数程序员似乎将加密字节编码为 Base64，并将生成的字符串存储在 VARCHAR 中。
Base64 的编码和解码对我来说似乎违反直觉。它使数据的长度最多增加 50%，并且每次都是一个额外的步骤。它还强制数据库在存储和检索数据时应用字符编码。这是一个额外的步骤，肯定会花费额外的时间和资源，而我们真正需要存储的只是一些字节。加密数据在任何字符编码中都没有任何意义。
问题：
是否有任何充分的理由支持或反对将加密数据以二进制形式存储在数据库中？出于安全、数据完整性或性能方面的原因，我不想将加密数据直接存储为二进制文件吗？
（我想这个问题很快就会被关闭为 "opinion based" - 但尽管如此）
Is there any good reason for or against storing encrypted data as binary in a database
没有。我看不出有任何理由反对使用正确的 "blob" 类型 (BLOB, bytea, varbinary(max), ....)
一般的经验法则是：使用与数据匹配的数据类型。所以 BLOB （或等效类型）是正确的选择。
使用 base64 编码的字符串可能是因为并非所有库（混淆层，如 ORM）都能够正确处理 "blobs"，所以人们选择使用普遍适用的东西（忽略开销存储和处理）。
请注意，Postgres 的 bytea 不是 "a special type for encrypted data"。它是 二进制 数据（图像、文档、音乐...）的通用数据类型