< KDE PIM | KItineraryRevision as of 17:27, 24 October 2019 by Vkrause (talk | contribs)(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) 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  (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 Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/KItinerary/Trenitalia_Barcode&oldid=86529" This page was last edited on 24 October 2019, at 17:27. Content is available under Creative Commons License SA 4.0 unless otherwise noted.