KDE PIM/KItinerary/Trenitalia Barcode: Difference between revisions

From KDE Community Wiki
Line 5: Line 5:
* does not seem to contain signatures, checksums or compression, based on minimal bit pattern changes on adjacent tickets
* does not seem to contain signatures, checksums or compression, based on minimal bit pattern changes on adjacent tickets
* a lot less null bytes when PNR/seat reservation are present (ie. highspeed train tickets?)
* a lot less null bytes when PNR/seat reservation are present (ie. highspeed train tickets?)
* there is a unique, globally sequential ticket number, 2017 in the 600M range, 2019 in the 1B range, which suggests 32bit might be a bit short for this


== Bit Layout ==
== Bit Layout ==

Revision as of 08:45, 11 May 2019

General Observations

  • always 67 bytes
  • exactly for one passenger/leg
  • does not seem to contain signatures, checksums or compression, based on minimal bit pattern changes on adjacent tickets
  • a lot less null bytes when PNR/seat reservation are present (ie. highspeed train tickets?)
  • there is a unique, globally sequential ticket number, 2017 in the 600M range, 2019 in the 1B range, which suggests 32bit might be a bit short for this

Bit Layout

Byte:Bit (MSB) Content Meaning Notes
0:0 - 4:7 0x20 0x14 0xC2 0x08 0x10 header? fixed value in all samples
5:0 - 7:7 date? varies between samples
8:0 - 12:7 null
13:0 - 14:3 0000 0100 0000 fixed values in all samples
14:4 - 17:3 24 bit uint UIC station code of departure
17:4 - 18:2
18:3 - 21:2 24 bit uint UIC station code of arrival
xx bit uint train number
25:0 - 29:7 null
30:0 - 38:7 null if no PNR present, seems to contain seat number?
39:0 -42:7 null
40:0 - 50:7 null if no PNR present, unknown content otherwise
51:0 - 57:7 0x0B 0x65 0x23 0x18 0x40 0xE6 0xC0 fixed in all samples?
58:0 - 58:3 null might be part of the ticket number?
58:4 - 62:3 32 bit uint ticket number
63:4 - 65:7 null
66:0 - 66:7 varies between samples