在Python 3.5 base64模块中有一个方法standard_b64decode()，用于解码来自base64的字符串，该字符串返回bytes个对象。
当我运行base64.standard_b64decode("wc==")时，输出为b\xc1。当您对"\xc1"进行base64编码时，您会获得"wQ=="。看起来解码功能有错误。实际上，我认为"wc=="是一个无效的base64编码字符串，基于这样的推理：
wc==以==结尾，这意味着它是从单个输入字节生成的。
常规base64字母表中'w'和'c'的对应值分别为48和28，表示其6位表示形式为，分别为110000和011100。
连接这些，前8位为11000001，即\xc1，但其余位（1100）不为零，所以不可能由base64编码期间执行的填充过程产生，因为它只附加值为0的位，这意味着这些额外的1位不能通过有效的base64编码生成 - ＆gt;该字符串不是有效的base64编码字符串。
我认为当第二个字符的最后4位中的任何一个为==时，以1结尾的任何4个字符的base64编码块都是如此。
我非常确信这是对的，但我的经验远不如Python开发人员。
任何人都可以确认上述内容，或解释为什么它是错的，如果它确实存在？
答案 0 :(得分：3)
Base64标准由RFC 4648定义。您的问题由§3.5回答：
Canonical Encoding
如果不正确地实现，基础64和基础32编码中的填充步骤可导致编码数据的非显着改变。例如，如果输入仅是基本64编码的一个八位字节，则使用第一个符号的所有六个位，但仅使用下一个符号的前两位。这些填充位必须通过符合编码器设置为零，这将在下面的填充描述中描述。如果此属性不成立，则不存在基本编码数据的规范表示，并且可以将多个基本编码的字符串解码为相同的二进制数据。如果此属性（以及本文档中讨论的其他属性）成立，则保证规范编码。在某些环境中，更改很关键，因此如果填充位未设置为零，解码器可能会选择拒绝编码。
MAY的含义由RFC 2119定义：
MAY 这个词，或形容词＆＃34; OPTIONAL＆＃34;，表示一个项目是真正可选的。一个供应商可能会选择包含该项目，因为特定的市场需要它，或者因为供应商认为它增强了产品，而另一个供应商可能会省略相同的项目。
因此，标准不要求Python拒绝非规范编码。