Hacker News new | ask | show | jobs
by KGIII 3189 days ago
I am not a lawyer, but I think most of the author's actions would be considered illegal in the US. While he didn't do any harm, his actions were still probably a violation of at least the CFAA.

Anyhow, Aztec code? It looks, the one on the watch, pretty much like a QR Code. I've never seen the Aztec code before today. It makes me wonder how many of these barcode things we really need. A quick Google didn't reveal any information demonstrating why this Aztec code is any better than the other options out there.

It does make me grateful that I don't have to work on implementing all these things or, really, even deal with them. I know a bunch of you are developers and I hope you're not the ones stuck with dealing with all these different 'standards,'

1 comments

Aztec is more compact than QR - does not need margin and because it's optimised for lowercase letters (used a lot for urls). Also has tunable error correction.
Doesn't the QR standard allow lowercase via hex and have a miniature version? I know it has error correction, but I'm not sure if it is tunable. I know it can embed kanji, so it seems odd that lowercase would be much of a problem?

Thanks!

I am pretty grateful I'm not tasked with implementing these.

It's not that lowercase is a problem, it's that aztec is more efficient at it.

Note that GP is incorrect that you need lowercase to express URLs and qrcode has an "alphanumeric" mode (based around uppercases which works fine), but even then qrcode's alphanumeric mode is slightly less efficient as it needs 5.5 bits per character versus 5 for Aztec.

Kanji has its own qrcode encoding mode (the qrcode encoding modes are numeric, alphanumeric[0], byte, kanji, structured append[1], ECI[2] and Code128[3]).

[0] digits, uppercase ascii letters and 9 symbols

[1] to split messages across multiple codes

[2] additional "local" encodings: https://strokescribe.com/en/ECI.html

[3] https://en.wikipedia.org/wiki/Code_128

I don't really like HN for the links. I can find those anywhere.

What I do like about HN is the comments. Someone here usually knows what they are talking about and can explain it well.

Thanks!

QR codes have variable-level error-correction, from 7-30%.

https://en.wikipedia.org/wiki/QR_code#Error_correction

Thanks! As mentioned above, I am so glad I'm not one of the folks who has to implement this stuff.

I'd ask why they didn't just improve QR codes, instead of making yet another format, but I'm not sure I want to know the answer(s).

> because it's optimised for lowercase letters (used a lot for urls).

Case does not matter for URLs, HTTP://NEWS.YCOMBINATOR.COM will work perfectly, and can be encoded using qrcode's alphanumeric mode.

Aztec is slightly more efficient regardless, but not by much: qr alpha is 5.5 bits symbol, Aztec is 5 bits per symbol.

However, https://news.ycombinator.com/REPLY?id=15319423 does not work. Domain names are fine, because DNS is case insensitive in the ascii region by specification; I don't know about punycode for Unicode domain names. Paths beyond the domain name are expected to be case sensitive, but may be insensitive depending on the server environment (windows servers usually would be insensitive when serving files, Yahoo servers have a plugin to lowercase everything in the path to help with people typing in urls from offline media where users or publishers may not be very careful.
Case doesn't matter for the protocol or domain name but it does matter for the rest of the URL.
Oh you already commented that. (Deleting my comment)
QR also has tunable error correction.
qrcode has tunable error correction (7, 15, 25 or 30% recovery via reed-solomon).