核心结论
把二进制数据编码成文件名，看似只要选 Base64 就够了。真正跨过 Linux、macOS、Windows、同步客户端和图形文件管理器后，问题会变成字符禁用、尾部字符、保留名称、路径长度和库的额外限制。编码方案应按最严格的目标环境设计，而不是按某个文件系统的理论能力设计。
文件名编码的真实约束
常见 Base64 字母表含有加号、斜杠和等号。它适合传输，不适合直接作为可移植路径组件。URL 安全变体避开了部分字符，但填充与大小写、名字长度仍要考虑。十六进制最稳妥，却把每个字节扩成两个字符，长对象名很快碰到文件系统的长度上限。
设计文件名编码时，先列出约束。Windows 禁用一组标点字符，并对尾部空格和点有特殊规则。部分名称还会被解释为设备，即使带扩展名也可能失败。Unix 系统允许更多字节，但点号开头有隐藏语义，单点和双点又表示目录。云盘、压缩工具和跨语言库可能在这些规则之上再加限制。因此字母表应只使用三端都能稳定处理的字符。
编码效率与安全边界
可移植字母表的大小直接影响膨胀率。若能选择 84 个安全字符，五个输出字符可承载接近 32 位的数据，比常见 Base64 的平均膨胀更小，同时不必引入危险标点。编码器可以按块读取输入位，依据当前值决定消费 31 位还是 32 位，再输出固定长度的一组字符。解码器必须严格检查末尾组和非法字符，不能悄悄替换。
这里有一个容易忽略的限制。文件系统通常限制的是单个路径组件的字节数，而不是整条路径。即使编码字母表全为 ASCII，目录层级、前缀和临时扩展名也会占用预算。加密存储系统还需要预留版本号、认证标签和冲突后缀。设计时应先确定最大原始名称长度，超过时改用分片、内容寻址或独立元数据表。
落地测试与选择建议
安全上，文件名编码只能隐藏格式，不能替代认证。加密后的名称若缺少完整性校验，攻击者可以替换、重排或回放对象。解密程序应把路径规范化和授权检查放在打开文件之前，避免解码结果与上层路径处理产生差异。不要接受解码后包含分隔符、空字节或保留名称的结果，即便理论上编码器永远不会生成它们。
测试不需要复杂。建立含特殊字符、极长名称、不同 Unicode 形式和并发写入的样本集，在目标操作系统、同步工具和压缩流程中往返验证。再做随机数据的属性测试，确认编码解码互逆，输出不包含禁用字符，长度从不超过约束。跨平台问题通常在这一步暴露。
FAQ
Base64 URL 安全变体能直接用于文件名吗。可用于受控环境，但在多平台共享前仍应测试尾部填充、长度和应用程序行为。
为什么不直接用哈希。哈希适合内容寻址，却不能恢复原始名称。是否需要可逆性决定方案。