Is a checksum required in the Code128 barcode specification?

Question

Introduction

Step 1

I tried to read the barcode (see image below) using a mobile barcode reader and online tools and got it: data - 30925018, visualization algorithm - Code128C

Step 2

Then I tried to generate a barcode from given data and got these images:

Original barcode

Generated barcode

Step 3

As you can see, the images are different. So, I decided to decrypt it by myself. Here is the result:

Original decrypted barcode

Generated decrypted barcode

Сlarifications

1. As Wikipedia says (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.

2. I tried to generate barcode from the given data by Java libs in my application, and by online tools. Both gave me the same result.

Questions

1. Why do online tools generate barcodes without a checksum, but with FNC1 at the end?
2. Why there is a FNC1 at the beginning of the barcode?
3. Is a checksum required by Code128 specification?

My thoughts

• I think GS1-128 specification can be cause of FNC1 at the beginning of the barcode
• FNC1 at the end can be just a checksum. It is just a coincidence.

Answer 1

The original image is a GS1-128 (formerly EAN-128) representing the following GS1 Application Identifier formatted data:

(30)925018

The meaning is Count of items: 925018.

• I think GS1-128 specification can be cause of FNC1 at the beginning of the barcode

Correct. By definition a Code 128 beginning with an FNC1 character in first position is a GS1-128 and should therefore contain data encoded according to the GS1 specification.

The background provided in the following answer describes the principles behind this encoding: https://stackoverflow.com/a/31760872/2568535

• FNC1 at the end can be just a checksum.

The checksum is mandatory in the Code 128 specification (and any derivative application standards) and is not normally displayed in any human-readable text. In your generated symbol (not a GS1-128 since there is no "FNC1 in first") it would just be a coincidence if the checksum character happened to match FNC1, although - as noted by Brian Anderson - it doesn't.