SRFI 281, inheriting the description from SRFI 207, ignore characters
that are char-whitespace?. However, RFC 4648 says[1]

 > Base encodings use a specific, reduced alphabet to encode binary
data.  Non-alphabet characters could exist within base-encoded data,
caused by data corruption or by design.  Non-alphabet characters may be
exploited as a "covert channel", where non-protocol data can be sent for
nefarious purposes.  Non-alphabet characters might also be sent in order
to exploit implementation errors leading to, e.g., buffer overflow attacks.

 > Implementations MUST reject the encoded data if it contains
characters outside the base alphabet when interpreting base-encoded
data, unless the specification referring to this document explicitly
states otherwise.

That covers us, since SRFI 207/281 say that the decoder must ignore
spaces. However, the security considerations outlined above still apply.

Outside of the security considerations (which I think to be a little
unlikely to be triggered, at least in a Scheme program), the requirement
that char-whitespace? characters be ignored makes it difficult to
accelerate base64->bytevector using SIMD instructions. This is important
since some code, like in web development, requires decoding and encoding
of base64 data over and over.

Similar comments apply to hex-string->bytevector, which is basically
Base16, but is case-insensitive. Currently in SRFI 281, but not in SRFI
207, the procedure ignores whitespace characters.

[1]: https://datatracker.ietf.org/doc/html/rfc4648#section-3.3

-- Peter McGoron