KDE PIM/KItinerary/Trenitalia Barcode
< KDE PIM | KItinerary
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 | |
21:3 - 22:1 | unknown | 22:1 seems 0 in all samples, the rest varies | |
22:2 - 24:1 | 16 bit uint | train number | could be as little as 14 bits too, no train number > 16k has been observed |
24:3 - 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 |
Open Questions
- there is one sample where the departure and arrival UIC station codes are equal, contrary to what's in the corresponding PDF
- for international destinations the station code does not actually seem to be a valid UIC station code, but there is only one sample to back this up so far