search

openfoodfacts / openfoodfacts-cordova-app-old-with-blob

Open Food Facts App in Cordova (Android)
Other
83 stars 48 forks source link

Some barcodes are scanned with an extra leading zero #25

Closed HummingBrid closed 9 years ago

HummingBrid commented 9 years ago

Some barcode, for example: http://world.openfoodfacts.org/product/055742357653/cottage-cheese-compliments http://world.openfoodfacts.org/product/060383998622/milk-chocolate-with-hazelnuts-pc http://world.openfoodfacts.org/product/060383042400/dark-chocolate-no-name

were originally scanned with an extra leading zero, that does not actually appear on the barcode. the result is that products added with the phonegap app cannot be found by the native app.

TaciteOFF commented 9 years ago

That's not an issue, it's perfectly normal.

If you scan these barcode with another app/tool, you'll find the same result.

Manufacturers don't have to write every digit of the barcodes, the important thing is that their barcode format has 13 digits.

(NB: In the examples you provided, I can see the all the digits written on the label, for the dark chocolate for instance you can read "0 6038304240 0")

HummingBrid commented 9 years ago

let me rephrase the bug: the inconsistency of scanning barcodes causing products not to be found! for example, if in the db a product is stored under "0 6038304240 0", it WILL NOT be found by the phonegap app, which reads that same barcode as "00 6038304240 0"! Moreover, if a product is saved as "00 6038304240 0" by the phonegap app, it WILL NOT be found by the native android app.

In other words, while the leading zero inconsistency may be "normal" for a person reading the label, the apps currently do not handle this discrepancy properly.

TaciteOFF commented 9 years ago

Got it. I must admit I never experienced this on the iPhone version. I'll let the devs find a workaround for this. It's obviously an app problem. Thanks for reporting the issue!

stephanegigandet commented 9 years ago

We could try to normalize barcodes and add/remove leading 0 so that codes conform to the EAN-13 standard. Is there any risk for a collision of two barcodes that differ only by a leading 0?

Related: bug 141 https://github.com/openfoodfacts/openfoodfacts-server/issues/141 cc @itchix

HummingBrid commented 9 years ago

I actually think the real problem is that the DB query is sensitive for a leading zero. Wouldn't it make more sense to fix it on the db side? And what about "y2k" style issues? i.e. for how long 13 digits would suffice?

stephanegigandet commented 9 years ago

Right by normalizing, I mean normalizing everywhere, including the database.

Y2K-style issues: we'll let GS1 figure that one out, and we'll use whatever id we can find on products.

stephanegigandet commented 9 years ago

All valid UPC codes with 12 digits are now normalized to the corresponding EAN-13 (with one extra leading 0). The normalization has been done on all existing products, and it is done for new barcode scans, API calls etc.

URLs with old codes are 301 redirected to URLs with the new codes.

On the web site, when the code is a EAN-13 with a leading 0, we also display the corresponding UPC code without the leading 0.