这里有很多问题我会解决。
首先,您误读了原始条形码的文本,其中包含固定长度的应用标识符 (AI) 字段 (3103)2775 表示净重。
您编写的代码包含无效的(3013)2675。没有 AI (3013),不幸的是,这将与表示项目计数的合法 AI (30) 前缀匹配,该项目计数是一个可变长度字段。因此,解码器将继续读取剩余的数据,直到代码结束进入 AI (30),因为没有后续字段终止符 (FNC1)。那是很多项目——实际上价值超过八位数,所以读者可能会指出错误!
this answer 的“提取”部分提供了有关 GS1 数据如何在 Code 128 条码中编码以生成有效 GS1-128 符号的背景信息。
假设您要对 GS1 数据 (01)08437013308045(3103)2675(15)161201(10)150518 进行编码。
您需要在 Code 128 中编码的原始数据是{FNC1}0108437013308045310326751516120110150518。
推导如下:
- 数据以 FNC1 标志字符开头(表示存在 GS1 格式的数据)。
- AI 周围的括号已被省略。
- 由于您的数据仅包含固定长度的 AI,因此我们无需使用 FNC1 分隔符 [*] 终止可变长度字段。
[*] 请注意,GS1 General Specifications §3.2“按数字顺序排列的 GS1 应用程序标识符”中提供的 AI 列表表明它们是否需要在后跟附加数据时以 FNC1 字符终止。
这些知识如何转化为 TCPDF 的代码?抱歉,我从未使用过它,但这可能会有所帮助:
您的 $codeString 变量需要定义如下:
$codeString = chr(241).'0108437013308045310326751516120110150518';
这假设支持论坛上的链接答案正确地说明了 TCPDF 使用 ASCII 序号 241 来指示 FNC1 字符。 (There is some doubt whether this is the case.) 如果它有效,那么这是一个特定于库的选择,您不应该过多地阅读他们选择值 241 的事实。See here 了解有关编码非数据字符(例如 FNC1)的详细信息。
我还注意到您将C128A 传递给write1DBarcode 的type 参数,这将符号限制为模式A(数字、大写字母和控制字符)。这将非常低效并且可能导致一个符号太宽(或在重新缩放时太密集),无法使用大多数物流应用的标准设备进行扫描。
Code 128 支持模式 C,它提供数字的双密度压缩,因此您应该使用它,可能通过传递 type=C128C 或 type=C128(自动)假设 TCPDF 的自动编码是您认为的任何好的和未来的符号将创建可能需要包含字母。
$label->write1DBarcode($codeString, 'C128', $x, $y, $w, $h);
就条形码下方的人类可读文本而言,如果正确编码的数据无法正确显示,那么您可能需要针对 TCPDF 提出错误报告或功能请求。