KDE PIM/KItinerary/Trenitalia Barcode: Difference between revisions

From KDE Community Wiki
No edit summary
 
(18 intermediate revisions by 2 users not shown)
Line 4: Line 4:
* exactly for one passenger/leg
* exactly for one passenger/leg
* 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
* up to byte 22 this matches "ERA TAP TSI TD B.12 - §15 Appendix B - SSB - old version", ie. SSB version 2, after that it diverges and doesn't match any of the SSB format versions anymore.
* 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
* 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
Line 12: Line 13:
! Byte:Bit (MSB) !! Content !! Meaning !! Notes
! Byte:Bit (MSB) !! Content !! Meaning !! Notes
|-
|-
| 0:0 - 4:7 || 0x20 0x14 0xC2 0x08 0x10 || header? || fixed value in all samples
| 0:0 - 4:7 || 0x20 0x14 0xC2 0x08 0x10 || || fixed value in all samples, contains the Trenitalia UIC code ("83")
|-
|-
| 5:0 - 7:7 || || date? || varies between samples
| 5:0 - 5:2 || null || ||
|-
|-
| 8:0 - 13:4 || 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?
| 13:5 - 14:3 || 100 xxxx || || 0000 for Italian stations codes (UIC 83.....), 0111 for international destination?
Line 32: Line 41:
| 24:3 - 29:7 || null || ||
| 24:3 - 29:7 || null || ||
|-
|-
| 30:0 - 31:1 || || || null if no PNR present, content unknown
| 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
| 31:2 - 32:0 || 7 bit uint || seat number || seat row for trains with an airplane-like numbering scheme
Line 42: Line 53:
| 32:7 - 33:6  || null? || ||
| 32:7 - 33:6  || null? || ||
|-
|-
| 33:7 - 38:3 || 6x6 bit as listed below || PNR || all null if ticket has no PNR
| 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:4 -43:3 || null ||  ||
| 38:3 -43:3 || null ||  ||
|-
|-
| 43:4 - 44:2 || 1010 011 or null || Issuer 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
| 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:7 || null || ||
| 44:3 -45:6 || null || ||
|-
|-
| 46:0 - 48:7 || || unknown || null if no PNR present, unknown content otherwise
| 45:7 - 50:2 || 6 x 6 bit uint || "Codice CP" (CP code) || Each uint is a digit of the code
|-
|-
| 49:0 - 49:7 || null || ||
| 50:3 - 50:7 || null || ||
|-
|-
| 50:0 - 50:7 || || unknown || null if no PNR present, unknown content otherwise
| 51:0 - 51:3 || 0x0 or 0x8 || || 0x0 when seat reservation/PNR present, 0x8 otherwise
|-
|-
| 51:0 - 57:7 || 0x0B 0x65 0x23 0x18 0x40 0xE6 0xC0 || || fixed in all samples?
| 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:0 - 58:3 || null || || might be part of the ticket number?
Line 62: Line 73:
| 58:4 - 62:3 || 32 bit uint || ticket number ||
| 58:4 - 62:3 || 32 bit uint || ticket number ||
|-
|-
| 63:4 - 65:7 || null || ||
| 63:4 - 65:6 || null || ||
|-
|-
| 66:0 - 66:7 || || || varies between samples, same as 6:4 - 7:3?
| 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)
|}
|}
== PNR Decoding Table ==
Based on all available samples, PNR strings map to the PNR binary encoding as listed in the table below:
{| class="wikitable"
! Code !! Symbol
|-
| 0 || W
|-
| 4 || 2
|-
| 6 || 3, Z
|-
| 8 || 4
|-
| 10 || 5
|-
| 12 || 6
|-
| 14 || 7
|-
| 18 || 9
|-
| 22 || B
|-
| 24 || C
|-
| 26 || D
|-
| 28 || E
|-
| 30, 31 || F
|-
| 32 || G
|-
| 34 || H
|-
| 38, 39 || J
|-
| 40 || K
|-
| 42, 43 || L
|-
| 44 || M
|-
| 46 || N
|-
| 50 || P
|-
| 52 || Q
|-
| 55 || R
|-
| 56 || S
|-
| 59 || T
|-
| 60 || U
|-
| 62 || V
|}
This is obviously incomplete due to too few samples. Observations/speculations:
* the lowest bit seems irrelevant for which symbol a code maps to, the meaning of that bit is unknown
* there are only 32 rather than 36 symbols used, probably omitting those that are hard to differentiate (1/I or O/0).
* the gaps in the table are suspected to be 2 -> X, 12 -> 8, 20 -> A, 36 -> I, 48 -> O
* the only conflicting sample with that theory is the clash on 6 -> 3/Z.


== Open Questions ==
== Open Questions ==
Line 140: Line 82:
* there is one sample where the departure and arrival UIC station codes are equal, contrary to what's in the corresponding PDF
* 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
* 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.
* 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?
* 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.
* 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]])). (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 [[User:Drdanz|Drdanz]] ([[User talk:Drdanz|talk]]))
* Is the PNR encoded? 46-50 seems like a plausible range for that. 36^5 possible values, ie. needs >= 26 bit.
* 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" in the PDF, and is that encoded somewhere? -> unlikely based on comparing adjacent codes

Latest revision as of 15:56, 14 July 2022

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
  • up to byte 22 this matches "ERA TAP TSI TD B.12 - §15 Appendix B - SSB - old version", ie. SSB version 2, after that it diverges and doesn't match any of the SSB format versions anymore.
  • 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