Next was an issue were the library I used to encode the data, qrtools, would generate a qr code, but the data would not be the same when decoding! So I fixed this by detecting this, then adding some padding to the data and trying again until it works, then strip the padding off on the other side.
That needs some explanation; Wikipedia has a capacity table (albeit for the largest, least error-corrected possible configuration, which the author is presumably not using) and bytes are nearly 10% more efficient than base32-over-alphanum.
I think it’s because of how the info is encoded as a first class encoding scheme. With byte encoding, each character is represented by a full byte or 8-bits and only supports ISO/IEC 8859-1 aka Latin-1 encoding. In the case of alphanumeric encoding, they only support basically a selection of 45 characters giving 5.5bits per character or 11 bits per character pair. By excluding the vast majority of characters that are uncommon, they’ve reduced the number of elements that can be encoded, thus reducing the number of bits needed to encode any single character.
A 10 character long base32 string will require 105.5 or 55 bits to encode in alphanumeric. Base 64 is not possible because only 45 characters are supported so you must use something like byte encoding which uses latin1 which will be 8 bits per character, requiring 108 or 80 bits.
I’m sure you could run a base64 compressor so you use exactly 6 bits per character and them feed it into the QR encoder as Latin one but the decoder will need to know the QR code has this extra level of encoding to work with. This method would get you the full use of base64 with only about 10% decrease in space efficiency.
Today I learned I apparently do not understand at all how QR codes work.
Extra WTF:
More WTF:
That needs some explanation; Wikipedia has a capacity table (albeit for the largest, least error-corrected possible configuration, which the author is presumably not using) and bytes are nearly 10% more efficient than base32-over-alphanum.
I think it’s because of how the info is encoded as a first class encoding scheme. With byte encoding, each character is represented by a full byte or 8-bits and only supports ISO/IEC 8859-1 aka Latin-1 encoding. In the case of alphanumeric encoding, they only support basically a selection of 45 characters giving 5.5bits per character or 11 bits per character pair. By excluding the vast majority of characters that are uncommon, they’ve reduced the number of elements that can be encoded, thus reducing the number of bits needed to encode any single character.
A 10 character long base32 string will require 105.5 or 55 bits to encode in alphanumeric. Base 64 is not possible because only 45 characters are supported so you must use something like byte encoding which uses latin1 which will be 8 bits per character, requiring 108 or 80 bits.
I’m sure you could run a base64 compressor so you use exactly 6 bits per character and them feed it into the QR encoder as Latin one but the decoder will need to know the QR code has this extra level of encoding to work with. This method would get you the full use of base64 with only about 10% decrease in space efficiency.