@ Ben 11 [#314]

Sehr seltsam!

beim Sichten meines Materials und Bilderstichproben von ebay habe ich diese Abweichung nirgends gesehen. Am besten also, Deinen Bogen gut aufheben und nicht verbrauchen. ;-)

Wenn man sich die 49 nutzbaren Datenbytes ansieht, hat man ja bei den drei Ausreissern folgendes Bild:

- Die ersten Bytes DEA500 sind noch in Klartext, also noch nicht in Base256, codiert - das ist erst einmal ok (wie gesagt, machte das Bagel auch schon mal)

- Bei der ID, die dann kommt, macht eigentlich nur eine Base256-Codierung Sinn, weil ja hier theoretisch in jedem Byte jedes der 256 Zeichen vorkommen kann - Byte7+8 sind aber noch nicht in Base256!

- In Byte9 dann die Umschaltung, bei der Byte 10 sagt, dass dies 38 Zeichen lang gilt.

- In Byte 11-48 ist alles wie gewohnt in Bas256-Codierung, aber alles kommt 1 Byte früher als bei anderen Marken.

- Am Schluss wäre noch Byte 49 verfügbar. Aber da steht eine 129, was einem Padding-Zeichen entspricht und besagt, dass dieses Zeichen keine Daten enthält.

Für die ID 0x1C3237 wären also eigentlich 3 Byte nötig, man hat aber nur noch Byte 7+8 übrig:

Byte 7: Rohwert 29, wird als ASCII-Wert 28 interpretiert, was man auch 0x1C schreiben kann

Byte 8: Rohwert 157, wird als Zahl 27 interpretiert.

Bei den anderen beiden Marken ist der Rohwert von Byte 8 154 bzw. 151, d.h. das kann evtl. den ID-Abstand von 3 widerspiegeln, generell ist es aber myteriös, wie man 3 Byte durch 2 Byte kodieren kann...

Es ist auch eher nicht der Fall, dass hier eine geheime DeutschePost-Spezial-Codierung vorliegt. Denn wenn ich den Code dem (eigentlich von der Post unabhängigen) Online-Tool [1] übergebe, erkennt er die enthaltenen Daten genauso wie bei den anderen Codes.

[1] https://online-barcode-reader.inliteresearch.com/