4 ms·
If your original data is not a byte sequence then it would indeed work. Otherwise you have to convert it back to bytes yourself, but no small x exists such that
by lifthrasiir 2y ago
If your original data is not a byte sequence then it would indeed work. Otherwise you have to convert it back to bytes yourself, but no small x exists such that 10^x is just barely smaller than 256^y and bignum would be necessary for efficient encoding. Base45 doesn't need bignum and only incurs ~3.2% overhead [1] compared to the pure octet mode (which might be unsuitable for decoder compatibility and other purposes though).
[1] 32 original bits = 4 original bytes = 6 base45-encoded letters = 33 bits in the alphanumeric mode, so the overhead is 1 - 33/32 = 0.03125 for 4n bytes of data.
- josh11b 2y ago10^12 < 256^5 ≈ 1.1e+12, which isn't too bad. You could also use 10^118 < 256^49, which wastes less but is in bignum land. But don't you want 10^x to be slightly bigger than 256^y, so you could represent all length-y byte sequences in x-digit number? In this direction, there's 10^53 > 256^22, but that is still in bignum land.
- Dylan16807 2y agoYeah, use a bignum. QR codes are not very big. And while 3% overhead is fine, encoding decimal digits in groups of 3 is only 0.3% plus a couple bits to round up to the nearest digit.