?!?!?!
QR codes support binary natively. What the hell even is base45?!
?!?!?!
QR codes support binary natively. What the hell even is base45?!
https://datatracker.ietf.org/doc/draft-faltstrom-base45/
"Even in Byte mode a typical QR-code reader tries to interpret a byte sequence as an UTF-8 or ISO/IEC 8859-1 encoded text. Thus QR-codes cannot be used to encode arbitrary binary data directly. Such data has to be converted into an appropriate text before that text could be encoded as a QR-code. Compared to already established Base64, Base32 and Base16 encoding schemes, that are described in RFC 4648 [RFC4648], the Base45 scheme described in this document offer a more compact QR-code encoding."
Here is the output alphabet:
Value Encoding Value Encoding Value Encoding Value Encoding
00 0 12 C 24 O 36 Space
01 1 13 D 25 P 37 $
02 2 14 E 26 Q 38 %
03 3 15 F 27 R 39 *
04 4 16 G 28 S 40 +
05 5 17 H 29 T 41 -
06 6 18 I 30 U 42 .
07 7 19 J 31 V 43 /
08 8 20 K 32 W 44 :
09 9 21 L 33 X
10 A 22 M 34 Y
11 B 23 N 35 Z
My initial thought is using "Space" as a valid encoded value seems like an enormous foot gun.I would have omitted these four (the asterix being there only to have a consecutive subset):
36 Space
37 $
38 %
39 *
Especially % can be confusing, as %20AA seems like a valid base45 both before and after urldecode. The $ is a lesser footgun.I'd be keen to learn why they decided to use full 45 characters available in alphanumeric QR.
The encoding is great, actually: 4n bytes will get encoded into 6n alnums (base45 symbols) which are 3n * 11 = 33n QR-bits. A loss of just 3% (33/32 - 1). This works because [ alnum1 alnum2 ] by spec must get packed into [ 11 bits ] in the QR message bitstream.
Wrote an explanation here: https://news.ycombinator.com/item?id=27592936
Which means it is a text mode, and actual scanners do treat it as text (although usually UTF-8 which goes against that standard, meh).