EAN and GTIN 8 issue

Just downloaded the script this morning and spent most of the day testing it for production on our site. Here are my initial bugs report.

1) I Have a EAN 0843163050105, it is being returned as a GTIN-14. Obviously, this is a EAN since it has 13 digits.

2) GTIN-8s are not properly validated unless put in GTIN-14 format. Example:

GTIN-8: 12345670, it returns FALSE/BAD UPC. But if I enter it in GTIN 14 format like so: 00000012345670, it comes back as a valid GTIN-8.

All this barcode data I am confirmed directly from GS 1 for absolute validity.


gs1.org/barcodes/support/check_digi ...

I run a web site that catalogs everyday items via barcodes, so we are quick to find any issues with a barcode validating script. Other than that, this works really nice. Major thanks to the creator!

Just solved GTIN-8 issue. In class script, on line 16, it said this:
if($length > 11 && $length <= 14)

I made it:
if($length >= 8 && $length <= 14)

Of course, this means that invalid barcodes with 9 and 10 digits will go through the process. I tried made up 9 and 10 digit barcodes, they all failed, as they should. But perhaps it would be better if we write if statement to exclude 9 and 10 digit barcodes in case they can actually return true statement?

Thanks for your comment.

I use this class for last 3 years now and recently I have added GTIN-14.
EAN and UPC are oldies and will eventually be replaced by GTIN-14.

All EAN, UPC, JAN, EAN-8 and others can be converted to GTIN-14 by adding zerro's.
GTIN-14 is not very common at this moment EAN and UPC are the most common bar codes. The best way of storing the bar codes in a database is to store them all as 14 digit strings (GTIN-14). You are then future proof.

I am now rewriting my library class to make it more usable worldwide, I will change the name to clsLibGTIN.php and make an extra function to output GTIN-14 if preferred (for database storage).

I will do my best to rewrite it in a few days.

For more information about GTIN and it's developments you cold visit:
gtin.info/
gs1.org/barcodes/support/check_digi ...

I have looked in your example 1 (EAN 0843163050105):
This is not really an EAN code to be correct this is an UPC code, this can be seen by prefix numbers.

You can see from the prefix number where the company who made the product register the bar code (not saying anything about the country where it has been made).

If you make a number 13 digit the first 3 digits makes the prefix number, you can find here where the numbers where assigned: http://www.gs1.org/barcodes/support/prefix_list

084 GS1 US
This makes it an UPC bar code what should be probably right knowing that Blackberry is a Canadian company and there the use UPC.
On the box there is probable the following bar code: 843163050105
You can make it an EAN code by adding an extra zerro.

So this is a nice example how complex it is.
What you could do is display all options on your website cause none of them are wrong:
UPC: 843163050105
EAN-13: 0843163050105
GTIN-14: 00843163050105

I myself only use GTIN-14 in my product feed I send Google daily for Google Shopping. They recognize GTIN-14 also if others are still using EAN or UPC (with GTIN-14 you are future proof)

Yes, I agree with you that GTIN-14 is the future and one should start saving GTIN as GTIN 14 into database.

A little about me, I co-run the world's biggest (and only) website dedicated to everyday items NOT made in China. We only accept items that have a GTIN:

pnmic.org/how-it-works
pnmic.org/search/?q=&category=Any-C ...

How this works is that everyday people submit items to the database. Depending how they enter the GTIN, it could be either this 044357002225 or this 0044357002225. Both ways as you already know, are valid.

However, here in America, we use UPC-A (12 digit GTIN) and are very slow to implement GTIN 14 format. So for the foreseeable future, we must cater to legacy barcodes such as UPC-A, EAN and 8 digit barcodes. Not just because that is how people are accustomed to reading barcodes, but a lot of production scripts still operate on the above format. Example:
codecanyon.net/item/ultimate-barcod ...

No GTIN support, so it must be told what type of barcode is sent to it so it can printout proper barcode graph. Example:
pnmic.org/Saunders-Portable-DeskTop ... (UPC)
pnmic.org/Sistema-460ml-Squeeze-Bot ... (EAN)

In a perfect world, we can store barcode as GTIN 14 format, but when showing for barcode, be able to tell if it is legacy code such as EAN, UPC, or EAN-8. I believe your latest script does that accurately now?

Your old script, while it was precise and accurate in validating barcode checksum, it had hard time returning EAN or UPC. Most times I got GTIN 14 for what is clearly a 12 digit UPC. Example:
pnmic.org/Organic-Miswak-Power-Toot ...

This is the old script, that had EAN in its name. The new one sees this as a UPC. I think the old script just did not like UPC's that did not begin with 0...

I'll be testing the new script tonight and let you know if I find any bugs. In the mean time, I used and still use, a JavaScript script that's able to differentiate between legacy codes such as EAN, UPC, EAN-8, even GTIN-14, and validate them. I have it up here as plain text if it has any benefit to you:
proudlynotmadeinchina.org/js.txt

So let's stay in touch!

BTW, good call on renaming it to ...GTIN!

Dear Lyod Johnson,

Are you still using the script?
Did you find any bugs in the last version or is everything working now?

The script got nominated for inovation award of the month, if you like it please vote for it.
Thanks in advance.

Kind regards,

Ferry Bouwhuis

So far so good. Will be doing more testing later in the week. Very happy you got nominated! I've been waiting for exactly this script for about 2 years. You got my vote!!!