我正在尝试验证使用 ZXing 或 ZBar 扫描的 GS1 条形码。这GS1 一般规格 http://www.gs1.org/docs/gsmp/barcodes/GS1_General_Specifications.pdf7.8 中说 GS1 条形码
必须使用特定的符号标识符进行传输：
-
]C1= GS1-128
-
]e0= GS1 DataBar 和 GS1 复合符号
-
]d2= GS1 数据矩阵
-
]Q3= GS1 二维码
但 ZXing 只显示 Code 128 的符号标识符（带或不带）--gs1），其余的不做。
ZBar 根本不显示符号标识符。
我对规范的理解是否正确？
有没有办法用 ZXing 或 ZBar 从条形码中提取这些标识符？
通常的手持式扫描仪会查看这些符号标识符吗？
您对规范的理解确实是正确的。这些库不遵循“FNC1 在第一位置”所需的传输协议，即 GS1 模式。
条形码符号标准是规定性的：修改后的 AIM 符号标识符的传输是通用 ISO 符号标准的强制性部分，而不仅仅是 GS1 应用标准。
这些单独的标准没有尝试描述传输协议运行的总体框架，让读者根据不完整的情况猜测某些决策的原因。此外，由于历史原因，这些标准预设了一种假设情况，其中条形码读取器通过物理字节模式接口连接到主机。
手持式扫描仪通常可以配置为发出 AIM 符号标识符（或某些专有等效标识符）作为传输消息的前缀，并且通常会严格遵守规定的传输协议。
然而，典型的解码器开发人员现在正在为既托管最终用户应用程序又包含集成摄像头的设备编写库，因此执行传输协议的“线路”是不存在的。开发人员忽略意图不明确的标准的基本特征是可以理解的，但这样做会在解码某些类型的数据时产生歧义。
某些类型的数据（例如 GS1 应用标识符语法）需要显式激活标志，该标志通过修改 AIM 符号标识符来规范地发出信号。除了识别扫描条形码的通用格式之外，解码器库的 API 很少提供对符号标识符指示的功能的完全替代。例如，设备 API 通常缺乏 GS1 模式和 ECI 协议扩展的信令。
一个相关问题是解码器库经常忽略将条形码消息的第三个及后续字符位置中的 FNC1 字符作为 GS（ASCII 值 29）发送，从而无法解码 GS1 AI 语法消息。更少的图书馆在 QR 码符号中传输“%”字符，其中 GS1 模式被激活为 GS。这些实现根本不符合符号标准。
ZXing 到 C++ 的端口 (zxing-cpp) 的维护者正在积极与条形码标准制定社区合作，以确保正确遵守符号标准。因此，ZXing（Java）以及包装器和绑定生态系统应该会在适当的时候从这些改进中受益。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
