Dynamic Header Version not supported

[gXLg]

Beim Parsen von einem D-Ticket von Januar 2024, gekauft in der App MVGO entsteht der oben genannte Fehler.

Reproduktion: 1) Scanne Aztec Code mithilfe von ZXing 2) Wandle Hexdump in byte-Array um 3) import org.uic.barcode.Decoder; und Decoder dec = new Decoder(ticket); schmeißt den Fehler.

Stacktrace:

org.uic.barcode.ticket.EncodingFormatException: Dynamic Header Version not supported
        at org.uic.barcode.dynamicFrame.api.DynamicFrameCoder.decode(DynamicFrameCoder.java:66)
        at org.uic.barcode.Decoder.decodeDynamicFrame(Decoder.java:247)
        at org.uic.barcode.Decoder.decode(Decoder.java:218)
        at org.uic.barcode.Decoder.<init>(Decoder.java:69)
        at com.gxlg.db.Main.main(Main.java:11)

[CGantert345]

Handelt es sich um einen UIC barkode? Der DynamicFrame ist der letzte Versuch einen UIC Barkode zu dekodieren, falls das auch nicht funktioniert kommt der Fehler wie beschrieben.

[gXLg]

Es handelt sich um einen in Aztec formatierten UIC-918-9 Code, das ist korrekt

[CGantert345]

?? Wandle Hexdump in byte-Array um ??

ZXing liefert beim Dekodieren ein Result Object, daraus müsste man die rawBytes verwenden. Der Inhalt sollte mit "U_HEAD"... anfangen.

Um weiter zu analysieren bräuchte ich die rawBytes als hex.

[gXLg]

ZXing liefert neben rawData auch einen Hexdump, diesen kann man besser kopieren und speichern, daraufhin kann es leicht mit Java HexFormat.of().parseHex("hex data"); in ein byte[] umgewandelt werden.

Der Inhalt beginnt selbstverständlich nicht mit U_HEAD an, sondern mit bytes, die (laut den PDFs mit UIC-918 Spezifikationen) Version und weitere Daten über den Format liefern.

Das eigentliche U_HEAD ist doch eigentlich in dem komprimierten Segment der RawData zu finden, oder nicht?

[gXLg]

Die Hexdump, die beim Scannen meines Tickets entstanden ist:

f809ccf40c0124df065c03ccd16ff19e17555028ee91515af5c9e40088c90c91d05c4fc740dbeabc7c6ae7e2cc997237da471c9250ccd8fec268c54bffba54150615f55684da5ccb24060a3a16f632b1b80c9898eb32a768fdab05c62c42d7f6308d26cd5e8e3b18df004cf895edf06f8cebee71a314e9ef1d1daead04040a6dbc4062dc801cd02ab222b0883bf90c0e42f9bc0e0479b58fc05d973f226d694ef876a0e08b0aa3f1a7346bf8ea4e2febb3434342f31bad4d7d22aa20d79fe8782829e9d303200c2a78f2829265276a871dc218b091e466f08d58ac6671b00bbafe2f8a426fc7555634bffbeeb93f358faecc293655f69d79e449ad2b9c5ab43d6b1cf701a782509d7cd3fbdbef1554d52bfd58d3ab0ce02a7cf1d4ac8b484cef0df4efb8b1ef0c3900676f67a1b181088da2bb011392264f02d4691dbe9c0659a339fb778acd5d51dc1e9a12e2e6f747c0f14bf372f9c00c0a10414d72dfe3110621f8

[CGantert345]

Die Daten müssten mit der Kennung für den statischen Frame des UIC barcodes beginnen: "#UC", das ist aber nicht der Fall.

[B00tLoad]

Ich habe das gleiche Problem, sowohl mit meinem eigenen Ticket aus dem Dezember, als auch mit einem der Mustertickets der DB.

Beide beginnen in meinem Fall beim auslesen mit ZXing allerdings mit "#UT"

For Reference mein Hexdump Musterticket "Muster 918-9 FV_SuperSparpreisYoung.pdf":

022d5f1219511111277c00b9fda51ed0b375a78bc3828323e47e7d0db221f8de0a5dab50a2400f78547754061cb28278f279669405cd523aad1c0b0b8cf4181ec0e8bc3d90a2787ce6781f5cc0c8c4c5e270072000dffd557ced367c6a4845dc1fc0276c8021b843707a358a0544422041472111e54e98de755aa802a0600220b634bc053b37b71029b1b434b938324b2020888af7c02004316529c55691a906c98715046c3a396bc3cba653d0fcb3d1ca203a837ba39b230b6842237b93a36bab73213ab34b09d101e18981c181f1426a217a129a8152ba7a11495241526a49514212497a7a99526a9948083001a4c38ad5a3613365701300070014b00240661553757065722053706172707265697320596f756e6701040088486646a03fb5cc14

(EDIT: Formatierung)

[CGantert345]

Der Hexdump sieht nicht wie ein Ticket Inhalt aus. Er fängt auch nicht mit #UT an. "022d5f" ist nicht "#UT".

[B00tLoad]

Das kommt so aus ZXing raus tho. (Ich habe allerdings gerade gemerkt, dass es doch nicht das Musterticket ist, sondern eines von mir.)

[CGantert345]

Die raw bytes von zXing passen nicht zum raw text:

Text: #UT = 23 55 54 rawBytes: 02 2d 5f = -_

das wäre eine Frage an zXing. Ich habe keine zXing doku zum Inhalt von Rawbytes gefunden. Ggf. wird der falsche Zeichensatz verwendet oder es sind die Image Daten.

Man kann versuchen den Text über den richtigen Zeichensatz StandardCharsets.ISO_8859_1 zu Bytes zu konvertieren. zXing hat bei großen Aztec Kodes Probleme, Googles ML Kit funktioniert besser.

[CGantert345]

Wenn man sich den zXing code ansieht scheint rawBytes nicht der BarCode Inhalt zu sein sondern die BarCode BitMatrix nach der Anwendung der Fehlerkorrektur. Damit fehlt dort die Decodierung der Aztec character, die für den rawText noch gemacht wird.