Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

10 > 64, in QR Codes

huonw.github.io

Post reply on HN
Print view View original

51–60 of 83 posts

Re: 10 > 64, in QR Codes

#51

Post by nneonneo »

londons_explore wrote: post #8

Or... Don't encode data in the URL at all. If your data isn't secret or per-user, have it go to https://yoursite.com/gh . If it is security sensitive, go to https://yoursite.com/Qhm4Qr55mS 2 alphanumerics (=4000 links) is plenty to encode a link to all the major pages of your website/service you may want to advertise. 10 alphanumerics (=10^18) is plenty that even if every person in the world had a QR code, nobody cou…

In the case of vaccine cards, which the OP uses as the case study, it's better to have the entire card offline for both privacy and offline use purposes.

Re: 10 > 64, in QR Codes

#52

Post by dbaupp »

JadeNB wrote: post #27

Why does the title have a "'" that isn't in the document ("'10 > 64, in QR Codes" versus "10 > 64, in QR Codes")?

Hacker News strips leading digits targeted at "listicles" (e.g. "10 ways to fizz buzz" -> "Ways to fizz buzz"), so tricks are required if the digits are actually important.

Re: 10 > 64, in QR Codes

#53

Post by dbaupp »

pclmulqdq wrote: post #35

I'm not sure if anyone uses Base36 any more (or its more obscure sister, Base32), but it uses [0-9, A-Z] as its alphabet. It is URL safe and also smaller than base 10 in character count for each number, and is the smallest standard URL-safe encoding that works with alphanumeric QR codes. I sort of assumed this was common knowledge, but I guess not.

I implicitly ignored encoding schemes like base 36 and 32 (and 16, referenced elsewhere in the thread) because they're not as good as the schemes referenced in the post. The best you can get that's fully URL safe with Alphanumeric is a hypothetical base 39, referenced in a footnote, and only using 39 of the 45 possible characters has 3.9% overhead (even ignoring the 50% overhead of the https://www.rfc-editor.org/rfc/rfc9285.html encoding).

I've added an analysis of many more bases to the article: https://huonw.github.io/blog/2024/03/qr-base10-base64/#fn:ot...

Re: 10 > 64, in QR Codes

#54

Post by dbaupp »

dbaupp wrote: post #49
Karellen wrote: post #11

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?

Ah, it is a good point that it might be worth comparing to, but it is far worse. Abstractly, it requires approximately log(45)/log(16) output bits per input bit, an overhead of 37%. Making this more concrete: each input byte is encoded as two hex digits, and two hex digits have to be encoded as two Alphanumeric characters. It thus takes 11 bits in the QR code bit stream to store 8 bits of input.

(I've added an analysis of this and other bases to the article: https://huonw.github.io/blog/2024/03/qr-base10-base64/#fn:ot...)

Re: 10 > 64, in QR Codes

#55

Post by dbaupp »

planede wrote: post #16

base10 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.

Good point! I've added an analysis of this and other bases to https://huonw.github.io/blog/2024/03/qr-base10-base64/#fn:ot...

Re: 10 > 64, in QR Codes

#56

Post by knallfrosch »

91bananas wrote: post #40
pclmulqdq wrote: post #35

I'm not sure if anyone uses Base36 any more (or its more obscure sister, Base32), but it uses [0-9, A-Z] as its alphabet. It is URL safe and also smaller than base 10 in character count for each number, and is the smallest standard URL-safe encoding that works with alphanumeric QR codes. I sort of assumed this was common knowledge, but I guess not.

Tooling is probably what dictates this more than anything. atob() is everywhere.

Yeah, I don't get it. Assume I have a standard URL with query params, the web browser doesn't understand the decimal encoding – right?

Let's assume... this: https://news.ycombinator.com/reply?id=39907672&goto=item%3Fi...

The special encoding is just about sending data to the backend?

Re: 10 > 64, in QR Codes

#57

Post by dbaupp »

FullyFunctional wrote: post #41

This is fascinating, but I was curious about the last two QR codes. The left one is scannable on my iPhone (iOS 17.4.1) leading to http://example.com/AAE..._w8fL whereas the one on the right gets only http://example.com (both Safari and Firefox). Is this an iOS URL length limitation?

Good catch! I should've tested. I've added a paragraph to https://huonw.github.io/blog/2024/03/qr-base10-base64/#extre... about this.

Re: 10 > 64, in QR Codes

#58

Post by bytecodes »

1. Pretty neat to switch encoding in the middle of the URL. It does look like it works and it does look like a better encoding. This is cool.

2. I'd have called this base-1000. It's using 3-digit numbers encoded into 10 bits. Base64 doesn't encode into 64 bits, it uses 64 characters encoded into 6 bits. And this encoding uses 000 to 999, encoded into 10 bits. But that messes up the title when you compare apples to apples, 1000 > 64 is just obvious and true.

Re: 10 > 64, in QR Codes

#59

Post by dbaupp »

bytecodes wrote: post #58

1. Pretty neat to switch encoding in the middle of the URL. It does look like it works and it does look like a better encoding. This is cool. 2. I'd have called this base-1000. It's using 3-digit numbers encoded into 10 bits. Base64 doesn't encode into 64 bits, it uses 64 characters encoded into 6 bits. And this encoding uses 000 to 999, encoded into 10 bits. But that messes up the title when you compare apples to ap…

The base 10 is referring to conversion of bytes into a long decimal (base 10) integer, not that it's being stored in chunks of 10 bits.

But yes, you're right, it would be reasonable to think of this as encoding the bytes in base 1000, where each "digit" just happens to be shown to humans as 3 digits.

Re: 10 > 64, in QR Codes

#60

Post by klodolph »

zamfi wrote: post #46
pimlottc wrote: post #7

This is really great, I didn't know you could switch encoding schemes within the same QR code. There's a nifty visualization tool [0] that shows how this can reduce QR code sizes. It can determine the optimal segmentation strategy for any string and display a color-code version with statistics. Very nice! 0: https://www.nayuki.io/page/optimal-text-segmentation-for-qr-...

Speaking of visualization...that last figure in this post is super interesting in part because you can actually see some of the redundancy in the base64 encoding on the left, in the patterns of vertical lines. In general, better compression means output that looks more like "randomness"—any redundancy implies there was room for more compression—and that figure makes this quite clear visually!

That’s undoubtedly some redundancy in the underlying data, not in the encoding itself.
Post reply on HN