Ruiqi Dong created CODEC-340:
--------------------------------
Summary: Base58.Builder#setEncodeTable(...) is ignored by Base58
Key: CODEC-340
URL: https://issues.apache.org/jira/browse/CODEC-340
Project: Commons Codec
Issue Type: Bug
Reporter: Ruiqi Dong
*Summary*
Base58.Builder exposes setEncodeTable(...), which suggests a caller can
configure a custom Base58 alphabet. However, Base58 encoding and decoding still
use the hard-coded default alphabet internally. As a result, the builder
accepts custom configuration that is silently ignored.
*Affected code*
File: src/main/java/org/apache/commons/codec/binary/Base58.java
The builder accepts custom tables:
{code:java}
public Base58.Builder setEncodeTable(final byte... encodeTable) {
super.setDecodeTableRaw(DECODE_TABLE);
return super.setEncodeTable(encodeTable);
} {code}
But the codec still uses the built-in constants directly:
{code:java}
final int digit = b < DECODE_TABLE.length ? DECODE_TABLE[b] : -1; {code}
{code:java}
base58.append((char) ENCODE_TABLE[divRem[1].intValue()]); {code}
{code:java}
base58.append('1'); {code}
So the configured alphabet is not used on either encode or decode.
*Reproducer*
Add the following test to
src/test/java/org/apache/commons/codec/binary/Base58Test.java:
{code:java}
@Test
void testBuilderCustomEncodeTableAffectsEncodeAndDecode() {
final byte[] encodeTable =
"123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz".getBytes(StandardCharsets.US_ASCII);
final byte tmp = encodeTable[0];
encodeTable[0] = encodeTable[1];
encodeTable[1] = tmp;
final Base58 base58 = Base58.builder().setEncodeTable(encodeTable).get();
assertEquals("1", new String(base58.encode(new byte[] {1}),
StandardCharsets.US_ASCII),
"A custom Base58 alphabet should affect encoding");
assertArrayEquals(new byte[] {1},
base58.decode("1".getBytes(StandardCharsets.US_ASCII)),
"A custom Base58 alphabet should affect decoding consistently");
} {code}
Run:
{code:java}
mvn -q
-Dtest=org.apache.commons.codec.binary.Base58Test#testBuilderCustomEncodeTableAffectsEncodeAndDecode
test {code}
Observed behavior:
{code:java}
expected: <1> but was: <2> {code}
That is the output for the built-in alphabet, not the configured one.
Expected behavior:
If setEncodeTable(...) is part of the public builder API, the resulting Base58
instance should actually use that alphabet consistently for both encoding and
decoding. Otherwise, the builder should reject the unsupported configuration
instead of accepting it silently.
This is a configuration/state bug in a public API. The builder records a custom
alphabet, but the operational code paths ignore it and continue using the
default constants. That makes the exposed configuration misleading and
non-functional.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
