Code128 条码规范是否需要校验和？
Is a checksum required in the Code128 barcode specification?
简介
第 1 步
我尝试使用手机条码reader和在线工具读取条码（见下图）并得到它：数据 - 30925018，可视化算法 - 代码128C
第 2 步
然后我尝试从给定的数据生成条形码并得到这些图像：
原始条码
生成条形码
第 3 步
如您所见，图像有所不同。所以，我决定自己解密。这是结果：
原始解密条码
生成解密条码
澄清
正如维基百科所说 (https://en.wikipedia.org/wiki/Code_128):
The check digit is a weighted modulo-103 checksum. It is calculated by summing the start code 'value' to the products of each symbol's 'value' multiplied by its position in the barcode string.
我尝试通过应用程序中的 Java 库和在线工具从给定数据生成条形码。两者都给了我相同的结果。
问题
- 为什么在线工具生成的条码没有校验和，但最后有 FNC1？
- 为什么条码开头有一个FNC1？
- Code128 规范是否需要校验和？
我的想法
- 我认为 GS1-128 规格可能是条码开头的 FNC1 的原因
- 末尾的 FNC1 可以只是一个校验和。纯属巧合
原始图像是 GS1-128（以前称为 EAN-128），表示以下 GS1 应用程序标识符格式的数据：
(30)925018
意思是项目数：925018。
- I think GS1-128 specification can be cause of FNC1 at the beginning of the barcode
正确。根据定义，第一个位置以 FNC1 字符开头的 Code 128 是 GS1-128，因此应包含根据 GS1 规范编码的数据。
以下答案中提供的背景描述了这种编码背后的原理：
- FNC1 at the end can be just a checksum.
校验和在 Code 128 规范（以及任何衍生应用标准）中是强制性的，通常不会显示在任何人类可读的文本中。在您生成的符号中（不是 GS1-128，因为没有 "FNC1 in first"），如果校验和字符恰好与 FNC1 匹配，那只是巧合，尽管 - 正如 Brian Anderson 所指出的那样 - 它没有。
原始条码以FNC1开头。这两个条形码的末尾都没有 FNC1。正如 Terry Burton 所述，开头的 FNC1 表示条码用于 GS1，该代码的数据通常表示为 (30)925018。为第一个条码计算的校验和是右括号的数字 09 或代码 128 字符 ')'。
105
102
30*2 = 60
92*3 = 276
50*4 = 200
18*5 = 90
(105 + 102 + 60 + 276 + 200 + 90) = 833
833 % 103 = 09 (')')
不带 FNC1 的条形码的第二个校验和是数字 26 或 Code 128 字符“:”（冒号）。
105
30
92*2 = 184
50*3 = 150
18*4 = 72
105 + 30 + 184 + 150 + 72 = 541
541 % 103 = 26 (':')
可能校验和等于 FNC1 字符？是的。校验和是对条形码中的元素和数字 103 的加权和进行取模运算的结果，因此任何不超过 102 (FNC1) 的数字都可以是校验和的结果。因为Code 128标准没有对校验和位置的字符（STOP之前的最后一个字符）赋予任何特殊意义，所以无关紧要。
当您尝试破译 Code 128 条形码时，请记住，字符间距是不存在的。字符将具有完全相同的宽度 (11 "dots")，除非它是停止字符（在这种情况下为 13 "dots"）。每个点的宽度与图形成比例。您最好不要忽略每个字符的尾随 "zeroes"。它们很重要。
简介
第 1 步
我尝试使用手机条码reader和在线工具读取条码（见下图）并得到它：数据 - 30925018，可视化算法 - 代码128C
第 2 步
然后我尝试从给定的数据生成条形码并得到这些图像：
第 3 步
如您所见，图像有所不同。所以，我决定自己解密。这是结果：
澄清
正如维基百科所说 (https://en.wikipedia.org/wiki/Code_128):
The check digit is a weighted modulo-103 checksum. It is calculated by summing the start code 'value' to the products of each symbol's 'value' multiplied by its position in the barcode string.
我尝试通过应用程序中的 Java 库和在线工具从给定数据生成条形码。两者都给了我相同的结果。
问题
- 为什么在线工具生成的条码没有校验和，但最后有 FNC1？
- 为什么条码开头有一个FNC1？
- Code128 规范是否需要校验和？
我的想法
- 我认为 GS1-128 规格可能是条码开头的 FNC1 的原因
- 末尾的 FNC1 可以只是一个校验和。纯属巧合
原始图像是 GS1-128（以前称为 EAN-128），表示以下 GS1 应用程序标识符格式的数据：
(30)925018
意思是项目数：925018。
- I think GS1-128 specification can be cause of FNC1 at the beginning of the barcode
正确。根据定义，第一个位置以 FNC1 字符开头的 Code 128 是 GS1-128，因此应包含根据 GS1 规范编码的数据。
以下答案中提供的背景描述了这种编码背后的原理：
- FNC1 at the end can be just a checksum.
校验和在 Code 128 规范（以及任何衍生应用标准）中是强制性的，通常不会显示在任何人类可读的文本中。在您生成的符号中（不是 GS1-128，因为没有 "FNC1 in first"），如果校验和字符恰好与 FNC1 匹配，那只是巧合，尽管 - 正如 Brian Anderson 所指出的那样 - 它没有。
原始条码以FNC1开头。这两个条形码的末尾都没有 FNC1。正如 Terry Burton 所述，开头的 FNC1 表示条码用于 GS1，该代码的数据通常表示为 (30)925018。为第一个条码计算的校验和是右括号的数字 09 或代码 128 字符 ')'。
105
102
30*2 = 60
92*3 = 276
50*4 = 200
18*5 = 90
(105 + 102 + 60 + 276 + 200 + 90) = 833
833 % 103 = 09 (')')
不带 FNC1 的条形码的第二个校验和是数字 26 或 Code 128 字符“:”（冒号）。
105
30
92*2 = 184
50*3 = 150
18*4 = 72
105 + 30 + 184 + 150 + 72 = 541
541 % 103 = 26 (':')
可能校验和等于 FNC1 字符？是的。校验和是对条形码中的元素和数字 103 的加权和进行取模运算的结果，因此任何不超过 102 (FNC1) 的数字都可以是校验和的结果。因为Code 128标准没有对校验和位置的字符（STOP之前的最后一个字符）赋予任何特殊意义，所以无关紧要。
当您尝试破译 Code 128 条形码时，请记住，字符间距是不存在的。字符将具有完全相同的宽度 (11 "dots")，除非它是停止字符（在这种情况下为 13 "dots"）。每个点的宽度与图形成比例。您最好不要忽略每个字符的尾随 "zeroes"。它们很重要。