etti wrote:
Hi,
RFC 4648, in section "3.5. Canonical Encoding", prescribes that pad
bits must be set to zero.
However, the current decoder implementation in java.util.Base64
accepts non-canonical encodings as well. For example, all of the
following four encodings
KCk=
KCl=
KCm=
KCn=
w
tion "3.5. Canonical Encoding", prescribes that pad
bits must be set to zero.
However, the current decoder implementation in java.util.Base64
accepts non-canonical encodings as well. For example, all of the
following four encodings
KCk=
KCl=
KCm=
KCn=
where only the first is canonical,
of the existing tests fail if the non-canonical encoding throws?
Thanks, Roger
On 6/23/20 9:00 AM, Raffaello Giulietti wrote:
Hi,
RFC 4648, in section "3.5. Canonical Encoding", prescribes that pad
bits must be set to zero.
However, the current decoder implementation in java
fail if the non-canonical encoding throws?
Thanks, Roger
On 6/23/20 9:00 AM, Raffaello Giulietti wrote:
Hi,
RFC 4648, in section "3.5. Canonical Encoding", prescribes that pad
bits must be set to zero.
However, the current decoder implementation in java.util.Base64
accepts non
Hi,
RFC 4648, in section "3.5. Canonical Encoding", prescribes that pad bits
must be set to zero.
However, the current decoder implementation in java.util.Base64 accepts
non-canonical encodings as well. For example, all of the following four
encodings
KCk=
KCl=
KCm=
KCn=
wher