存储 GUID 的最有效条码

Most efficient barcode to store a GUID

我目前正在开发的系统要求用户登录系统,而客户希望使用条形码扫描仪和卡片来降低价格。 (是的,用户名和密码更便宜,但她想要一个卡式解决方案,所以她得到了一个。)

我的所有数据都使用 GUID 作为关键字段,因此我想将 GUID 直接存储在卡上的条形码中。虽然它很简单,可以将其编码为 9 个中的 3 个,但它不会是 space 的最有效使用。

在条形码中存储 GUID 是否有最佳实践或最有效的方法?我曾假设,由于数据的长度和深度一致,因此会有一个标准,但我找不到它。很容易生成我自己的 - 控制字符的两端,然后是二进制数据,但希望标准读者知道如何解释的东西。

感谢收到的任何帮助。

没有针对通用线性条码(例如 Code 39 和 Code 128)的专用数据压缩的开放标准。大多数 ISO/IEC-standardised 二维条码确实支持称为扩展通道解释的专用数据编码机制( ECI),它允许您指定数据符合特定的应用程序标准或编码机制,例如用于 IPv4 地址压缩的 ECI 298765 [*]。不幸的是,GUID 压缩不在已注册的那些之中,即使它是您仍然需要在您的应用程序中处理它,因为 reader 支持将缺乏。

这让您不得不将 GUID 预编码(并随后解码)为某种格式,以便某些普遍存在的条形码符号系统可以有效处理。

存储 GUID 的一种有效方法是将其转换为 40 位数字[†] 十进制表示,并使用双密度将结果存储在 Code 128 条形码中数字压缩(“模式 C”)。

例如,考虑 GUID:

cd171f7c-560d-4a62-8d65-16b87419a58c

用十六进制数表示:

0xCD171F7C560D4A628D6516B87419A58C

转换为 40 位十进制数字:

0272611800569275698104677545117639878028

在 Code 128 条形码中编码:

您的应用程序当然需要将此输入识别为十进制编码的 GUID 并反转上述过程,但我怀疑是否存在不需要您将数据转换为不寻常的基数的更有效的方法然后处理在扫描时处理 ASCII 控制字符的复杂性。

[*] 已分配的 ECI 代码的寄存器可从 AIM 商店以 "ECI Part 3: Register".

的形式获得

[†] 虽然可以在 39 位数字内存储整个 GUID 范围,但 39 位模式 C 代码 128 符号实际上比 40 位符号长。