KDE PIM/KItinerary/Trenitalia Barcode: Difference between revisions
Appearance
< KDE PIM | KItinerary
No edit summary |
|||
Line 66: | Line 66: | ||
| 51:0 - 55:7 57:7 || 0x0B 0x65 0x23 0x18 0x40 || || fixed in all samples? | | 51:0 - 55:7 57:7 || 0x0B 0x65 0x23 0x18 0x40 || || fixed in all samples? | ||
|- | |- | ||
| 56:0 - 56:7 || 0xE5 or 0xE6 || || | | 56:0 - 56:7 || 0xE5 or 0xE6 || || | ||
|- | |- | ||
| 57:0 - 57:7 || 0xC0 || || fixed in all samples? | | 57:0 - 57:7 || 0xC0 || || fixed in all samples? | ||
Line 74: | Line 74: | ||
| 58:4 - 62:3 || 32 bit uint || ticket number || | | 58:4 - 62:3 || 32 bit uint || ticket number || | ||
|- | |- | ||
| 63:4 - 65: | | 63:4 - 65:6 || null || || | ||
|- | |- | ||
| | | 65:7 - 66:7 || || || varies between samples, <s>same as 6:4 - 7:3</s> same as 5:3 - 6:3 (days since Jan 1st)? | ||
|} | |} | ||
Line 85: | Line 85: | ||
* 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. [[User:Drdanz|Drdanz]] ([[User talk:Drdanz|talk]])) | * 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. [[User:Drdanz|Drdanz]] ([[User talk: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 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]?) | * Is the class encoded somewhere? <s>(could be [30:4 - 30:5]? or maybe [56:5 56:5]?)</s>. 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 [[User:Drdanz|Drdanz]] ([[User talk:Drdanz|talk]])). | * 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 [[User:Drdanz|Drdanz]] ([[User talk: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 | * 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 |
Revision as of 10:15, 10 September 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 | fixed value in all samples, contains the Trenitalia UIC code ("83") | |
5:0 - 5:2 | unknown | ||
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:7 | unknown | varies between samples | |
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 - 49:7 | null | ||
50:0 - 50:7 | unknown | null if no PNR present, unknown content otherwise | |
51:0 - 55:7 57:7 | 0x0B 0x65 0x23 0x18 0x40 | fixed in all samples? | |
56:0 - 56:7 | 0xE5 or 0xE6 | ||
57:0 - 57:7 | 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 | 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
- 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)).
- 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