Заполняющие байты (Padding)
Заполняющие байты — чередующиеся 0xEC и 0x11, которыми QR добивает область данных до ёмкости версии, если сообщение короче; ставятся после терминатора, перед байтами коррекции.
Зачем нужны заполняющие байты
Ёмкость QR фиксирована выбранной версией и уровнем коррекции: под данные отведено строго определённое число байтов. Реальное сообщение почти никогда не совпадает с этим числом ровно. Оставлять хвост пустым нельзя — область данных должна быть заполнена целиком, иначе кодер не сможет корректно посчитать байты коррекции и разложить код по модулям. Пустоту и закрывают padding-байты.
Как добавляются 0xEC и 0x11
Сначала после данных ставится терминатор, затем поток дополняется нулями до границы целого байта. Если и после этого до конца области данных остаётся место, туда пишутся заполняющие байты — строго чередующиеся: 11101100 и 00010001, то есть 0xEC и 0x11. Порядок именно такой: первый недостающий байт — 0xEC, следующий — 0x11, дальше снова 0xEC, и так до заполнения. Значения выбраны стандартом ISO/IEC 18004 не случайно — их битовый рисунок разнородный, что помогает маскированию избегать больших однотонных зон.
Место в потоке
Заполняющие байты завершают именно область данных — они идут после реального сообщения и терминатора, но до проверочных байтов коррекции. То есть код Рид-Соломона считается уже с учётом padding: заполнители для него — такие же данные, как и полезные. При чтении декодер, дойдя до терминатора, знает, что дальше пошёл мусор-заполнитель, и просто его игнорирует. Посмотреть, как код добивается до нужной ёмкости, можно в генераторе QR.
Частые вопросы
Зачем в QR добавляют заполняющие байты?
Чтобы заполнить область данных до конца, когда сообщение короче ёмкости выбранной версии. Незаполненный хвост недопустим: без него нельзя корректно посчитать байты коррекции и разложить код по модулям. Padding-байты закрывают эту пустоту, не неся никакого смысла для читателя.
Какие именно значения у padding-байтов?
Два чередующихся байта: 11101100 (0xEC) и 00010001 (0x11). Первый недостающий байт — всегда 0xEC, следующий — 0x11, дальше опять 0xEC и так до конца области данных. Значения жёстко заданы стандартом ISO/IEC 18004 и не зависят от содержимого кода.
Заполнители участвуют в расчёте коррекции ошибок?
Да. Padding-байты входят в область данных, поэтому код Рид-Соломона считает проверочные байты уже с их учётом — для него заполнители неотличимы от полезных данных. Идут они после сообщения и терминатора, но перед самими байтами коррекции ошибок.
Как декодер понимает, что дальше идут заполнители?
По терминатору. Дойдя до него, декодер знает, что реальные данные закончились, и всё, что идёт следом — выравнивание до байта и чередующиеся 0xEC/0x11 — просто игнорирует. Заполняющие байты никогда не показываются пользователю и не влияют на содержимое.