Bad decoding of concatenated Base64 files

[sebas642]

The library doesn't support decoding concatenated base64 files because it doesn't handle padding characters correctly when they are not located at the end of the stream.

For example, 'SQ==QU0=' should decode to [73,65,77] but it decodes to [73,0,0,65,77].

I have modfied the convert.js tests to show the problem in this patch base64-concat.txt.

[feross]

What is the reason you want this library to support concatenated base64 files? Node.js doesn't support that.

Buffer.from('SQ==QU0=', 'base64')
<Buffer 49>

If anything, we should abort when we see ==.

[sebas642]

I feel like this is a fairly standard feature. Wikipedia even says the following about padding bytes:

One case in which padding characters are required is concatenating multiple Base64 encoded files.’

This feature is supported by Chrome when using Data URLs, and in GNU coreutils:
$ echo "SQ==QU0=" | base64 --decode
IAM

While decoding concatenated base64 strings is helpful to me, it's not necessary. If it's not supported, ideally the limitation would be documented.

I agree that aborting when padding bytes are found would be better than the current behavior because it would make the error obvious instead of producing a corrupted bitstream.

[feross]

We now abort when padding bytes are found, so we match Node.js behavior.

[feross]

1.3.0