KDE PIM/KItinerary/Trenitalia Barcode

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		fixed value in all samples, contains the Trenitalia UIC code ("83")
5:0 - 5:2	null
5:3 - 6:3	9 bit uint	issue or travel day	day since Jan 1st, issue day when PNR present, travel day otherwise
6:4 - 7:4	9 bit uint	?	issue day if no PNR is present, a day about 60 days prior to the issue day otherwise??
7:5 - 7:7	null
8:0 - 10:0	null		might be part of CartaFreccia?
10:1 - 13:4		CartaFreccia (trenitalia loyalty program)
13:5 - 14:3	100 xxxx		0000 for Italian stations codes (UIC 83.....), 0111 for international destination?
14:4 - 17:3	24 bit uint	UIC station code of departure	only for Italian destinations apparently
17:4 - 18:2	100 xxxx		see above
18:3 - 21:2	24 bit uint	UIC station code of arrival	see above
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 - 30:5		unknown	null if no PNR present, content unknown
30:6 - 31:1	4 bit uint	coach number?
31:2 - 32:0	7 bit uint	seat number	seat row for trains with an airplane-like numbering scheme
32:1 - 32:2	null
32:3 - 32:6	4 bit uint	seat column as hex number	0 for trains without an airplane-like numbering scheme
32:7 - 33:6	null?
33:6 - 38:2	6x6 bit as listed below	PNR	all null if ticket has no PNR, values map to digits/letters as follows: 0-9 -> 0-9, 10-35 -> A-Z
38:3 -43:3	null
43:4 - 44:2	1010 011 or null	issuer or carrier UIC code	only set if PNR is present, "83" for Trenitalia tickets otherwise, a few preceding bits are likely part of this fields as well
44:3 -45:6	null
45:7 - 50:2	6 x 6 bit uint	"Codice CP" (CP code)	Each uint is a digit of the code
50:3 - 50:7	null
51:0 - 51:3	0x0 or 0x8		0x0 when seat reservation/PNR present, 0x8 otherwise
51:4 - 57:7	0xB 0x65 0x23 0x18 0x40 0xE5 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:6	null
65:7 - 66:7	9 bit uint	issue day	number of days since Jan 01 (same as 5:3-6:3 if PNR is present)

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
• It seems plausible that the coach number is also encoded given the seat number is, 30:0 - 31:1 would seem like the obvious range. In the sample data this does not seem the case with any obvious encoding (In my 6 tickets, the 4 bits [30:6 - 31:1] correspond to the coach number, but that might be a coincidence. Drdanz (talk))
• Is the train type derived from the train number, or is that also encoded? 21:3 -22:1 would seem to be the obvious range for that, but so far no correlation to current samples found.
• Is the class encoded somewhere? (could be [30:4 - 30:5]? or maybe [56:5 56:5]?). From 2 tickets, same route, same hour, same day, different "0ffer - Service" (ECONOMY-1a Class vs BASE-2a Class) comparing the two barcodes, after extracting all known information, the only unknown bits in different bytes are: [7:1 - 7:7] (1st class 0001000, 2nd class 0101000) and [66:0 66:7] (1st class 11110101, 2nd class 11111001), perhaps [66:4 - 66:5]?
• Date/time encoding is still a mystery. (In my tickets for the same route in different consecutive days, the only different bytes are [31,32] (Seat + null), [47,48,50] (CP Code + null) and [62] (Ticket number + null), meaning that the date might not be there, or be encoded in the CP Code. In return tickets for the same route also [15,16,17] (UIC station code of departure + 100 xxxx), [19,20,21] (UIC station code of arrival + *unknown*), and [23,24] (Train number + null) are different, therefore the remaining information can be encoded only in [21:3 - 21:7], which for all my ticket correspond to the departure time hour, but I couldn't find the minutes anywhere and it could be a coincidence Drdanz (talk)). (On a different sample this field is the departure time hour+1, perhaps departure time h? if minutes <= 30; departure time +1 if minutes > 30 Drdanz (talk))
• What is the "CP Code" (Encoded in 45:7 - 50:2): Last digit (or 2 digits) might be an incremental number in digits in the same purchase