Python might say that, but as often it’s not really true: it really mostly works off of 2045
- the “default” encoder (“b64encode”) will pad the output
- although it will not linebreak (“encodebytes”) does that)
- the default decoder will error if the input is not padded
- the default decoder will ignore all non-encoding characters by default
Also both b64encode and encodebytes actually use binascii.b2a_base64, which claims conformance to RFC 3548, which attempts to unify 1421 and 2045. Except RFC 3548 requires rejecting non-encoding data, whereas (again) Python accepts an ignores it by default, in 2045 fashion.
Comments
So there are 7 base64 encodings, one with “+ / =“, one with “- _ =“, one with “+,” and no “=“… https://en.wikipedia.org/wiki/Base64#Variants_summary_table
And decoders typically aren't interoperable, requiring you to use the specific decoder for that combination.
Which is silly, because there’s no good reason to, except for strict validation.
TIL.
And Python uses RFC 4648
Python might say that, but as often it’s not really true: it really mostly works off of 2045
- the “default” encoder (“b64encode”) will pad the output
- although it will not linebreak (“encodebytes”) does that)
- the default decoder will error if the input is not padded
- the default decoder will ignore all non-encoding characters by default
Also both b64encode and encodebytes actually use binascii.b2a_base64, which claims conformance to RFC 3548, which attempts to unify 1421 and 2045. Except RFC 3548 requires rejecting non-encoding data, whereas (again) Python accepts an ignores it by default, in 2045 fashion.