Re: base26 Encoder/Decoder

On 28.04.2024 10:12, Stefan Claas wrote:

So, in the end people are free to choose which base26 approach they like to use,
because there is no standard, like an RFC, available.

But base26 doesn't make much sense. How big are the chunks of the
data input stream you encode in base26? If you encode each byte,
you need 2 digits for the byte, which is the same as base16 (hex format).
The same is true for 2 and 3 byte chunks (4 and 6 digits). Starting
with 4 byte chunks you can save one digit (7 instead of 8 for hex).
The next step is at 7 byte chunks (12 instead of 14 digits for hex).
But this is also the biggest size which you can handle with 64 bit
arithmetic. Starting with 11 byte chunks you can save 3 digits (19
instead of 22 for hex), but this already requires long number
arithmetic.
So, if you can't use base32 at least, better stay at base16 (hex format)
instead of base26. There is only a small advantage in size, but a big
disadvantage in computing time and you have to cope with padding if the
message length is not a multiple of the chunk length.