Base36 fails round trip encoding of empty byte arrays

[hossman]

I'm not really familiar with the multibase project, or it's goals -- but I found this repo while looking for a general Base36 encoding/decoding class.

I thought i should point out that the Base36.java helper class can not handle encoding an empty byte[] such that the resulting string can be decoded back into an empty byte[] of the same size

Important

In any (in = new byte[x]) -> encode -> decode -> out situation, the resulting byte[] out will always have two extra bytes -- and re-encoding the out array as a string will always have 2 extra characters.

The problem does not exist as long as there is a single set bit anywhere in the byte[] input

consider the following trivial example...

for (int i = 0; i < 10; i++) {
  byte[] in = new byte[i];
  String s = Base36.encode(in);
  byte[] out = Base36.decode(s);
  System.out.println(i + ":0=" + in.length  + " -> " + s);
  System.out.println(i + ":0=" + out.length + " <- " + Base36.encode(out));

  if (0 < in.length) {
    in[in.length-1] = 1;
    s = Base36.encode(in);
    out = Base36.decode(s);
    System.out.println(i + ":1=" + in.length  + " -> " + s);
    System.out.println(i + ":1=" + out.length + " <- " + Base36.encode(out));
  }
  System.out.println();
}

...the output is...

0:0=0 -> 0
0:0=2 <- 000

1:0=1 -> 00
1:0=3 <- 0000
1:1=1 -> 1
1:1=1 <- 1

2:0=2 -> 000
2:0=4 <- 00000
2:1=2 -> 01
2:1=2 <- 01

3:0=3 -> 0000
3:0=5 <- 000000
3:1=3 -> 001
3:1=3 <- 001

4:0=4 -> 00000
4:0=6 <- 0000000
4:1=4 -> 0001
4:1=4 <- 0001

5:0=5 -> 000000
5:0=7 <- 00000000
5:1=5 -> 00001
5:1=5 <- 00001

6:0=6 -> 0000000
6:0=8 <- 000000000
6:1=6 -> 000001
6:1=6 <- 000001

7:0=7 -> 00000000
7:0=9 <- 0000000000
7:1=7 -> 0000001
7:1=7 <- 0000001

8:0=8 -> 000000000
8:0=10 <- 00000000000
8:1=8 -> 00000001
8:1=8 <- 00000001

9:0=9 -> 0000000000
9:0=11 <- 000000000000
9:1=9 -> 000000001
9:1=9 <- 000000001