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

21–30 of 83 posts

Re: 10 > 64, in QR Codes

#21

Post by chrisfinazzo »

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…

To play devil’s advocate for a moment…

Wouldn’t this break Deep/Universal links which send a user directly to a specific location within an app?

I get that there are potential security/privacy concerns, but if you are in full control of URL schemes, isn’t that purpose of this feature?

Re: 10 > 64, in QR Codes

#22

Post by planede »

For dealing with larger data I would probably split the input bits into 63 bit chunks, which can be encoded in 19 decimal digits. 63 input bits turn into 19 digits which in turn is encoded in 63.33... output bits on average. This has an overhead of 0.53% instead of 0.34% of pure base10, which I think is acceptable. But then you don't have to bring bignum libraries into the picture, as each chunk fits into a 64bit integral type.

64bit chunks are a little bit worse, with 4.16% overhead, so it might be worth dealing with the little complexity of 63 bit chunks.

I would also output the decimal digits in little-endian order.

edit: If you are willing to go for larger chunks then 93bit chunks would be my next candidate, there the overhead is 0.36%, barely more than pure base10's 0.34%. I don't think it's worth going any higher.

Re: 10 > 64, in QR Codes

#23

Post by sfmz »

ptramo wrote: post #19
sfmz wrote: post #17

I 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)) So you can point to Demo " rel="nofollow">https://srv.us/d# Demo

Almost, page doesn't have a body yet, so you get a null ref. I thought of spinning it up or hosting on ipfs, but it still won't live forever, somebody will lose interest and stop paying the DNS costs or similar.

Re: 10 > 64, in QR Codes

#24

Post by ptramo »

sfmz wrote: post #23
ptramo wrote: post #19

Earlier quoted context omitted.

Good idea. Built https://srv.us/d that does (edited): document.body.innerHTML = decodeURI(window.location.hash.substring(1)) So you can point to Demo " rel="nofollow">https://srv.us/d# Demo

Almost, page doesn't have a body yet, so you get a null ref. I thought of spinning it up or hosting on ipfs, but it still won't live forever, somebody will lose interest and stop paying the DNS costs or similar.

Fixed, thanks! Yes, longevity is an issue with anything online. On the other hand, in this case recovery is not a huge issue for anybody technical enough.

Re: 10 > 64, in QR Codes

#26

Post by buildsjets »

I need to re-run the math based on this info, but a while back, I wanted to figure out the maximum density of QR codes that could be reliably printed on a sheet of plain paper with a laser printer, then optically scanned and re-digitized. I recall the answer was about the same as a double-density 5.25" floppy disk, which is 320kb.

Re: 10 > 64, in QR Codes

#29

Post by PanMan »

Cool article. What I've wondered, and the article doesn't touch on: In "normal" usage (not damaged QR codes), what's the best error correction to use, with a fixed output size (eg a sticker)? Using a higher level, results in more bytes, and thus a larger QR, which, when printed, results in smaller details. Is it better to have a low error correction, resulting in large blobs, or to have higher error correction, resulting in smaller details, which I guess will be harder to scan, but more room for correction?

Re: 10 > 64, in QR Codes

#30

Post by master-lincoln »

PanMan wrote: post #29

Cool article. What I've wondered, and the article doesn't touch on: In "normal" usage (not damaged QR codes), what's the best error correction to use, with a fixed output size (eg a sticker)? Using a higher level, results in more bytes, and thus a larger QR, which, when printed, results in smaller details. Is it better to have a low error correction, resulting in large blobs, or to have higher error correction, resul…

I guess this is a trade off that depends on your use case: from which distance does the qr code need to be scannable, what cameras do we expect to be used for scanning, how likely is what kind of damage to parts of the qr code, ...
Post reply on HN