I'm not that familiar with QR codes. Anyone know how base16/hexadecimal encoding with 0-9A-F fares in comparison? It seems like an obvious encoding to test, especially for simplicity of implementation compared to base64 and base10, and an odd one to miss for comparison?
10 > 64, in QR Codes
11–20 of 83 posts
Re: 10 > 64, in QR Codes
#12https://zat.is uses uppercase base32 for URL checksums, as alphanumeric QR codes can contain 0–9, A–Z (upper-case only), space, $, %, *, +, -, ., /, :. Overhead is only 10% (5.5 bits / 5 bits). All links fit in a 33⨯33px image, margins included, so little point in improving on that for URLs so short. The tradeoff is that the checksum to URL mapping is stored in a backend and networking is required to learn anything about the real URL.
Re: 10 > 64, in QR Codes
#13I'm not that familiar with QR codes. Anyone know how base16/hexadecimal encoding with 0-9A-F fares in comparison? It seems like an obvious encoding to test, especially for simplicity of implementation compared to base64 and base10, and an odd one to miss for comparison?
Hex is worse, see here [1] for UUIDs
Re: 10 > 64, in QR Codes
#14I'm not that familiar with QR codes. Anyone know how base16/hexadecimal encoding with 0-9A-F fares in comparison? It seems like an obvious encoding to test, especially for simplicity of implementation compared to base64 and base10, and an odd one to miss for comparison?
The QR standard does not have a specific encoding mode [0] for hexademical, it would have to use alphanumeric. Since you'd only be using 16 out of 35 possible characters, it would be much less efficient.
0: https://en.wikipedia.org/wiki/QR_code#Information_capacity
Re: 10 > 64, in QR Codes
#15Thanks to the author's previous post, I instantly recognised the `eyJ` prefix as the start of a JSON object!
Re: 10 > 64, in QR Codes
#16base10 can be awkward to work with for large data, one can also consider:
base8 in numeric mode: 8 input bits -> 3 digits -> 10 output bits, 25% overhead
base32 in alphanumeric mode: 5 input bits -> 1 character -> 5.5 output bits, 10% overhead
I would prefer base32 out of these too, but it's interesting that even base8 beats base64 here.
Re: 10 > 64, in QR Codes
#17I had an idea to embed a webpage in a dataurl and convert that to a QR code; the website would only exist on if you snapped the QR Code. I was dreaming of code-golf, demoscene, nft and weird business card applications, but the web-browsers ruined my fun because they won't display dataURL unless you manually copy/paste it into the URL bar.
Re: 10 > 64, in QR Codes
#18In an ideal world, the QR standard would include a specific URL encoding scheme that exactly matches the URL-safe character set. But I suppose there's no real practical way to make big changes to the QR spec now, what with all the thousands of implementations in the wild.
Re: 10 > 64, in QR Codes
#19I had an idea to embed a webpage in a dataurl and convert that to a QR code; the website would only exist on if you snapped the QR Code. I was dreaming of code-golf, demoscene, nft and weird business card applications, but the web-browsers ruined my fun because they won't display dataURL unless you manually copy/paste it into the URL bar. https://issues.chromium.org/issues/40502904
Good idea. Built https://srv.us/d that does (edited):
document.body.innerHTML = decodeURI(window.location.hash.substring(1))
Re: 10 > 64, in QR Codes
#20I'm not that familiar with QR codes. Anyone know how base16/hexadecimal encoding with 0-9A-F fares in comparison? It seems like an obvious encoding to test, especially for simplicity of implementation compared to base64 and base10, and an odd one to miss for comparison?
Most compact QR encoding capable of representing hex symbols is alphanumeric mode which requires 5.5 bits per character. Which means the output will be 5.5/4 = 1.375 times longer than encoded binary data or 37.5% overhead. That's even worse than 8/6 =1.33 you get for doing base64 encoding on top of byte mode.