Как правильно сгенерировать штрихкод GS1-128 (ранее EAN-128) в TCPDF

Здесь есть ряд проблем, над которыми я буду работать.

Во-первых, вы неправильно прочитали текст оригинального штрих-кода, который содержит поле идентификатора приложения фиксированной длины (AI) (3103)2775 представляющий вес нетто.

Вы написали код, содержащий (3013)2675 который недействителен. AI (3013) не существует, и, к сожалению, этот префикс совпадает с легитимным AI (30), представляющим счетчик предметов, который является полем переменной длины. Поэтому декодер будет продолжать считывать оставшиеся данные до конца кода в AI (30), поскольку нет последующего символа конца поля (FNC1). Это много пунктов — более восьми цифр на самом деле, так что читатель может указать на ошибку!

«Добыча» часть этот ответ предоставляет справочную информацию о том, как данные GS1 кодируются в штрих-коде Code 128 для получения действительного символа GS1-128.

Давайте предположим, что вы хотели закодировать данные GS1 (01)08437013308045(3103)2675(15)161201(10)150518,

Необработанные данные, которые необходимо кодировать в коде 128, {FNC1}0108437013308045310326751516120110150518,

Это было получено следующим образом:

• Данные начинаются с символа флага FNC1 (указывающего на наличие данных в формате GS1).
• Скобки вокруг ИИ опущены.
• Поскольку ваши данные состоят только из ИИ фиксированной длины, не существует случаев, когда нам нужно завершать поле переменной длины символом-разделителем FNC1 ^[*].

^{[*] Обратите внимание, что список AI, представленный в Общие характеристики GS1 §3.2 «Идентификаторы приложения GS1 в числовом порядке» указывает, требуют ли они завершения символом FNC1, когда следуют дополнительные данные.}

Как эти знания переводятся в код для TCPDF? Я никогда не использовал это извините, но это может быть полезно:

Ваш $codeString переменная должна быть определена примерно так:

$codeString = chr(241).'0108437013308045310326751516120110150518';

Это предполагает, что ссылка на ответ на форуме поддержки правильна, поскольку в TCPDF используется порядковый номер 241 ASCII для обозначения символа FNC1. (Есть некоторые сомнения, так ли это.) Если это работает, то это выбор для конкретной библиотеки, и вам не нужно много читать о том факте, что они выбрали значение 241. Посмотреть здесь для получения подробной информации о кодировании символов, не относящихся к данным, таких как FNC1.

Я также заметил, что вы проходите C128A к type параметр write1DBarcode который ограничивает символ режимом A (цифры, заглавные буквы и управляющие символы). Это будет ужасно неэффективно и может привести к тому, что символ будет слишком широким (или слишком плотным при изменении масштаба) для сканирования с использованием большинства стандартного оборудования, используемого для логистики Приложения.

Код 128 поддерживает режим C, который обеспечивает сжатие цифр двойной плотности, поэтому вы должны использовать это, вероятно, передавая type=C128C или же type=C128 (автоматически) при условии, что автоматическое кодирование TCPDF — это любое хорошее и будущие символы, которые вы создадите, могут содержать буквы.

$label->write1DBarcode($codeString, 'C128', $x, $y, $w, $h);

Что касается читаемого человеком текста под штрих-кодом, если он не отображается правильно для правильно закодированных данных, то вам может потребоваться выдать отчет об ошибке или запрос функции для TCPDF.