Hi,
I reproduced CODEC-348 on current master (JDK 21). With
new Base64(76, new byte[]{'\n'}, false, CodecPolicy.STRICT), decoding the
encoder's own output works, but the same bytes with the trailing '\n'
trimmed, as a single line, or with CRLF separators throw
IllegalArgumentException (via BaseNCodec.validateCanonicalEnd and
validateCanonicalByte).
LENIENT decodes all three, but it also accepts non-canonical trailing bits
(for example "AB=="), which STRICT rejects. So switching to LENIENT gives up
a guarantee that callers chose STRICT for.
I wrote a JUnit test with four cases (20 and 256 bytes), three of which
currently fail:
https://github.com/adarshomrey/commons-codec/blob/CODEC-348-strict-line-length/src/test/java/org/apache/commons/codec/binary/Base64StrictLineLengthTest.java
Before I write a fix, which direction would you prefer?
(1) an opt-in builder option for line-structure validation, keeping the
1.22.1 STRICT semantics as the default,
(2) relaxing the final-separator requirement, or
(3) keeping the 1.23.0 behavior and documenting it.
I'm happy to prepare a PR for whichever you choose.
Thanks,
Adarsh
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
