Base84：跨平台文件名编码的新解法
Base84 deserves a place in file names
TurboCrypt 工具原本使用 Base91 加密文件名，以适配 Unix 和 macOS 系统，但 Windows 对文件名字符有严格限制，导致兼容性问题。为了解决这一痛点，TurboCrypt 决定转向 Base84 编码。Base84 巧妙避开了 Windows 禁止的 9 个字符以及末尾的点号，仅保留 84 个在 Linux、macOS 和 Windows 上均安全的 ASCII 字符。这种编码方式每 5 个字符可容纳约 32 位数据，扩展率仅为 25.2%，优于 Base64。更妙的是，其编码规则天然避开了 Windows 的保留设备名（如 CON、NUL），无需额外处理。对于需要跨平台安全存储加密文件名的场景，Base84 提供了一个既高效又稳健的解决方案。
Base84 是一个完美的选择，适用于任何需要编码为可移植且文件系统安全名称的场景。
HN 评论区
60- abound
> 这是按编码顺序排列的字符集：
> ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!#$%&'()+,-;=@[]^_`{}~
> 是的，如果我要在 shell 里对这些文件做任何操作，我绝对不想文件名里包含最后那 ~22 个字符。
- bensyverson
这些非字母数字字符简直就是自找麻烦。代理程序（Agents）往往无法正确转义它们，而且 $ 符号还可能导致变量展开。
Base62（或者带 -_ 的 Base64）完全够用了。
- est
macOS 的默认文件系统真是怪得很。
它在存储时不区分大小写，但在显示时却区分大小写。
我吃过亏才学到这一课，因为我的某个 git 仓库里有些文件死活下载不下来。
- killerstorm
比 Base32 效率高 27%，代价却是各种奇怪的 shell 脚本兼容性问题。哎呀！
- Dwedit
与此同时，Windows 内部到处都用 UTF-16，所以 "a" 和 "あ" 都是 2 字节大。
你仍然必须从文件名中排除代理对（surrogate pairs）和 Unicode 控制字符。