Note that 1-byte pieces do not need to be padded by 2 = signs; only 1 is
enough to indicate the end of an octets-span. The extra = after it do not
add any other octet. and as well you're allowed to insert whitespaces
anywhere in the encoded stream (this is what ensures that the
Base64-encoded octets-stream will not be altered if line breaks are forced
anywhere (notably within the body of emails).
So yes, Base64 is highly flexible, because any whitespace (SPACE, TAB, CR,
LF, NEL) in the middle is non-significant and ignorable on decoding (their
"encoded" bit length is 0 and they don't terminate an octets-span, unlike
"=" which discards extra bits remaining from the encoded stream before that
are not on 8-bit boundaries).
Also:
- For 1-octets pieces the minimum format is "XX= ", but the 2nd "X" symbol
before "=" can vary in its 4 lowest bits (which are then ignored/discarded
by the "=" symbol)
- For 2-octets pieces the minimum format is "XXX= ", but the 3rd "X" symbol
before "=" can vary in its 2 lowest bits (which are then ignored/discarded
by the "=" symbol)
So you can use Base64 by encoding each octet in separate pieces, as one
Base64 symbol followed by an "=" symbol, and even insert any number of
whitespaces between them: there's a infinite number of valid Base64
encodings for representing the same octets-stream payload.
Base64 allows encoding any octets streams but not directly any bits-streams
: it assumes that the effective bits-stream has a binary length multiple of
8. To encode a bits-stream with an exact number of bits (not multiple of
8), you need to encode an extra payload to indicate the effective number of
bits to keep at end of the encoded octets-stream (or at start):
- Base64 does not specify how you convert a bitstream of arbitrary length
to an octets-stream;
- for that purpose, you may need to pad the bits-stream at start or at end
with 1 to 6 bits (so that it the resulting bitstream has a length multiple
of 8, then encodable with Base64 which takes only octets on input).
- these extra padding bits are not significant for the original bitstream,
but are significant for the Base64 encoder/decoder, they will be discarded
by the bitstream decoder built on top of the Base64 decoder, but not by the
Base64 decoder itself.
You need to encode somewhere with the bitstream encoder how many padding
bits (0 to 7) are present at start or end of the octets-stream; this can be
done:
- as a separate payload (not encoded by Base64), or
- by prepending 3 bits at start of the bits-stream then padded at end with
1 to 7 random bits to get a bit-length multiple of 8 suitable for Base64
encoding.
- by appending 3 bits at end of the bits-stream, just after 1 to 7 random
bits needed to get a bit-length multiple of 8 suitable for Base64 encoding.
Finally your bits-stream decoder will be able to use this padding count to
discard these random padding bits (and possibly realign the stream on
different byte-boundaries when the effective bitlength bits-stream payload
is not a multiple of 8 and padding bits were added)
Base64 also does not specify how bits of the original bits-stream payload
are packed into the octets-stream input suitable for Base64-encoding,
notably it does not specify their order and endian-ness. The same remark
applies as well for MIME, HTTP. So lot of network protocols and file
formats need to how to properly encode which possible option is used to
encode bits-streams of arbitrary length, or need to specify which default
choice to apply if this option is not encoded, or which option must be used
(with no possible variation). And this also adds to the number of distinct
encodings that are possible but are still equivalent for the same effective
bits-stream payload.
All these allowed variations are from the encoder perspective. For
interoperability, the decoder has to be flexible and to support various
options to be compatible with different implementations of the encoder,
notably when the encoder was run on a different system. And this is the
case for the MIME transport by mail, or for HTTP and FTP transports, or
file/media storage formats even if the file is stored on the same system,
because it may actually be a copy stored locally but coming from another
system where the file was actually encoded).
Now if we come back to the encoding of plain-text payloads, Unicode just
specifies the allowed range (from 0 to 0x10FFFF) for scalar values of code
points (it actually does not mandate an exact bit-length because the range
does not fully fit exactly to 21 bits and an encoder can still pack
multiple code points together into more compact code units.
However Unicode provides and standardizes several encodings (UTF-8/16/32)
which use code units whose size is directly suitable as input for an
octets-stream, so that they are directly encodable with Base64, without
having to specify an extra layer for the bits-stream encoder/decoder.
But many other encodings are still possible (and can be conforming to
Unicode, provided they preserve each Unicode scalar value, or at least the
code point identity because an encoder/decoder is not required to support
non-character code points such as surrogates or U+FFFE), where Base64 may
be used for internally generated octets-streams.
Le dim. 14 oct. 2018 à 03:47, Adam Borowski via Unicode <unicode_at_unicode.org>
a écrit :
> On Sun, Oct 14, 2018 at 01:37:35AM +0200, Philippe Verdy via Unicode wrote:
> > Le sam. 13 oct. 2018 à 18:58, Steffen Nurpmeso via Unicode <
> > unicode_at_unicode.org> a écrit :
> > > The only variance is described as:
> > >
> > > Care must be taken to use the proper octets for line breaks if base64
> > > encoding is applied directly to text material that has not been
> > > converted to canonical form. In particular, text line breaks must be
> > > converted into CRLF sequences prior to base64 encoding. The
> > > important thing to note is that this may be done directly by the
> > > encoder rather than in a prior canonicalization step in some
> > > implementations.
> > >
> > > This is MIME, it specifies (in the same RFC):
> >
> > I've not spoken aboutr the encoding of new lines **in the actual encoded
> > text**:
> > - if their existing text-encoding ever gets converted to Base64 as if
> the
> > whole text was an opaque binary object, their initial text-encoding will
> be
> > preserved (so yes it will preserve the way these embedded newlines are
> > encoded as CR, LF, CR+LF, NL...)
> >
> > I spoke about newlines used in the transport syntax to split the initial
> > binary object (which may actually contain text but it does not matter).
> > MIME defines this operation and even requires splitting the binary object
> > in fragments with maximum binary size so that these binary fragments can
> be
> > converted with Base64 into lines with maximum length. In the MIME Base64
> > representation you can insert newlines anywhere between fragments encoded
> > separately.
>
> There's another kind of fragmentation that can make the encoding differ
> (but
> still decode to the same payload):
>
> The data stream gets split into 3-byte internal, 4-byte external packets.
> Any packet may contain less than those 3 bytes, in which cases it is padded
> with = characters:
> 3 bytes XXXX
> 2 bytes XXX=
> 1 byte XX==
>
> Usually, such smaller packets happen only at the end of a message, but to
> support encoding a stream piecewise, they are allowed at any point.
>
> For example:
> "meow" is bWVvdw==
> "me""ow" is bWU=b3c=
> yet both carry the same payload.
>
> > Base64 is used exactly to support this flexibility in transport (or
> > storage) without altering any bit of the initial content once it is
> > decoded.
>
> Right, any such variations are in packaging only.
>
>
> ᛗᛖᛟᚹ
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
> ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
> ⠈⠳⣄⠀⠀⠀⠀ and 1 who narrowly avoided an off-by-one error.
>
Received on Sun Oct 14 2018 - 03:41:58 CDT
This archive was generated by hypermail 2.2.0 : Sun Oct 14 2018 - 03:41:58 CDT