url-safe 和 filename-safe base64 的最佳候选填充字符是什么？答案

【问题标题】：What's the best candidate padding char for url-safe and filename-safe base64?url-safe 和 filename-safe base64 的最佳候选填充字符是什么？
【发布时间】：2009-03-18 19:20:28
【问题描述】：

官方 base64 的填充字符是 '='，在 URL 中使用时可能需要进行百分比编码。我正在尝试找到最好的填充字符，以便我的编码字符串既可以是 url 安全的（我将使用编码的字符串作为参数值，例如 id=encodedString）和文件名安全的（我将使用编码的字符串直接作为文件名）。

点 ('.') 是一个受欢迎的候选者，它是 url 安全的，但它并不完全是文件名安全的：Windows won't allow a file name which ends with a trailing dot。

'！'似乎是一个可行的选择，虽然我用谷歌搜索过，我从未见过有人将它用作填充字符。有任何想法吗？谢谢！

更新：我已经在自定义 base64 编码中将“+”替换为“-”（减号），并将“/”替换为“_”（下划线），因此是“-”或“_” ' 不再可用于填充字符。

【问题讨论】：

标签： encoding base64 padding

【解决方案1】：

最好的解决方案（我上个月在一个电子邮件发送网站上解决了这个问题）是根本不使用填充字符 (=)

存在填充字符的唯一原因是因为“懒惰”的解码器。您可以非常轻松地添加缺少的 = -> 只需在文本上执行 %4 并从 4 中减去您得到的数字，这就是您需要在字符串结尾添加多少 =。这是C#代码：

    var pad = 4 - (text.Length % 4);
    if (pad < 4)
        text = text.PadRight(text.Length + pad, '=');

此外，大多数这样做的人都有兴趣将 + 和 / 替换为其他 URL 安全字符...我建议：

替换为 - / 替换为 _

请勿使用。因为它会在不同的系统/网络服务器上产生疯狂的结果（例如在 IIS Base64 编码的字符串不能以 . 结尾，否则 IIS 将搜索文件）

【讨论】：

不太正确，填充的结果不能被4整除。需要附加（4-pad）个'='字符而不是填充数字。否则整洁的解决方案。
@YoungBob 我已经编辑了答案，如果你能提出更好的代码，请编辑它。谢谢！
在 Python 中，您可以简单地使用 text + (-len(text) % 4) * "="，但这种计算方式不能在其他语言中使用（Python 中的 % 运算符为正除数提供正值）。

【解决方案2】：

URI 中的RFC 2396 未保留字符是：

"-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

不过，值得指出的是，微软的文章还说“不要假设区分大小写”。也许你应该坚持使用 16 或 32 基数？

【讨论】：

我会避免 . ~ * ' ( ) 用于文件名
谢谢 Miles，好像是“！”对 url 和文件名都有好处。也许我会用 base32 和 '!'作为填充字符。

【解决方案3】：

Wikipedia 文章指出；

修改后的 Base64 用于 URL 变体存在，其中没有填充“=”将是用过

【讨论】：

【解决方案4】：

我会选择“-”或“_”
它们是 URL 和文件安全的，它们看起来或多或少像填充

【讨论】：

对不起，我应该提到这一点：我已经在我的自定义 base64 编码中将“+”替换为“-”（减号）并将“/”替换为“”（下划线），所以' -' 或 '' 不再可用于填充字符。