Python 3.5 base64 解码似乎不正确？

Question

在Python 3.5 中，base64 模块有一个方法 standard_b64decode() 用于从 base64 解码字符串，它返回一个 bytes 对象。

当我运行base64.standard_b64decode("wc==") 时，输出为b\xc1。当你对"\xc1"进行base64编码时，你得到"wQ=="。解码功能似乎有错误。实际上，我认为 "wc==" 是一个无效的 base64 编码字符串，理由如下：

1. wc== 以== 结尾，这意味着它是从单个输入字节生成的。

2. 正则base64字母表中'w'和'c'的对应值分别为48和28，意思是它们的6位表示分别为110000和@987654338 @。

3. 连接这些，前 8 位是11000001，即\xc1，但其余位 (1100) 非零，因此不可能由执行的填充过程产生在 base64 编码期间，因为它只会附加值为 0 的位，这意味着这些额外的 1 位不能通过有效的 base64 编码产生 -> 该字符串不是有效的 base64 编码字符串。

当第二个字符的最后 4 位中的任何一个是 1 时，我认为对于以 == 结尾的任何 4 个字符的 base64 编码块都是如此。

我非常确信这是正确的，但我的经验不如 Python 开发人员。

任何人都可以确认上述内容，或者解释为什么它是错误的，如果确实如此的话？

Answer 1

Base64 标准由RFC 4648 定义。 §3.5回答你的问题：

规范编码

base 64 和 base 32 编码中的填充步骤如果实施不当，可能会导致编码数据的非显着更改。例如，如果输入对于 base 64 编码只有一个八位字节，则使用第一个符号的所有六位，但只使用下一个符号的前两位。这些填充位必须通过一致的编码器设置为零，这在下面的填充描述中进行了描述。如果此属性不成立，则没有基本编码数据的规范表示，并且可以将多个基本编码字符串解码为相同的二进制数据。如果此属性（以及本文档中讨论的其他属性）成立，则保证规范编码。

在某些环境中，更改至关重要，因此如果填充位未设置为零，解码器可能会选择拒绝编码。

MAY的含义由RFC 2119定义：

可能这个词，或形容词“可选”，意味着一个项目是真正的可选。一个供应商可能会选择包含该项目，因为特定市场需要它，或者因为供应商认为它增强了产品，而另一个供应商可能会省略相同的项目。

因此标准没有强制 Python 拒绝非规范编码。