Один SVG: при 640 пикселях QR не читается, при 320 читается. Разбираю, как локатор принял часть подписи за угол кода, почему удаление букв возвращало чтение и как удалось оставить подпись на месте. С контрольными опытами и исходниками.

Два QR одинакового размера, одна строка и пять блоков вместо шести. С виду оба исправны, но из одного два декодера не смогли извлечь ничего. Восстанавливаем опечатку, разбираем её путь через кодировщик и проверяем, почему даже успешное чтение не доказывает правильность QR. Шесть иллюстраций, 160 сочетаний версии и уровня коррекции, 960 сравнений с Nayuki и код эксперимента для самостоятельного запуска.

Браузерный сканер штрихкодов упирается в развилку: чтобы показать, что за товар в руках, надо сходить в товарный API — и отдать туда номер, IP и время. По одному запросу это ничего, по потоку — фактический чек, собранный чужими руками.

Второй путь: скачать базу один раз, порезать на файлы по префиксу и раздавать статикой. Разбираем, что из этого вышло на 32 772 товарах: 1387 шардов, 1,85 МиБ сырых и 429 КиБ в brotli, худший файл 331 КиБ. И главное — сколько приватности при этом всё равно утекает: запрос к серверу есть, а медиана строк в шарде равна единице, то есть для 722 файлов из 1387 запрос за шардом равен запросу за товаром.

Внутри: фильтр на входе, почему не одним файлом, TSV против JSON с замерами, и что в схеме до сих пор не решено.

У EAN-13 есть контрольная цифра, и из этого обычно делают вывод: раз проверка сошлась, номер прочитан верно. Вывод неверный. Я получил с одной книги три разных номера, и все три контрольную цифру проходят. Разбираю, почему так выходит, почему у QR такой беды нет и что с этим делать — с кодом, замерами и таблицей, откуда взялась каждая цифра.