MySQL 8.0+ 原生支持 TO_BASE64() 和 FROM_BASE64()，前者将字符串/BLOB转为Base64 TEXT，后者将Base64字符串解码为 VARBINARY；输入需为合法UTF-8，非法字符或双重编码会导致NULL而非报错。
MySQL 8.0+ 的 TO_BASE64() 和 FROM_BASE64() 怎么用
这两个函数只在 MySQL 8.0 及以上版本原生支持，低版本会报错 FUNCTION xxx does not exist。它们处理的是字符串（VARCHAR、TEXT）的 Base64 编解码，输入必须是合法 UTF-8 字节序列，否则可能截断或报错。
实操建议：
-
TO_BASE64()接收一个字符串或 BLOB，返回 Base64 编码后的TEXT；若输入为NULL，结果也是NULL -
FROM_BASE64()接收 Base64 字符串，返回解码后的VARBINARY；如果输入含非法字符（如空格、换行、非 Base64 字符），返回NULL，**不会抛异常** - 常见错误：把已编码过的字符串再传给
TO_BASE64()，导致双重编码；或把明文当 Base64 传给FROM_BASE64()，结果为NULL却没检查 - 示例：
SELECT TO_BASE64('hello'), FROM_BASE64('aGVsbG8=');→'aGVsbG8='和0x68656C6C6F
PostgreSQL 没有内置 TO_BASE64，得用 encode() 和 decode()
PostgreSQL 不提供类似 MySQL 的函数名，而是统一用 encode() / decode() 配合模式参数。Base64 是其中一种编码方式，不是唯一选项。
实操建议：
-
encode(data, 'base64')：第一个参数必须是bytea，所以对文本要先用convert_to(text, 'UTF8')转换 -
decode(str, 'base64')：输入是TEXT，输出是bytea；若字符串含非法填充或长度不对（非 4 的倍数），会报错invalid input syntax for type bytea - 别直接对中文字段调
encode(col, 'base64')——如果col是TEXT类型，会隐式转换失败；必须显式encode(convert_to(col, 'UTF8'), 'base64') - 示例：
SELECT encode(convert_to('你好', 'UTF8'), 'base64');→'5L2g5aW9'
SQL Server 的 FOR XML + CAST 组合容易出错
SQL Server 没有原生 Base64 函数，老写法依赖 FOR XML 的 BINARY BASE64 模式，但它是为 XML 设计的，不是通用编解码工具。
实操建议：
- 编码可用：
SELECT CAST(N'' AS XML).value('xs:base64Binary(xs:hexBinary(sql:column("bin")))', 'VARCHAR(MAX)')，但更常用且简洁的是：SELECT CAST('' AS XML).value('xs:base64Binary(sql:variable("@b"))', 'VARCHAR(MAX)')，其中@b是VARBINARY - 解码只能靠
CONVERT(VARBINARY, str, 1)—— 但这是十六进制解码，不是 Base64；真正 Base64 解码需 CLR 或外部函数，T-SQL 原生不支持 - 最大坑：有人误用
SELECT CAST('hello' AS VARBINARY) FOR XML PATH(''), BINARY BASE64，结果带 XML 标签和换行，不是纯 Base64 字符串 - SQL Server 2022+ 开始支持
STRING_AGG()等新函数，但依然没加 Base64 原生函数，别指望语法糖能绕过限制
跨数据库移植时，Base64 结果不一致的根源在哪
不是算法不同，而是输入字节流的解释方式不一致。比如同样处理字符串 café ，MySQL 默认按连接字符集（可能是 utf8mb4）取字节，PostgreSQL 严格依赖 convert_to() 指定的编码，SQL Server 则常被当成 Windows-1252 处理。
实操建议：
- 永远明确指定源数据的编码意图：MySQL 用
COLLATE utf8mb4_bin强制字节一致性；PostgreSQL 必须用convert_to(..., 'UTF8')；SQL Server 若用UTF-8排序规则（2019+），才可能对齐 - Base64 编码后末尾的
=填充是标准行为，但某些旧客户端或 ORM 会自动 trim，导致解码失败——检查日志里实际传入的是不是完整字符串 - 二进制安全是关键：
FROM_BASE64()返回VARBINARY，不是TEXT；如果后续要转成字符串，得用CONVERT或CAST显式声明目标编码，否则可能乱码
NULL 就静默吞掉你的数据，而你还在查 WHERE 条件有没有写错。 
