kuon / java-base24 Goto Github PK

Currently the encoding only supports the input lengths in multiples of 4 bytes or 7 characters depending on operation.

During implementation it became evident that encoding can be extended to support inputs of any arbitrary length.

The tricky part is the fact that log2(24) = 4.585 bits, i.e. 4.585 bits per encoded symbol which is a fractional value.

Here is the implementation: https://github.com/gapotchenko/Gapotchenko.FX/blob/new/Source/Data/Encoding/Gapotchenko.FX.Data.Encoding.Base24/GenericKuonBase24.cs

I am not too proud of it cause it uses floating point operations to track the number of bits. But it works reliably enough to share the achievement with you.

Another missing part was the padding. It is not required when inputs are strict multiplies of 4, but it is a good preference to have it for fractional blocks of data to allow a seamless support for concatenated blocks. The '=' padding symbol is a traditional choice of BaseN encodings.

Here are some test vectors for padded variable-length Kuon Base24 encoding:

"", "",
"00", "Z======",
"01", "A======",
"FF", "H7=====",
"FF00", "B84Z===",
"0102", "ZHR====",
"010203", "ZBRP2==",
"009060", "ZCPBZ=="

I also ran a data fuzzer for all possible data combinations with perfect results.

Choosing 7 characters blocks is a neat trick as it gives a nearly perfect log2(24^7) = 32.095 bits per block which is roughly corresponds to 4 bytes. Having these pieces at hand, the proposed Base24 encoding is a good candidate for RFC.

The proposed implementation is a variation of Base24 encoding.

You refer to it as "Base24" but there is no standardized approach for such an encoding yet in contrast to something like Base64 which is defined by W3C RFCs.

This means that we should give it a specific name. Some obvious proposals that come into mind are:

1. Kuon Base24
2. Goi Base24
3. your suggestion ?

What name you do you prefer?

I would also suggest to imprint that chosen name into spec.