Thema: Delphi EAN128 mehrdeutig ?

Einzelnen Beitrag anzeigen

alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#7

Re: EAN128 mehrdeutig ?

  Alt 14. Nov 2007, 13:48
Hi, wir haben uns jahrelang mit der Materie beschäftigt. Das bedeutet nicht, das wir die volle Ahnung haben, sondern nur, das wir in so ziemlich jede Falle getappt sind.

Eins vorneweg: Es gibt keine 100% sicheren Barcodes. Sehrwohl gibt es richtig schlechte (Interleaved 2 of 5) und ziemlich gute (Code 128). Mit den EAN Codes haben wir nie gearbeitet, weil die wohl eher in der Lebensmittelindustrie zuhause sind. Soweit ich mich erinnere, ist bei den Dingern aber die 2.Hälfte des Codes spiegelbildlich zur 1.Hälfte. Weiterhin ist das zu kodierende Datenformat geregelt, so mit Hersteller-ID, Preis und so. Genau weiss ich das aber nicht.

Wir hatten eine Anwendung in der Industrie, bei der Werkstücke beim Anlegen an Maschinen eingescannt wurden. Der Kunde wollte die Software nicht abnehmen, weil die Daten nicht 100%ig korrekt in der DB waren. Wir sind auf Fehlersuche gegangen und haben dabei eben festgestellt, das es zu Fehllesungen kommt. Meistens, oder eigentlich fast immer verweigert der Scanner dann bzw. schickt gar nichts, weil z.B. die Prüfsumme nicht stimmt. Aber sehr selten kamen eben die Daten trotzdem durch, und waren Murks.

Wir haben dann weitere Konsistenzprüfungen eingebaut und so den Fehler gegen 0 gedrückt. Aber er ist immer noch vorhanden, nun jedoch im Bereich von 1:500000 oder noch geringer, fällt also nur bei genauer Analyse auf.

Wenn Du also
1. Einen guten Barcode verwendest (Code 39, Code 128)
2. Die Prüfsumme einbaust
3. Gute Scanner besorgst
und
4. Die gescannten Daten noch auf Plausibilität prüfst (Artikelnr muss existieren o.ä.)

Dann kannst Du ein 'eigentlich 100% Sicher' als Qualitätsmerkmal angeben.

@hoika: Stimmt, der ITF2of5 hat keine Start/Stop-Sequenzen (Bits sind das nicht, sondern eher Zeichen). Dafür stellt man i.a. eine konstante Datenlänge ein (muss gerade sein). Wenn der Scanner schräg auf den Barcode trifft, würde er sonst u.U. nur die ersten paar Zeichen lesen, die aber dafür richtig. Damit wenigstens das erkannt wird, kam man auf den banalen Trick mit der festen Datenlänge. Bei ITF sind Fehllesungen im Bereich von 1-3% zu erwarten.

Ach, eins noch: Die Scanner dekodieren natürlich anhand der unterschiedlichen Strick- und Zwischenraumstärken. Wenn man nun einen Barcode ziemlich klein (oder auf nem Matrixdrucker) ausdruckt, und der Renderer nicht darauf achtet, das die Balken immer genau die gleiche Dicke haben (z.B. dünne immer 2pxl, dicke immer 4pxl), dann hat man einen Barcode, der toll aussieht, mit dem aber die meisten Scanner nicht klarkommen, weil eben dünne Striche nicht immer gleich dünn sind. Die Toleranz (was ist dick? was ist dünn?) ist relativ eng gehalten.

Schaut Euch also die gedruckten Barcodes unter einer Lupe an und zählt die Pixelbreiten der Balken. Jaggies, also unscharfe Kanten sind auch sehr beliebt. Am besten, man bastelt sich eine S/W-Bitmap und vergrößert die um eine ganze Zahl. Dann bekommt man saubere Barcodes.
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat