这个问题不是关于“最佳” barcode库推荐的问题，我们在不同的平台上使用各种产品，并且需要一种简单的方法来验证给定的条形码是否正确(根据其规范)。
我们发现了互联网上不同条形码库和free online barcode generators对条形码进行不同渲染的情况。例如，新发布的Delphi报告库将在Code128中将非数字字符输出为“0”，或者仅在文本区域中跳过它们。在进行迁移之前，我们要检查这些更改是否是由于新库中的实现错误导致的，因此我们可以将其作为错误报告给作者。
我们主要需要带有A/B/C子代码的Code128和UCC/EAN-128。
到目前为止，我检查的在线资源是:
它们也显示出不同的结果，例如至少在人类可读的文本中支持逗号或加号之类的字符。
最佳答案
对于Code128，没有一个正确的答案。如果使用Code128-A，则可获得与Code128-C不同的结果。结果是我的意思是它的外观。以“803150”为例。在Code128-A中，您将需要6个字符(+，开始，校验和，停止)来表示该数字。 Code128-C仅包含数字，因此您可以将两位数字压缩为一个字符。因此，您只需要3个字符(+开始，校验和，停止)即可代表相同的数字。条形码看起来会有所不同(在这种情况下，A会更长)，但是如果您扫描它们，它们都会给出正确的数字。
此外，Code128不必只是A，B或C。您实际上可以组合不同的子集。这对于“US123457890”这样的情况很常见，其中在“US”上使用Code128-A或B，在其余数字上使用Code128-C。有时将其称为Code-128自动，或简称为Code-128。结果是宽度上的“压缩”条形码。您可以用A/B表示相同的数据，但同样会给您更长的条形码。
拿两个在线生成器:
我推荐第一个，您可以在其中选择自动/A/B/C。这是说明差异的示例图像:
在IDAutomation上，“默认”为“自动”，而在“条形码”中默认为A。两者都是正确的，您只需要在比较输出时注意选择了哪个子集即可。我还建议在开发中使用条形码读取器来测试输出。另外，请参见this page，以将不同子集与ASCII值进行比较。我还发现grandzebu.net很有用，它也可以使用免费的Code128字体。
听起来您的Delphi库始终使用Code128-C，因为只能在此子集中表示数字。