KDE PIM/KItinerary/vr.fi Barcode: Difference between revisions

From KDE Community Wiki
No edit summary
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
= General Observations =
= Format =


This is an ERA SSB version 1 code as described in "ERA TAP TSI Annex B.6 - Appendix C.1", with the following details/deviations:
* the issuer code is "0010" (UIC company code of VR).
* always exactly 107 byte
* always exactly 107 byte
* all binary, there are no recognizable ASCII strings in this
* barcodes on (newer? vending machine bought?) tickets have a "2" in the version field, they are nevertheless in the ERA SSB v1 format.
* the last ~64 byte have very high entropy, suggesting a signature or a compressed section
* arrival and destination are using alpha-numerical encoding and VR station codes.
* the customer number field contains a static value? (20105355479332)
 
= Other Observations =
 
* there's a base64 encoded sequential number printed below the Aztec code on the ticket, containing 24bit.
* there's a base64 encoded sequential number printed below the Aztec code on the ticket, containing 24bit.
* one barcode seems to be exactly for one journey section
* there's a 13 digit order number and optionally a 15 digit reference number on each ticket, sequential and covering multiple sections/travelers
 
= Bit Layout =


= Obsolete (Bit Layout) =


{| class="wikitable"
{| class="wikitable"
Line 21: Line 27:
| 4:0 4:6 || null || ||
| 4:0 4:6 || null || ||
|-
|-
| 4:7 - 5:7 || 9 bit day number ||  || day of travel, counted from Jan 1
| 4:7 - 5:7 || 9 bit uint ||  day of travel || counted from Jan 1
|-
|-
| 6 - 12 || 0x00 0x49 0x24 0x92 0x49 0x24 0x92 || || fixed in all samples, patterns repeats below
| 6 - 13:1 || 0x00 0x49 0x24 0x92 0x49 0x24 0x92 0b00 || || fixed in all samples, patterns repeats below
|-
|-
| 13 - 21 || todo || todo ||
| 13:2 - 16:7 || 5 x 6bit || departure station || see below
|-
| 17:0 || null || ||
|-
| 17:1 - 20:6 || 5 x 6bit || arrival station || see below
|-
| 20:7 - 21:7 || todo || todo ||
|-
|-
| 22:0 - 23:5 || 14 bit uint || train number || might be including too many/few leading 0 bits, 0 for buses
| 22:0 - 23:5 || 14 bit uint || train number || might be including too many/few leading 0 bits, 0 for buses
|-  
|-  
| 23:6 - 29 || todo || todo ||
| 23:6 - 25:3 || null || ||
|-
| 25:4 - 28:7 || todo || todo ||
|-
| 29 || 0b0010 0000 || || fixed in all samples
|-
|-
| 30:0 - 30:5 || 5 bit uint || coach number || leading 0 bits uncertain
| 30:0 - 30:5 || 6 bit uint || coach number || leading 0 bits uncertain
|-
|-
| 30:6 - 31:4 || 7 bit uint || seat number || 0 if no seat reserved
| 30:6 - 31:4 || 7 bit uint || seat number || 0 if no seat reserved
Line 43: Line 59:
| 42:1 - 106:0 || 64 byte varying || || high entropy in all samples, signature?
| 42:1 - 106:0 || 64 byte varying || || high entropy in all samples, signature?
|-
|-
| 106:1 - 106:7 || null || ||
| 106:1 - 106:7 || 0x00 or 0x80 || ||
|-
|-
|}
|}
= Station Codes =
* Using 2-4 characters long alphabetical codes from https://rata.digitraffic.fi/api/v1/metadata/stations, Wikidata has those codes as untyped P296 properties
* Values are encoded as a six bit number per character. Adding 55 to that number results in the corresponding ASCII code, which would suggest values 0-9 are reserved for digits. The value 36 (']' by that rule) is used to mark an unset character (for codes shorter than 5 characters).
* The official table also uses the 'Ä' and 'Ö' characters, it's unclear how those would be encoded here though.

Latest revision as of 08:58, 15 May 2021

Format

This is an ERA SSB version 1 code as described in "ERA TAP TSI Annex B.6 - Appendix C.1", with the following details/deviations:

  • the issuer code is "0010" (UIC company code of VR).
  • always exactly 107 byte
  • barcodes on (newer? vending machine bought?) tickets have a "2" in the version field, they are nevertheless in the ERA SSB v1 format.
  • arrival and destination are using alpha-numerical encoding and VR station codes.
  • the customer number field contains a static value? (20105355479332)

Other Observations

  • there's a base64 encoded sequential number printed below the Aztec code on the ticket, containing 24bit.
  • there's a 13 digit order number and optionally a 15 digit reference number on each ticket, sequential and covering multiple sections/travelers

Obsolete (Bit Layout)

Byte[:Bit] (MSB) Content Meaning Notes
0 - 1 0b0001 0000 0b0000 0010 unknown fixed in all samples
2 0b1010 0000 or 0b1000 0000 unknown
3 0b0000 0001 unknown fixed in all samples
4:0 4:6 null
4:7 - 5:7 9 bit uint day of travel counted from Jan 1
6 - 13:1 0x00 0x49 0x24 0x92 0x49 0x24 0x92 0b00 fixed in all samples, patterns repeats below
13:2 - 16:7 5 x 6bit departure station see below
17:0 null
17:1 - 20:6 5 x 6bit arrival station see below
20:7 - 21:7 todo todo
22:0 - 23:5 14 bit uint train number might be including too many/few leading 0 bits, 0 for buses
23:6 - 25:3 null
25:4 - 28:7 todo todo
29 0b0010 0000 fixed in all samples
30:0 - 30:5 6 bit uint coach number leading 0 bits uncertain
30:6 - 31:4 7 bit uint seat number 0 if no seat reserved
31:5 - 31:7 0b100 fixed in all samples
32 - 40 0x89 0x24 0x92 0x49 0x24 0x90 0x60 0x00 0x01 fixed in all samples, repeats a pattern from 6-12
41:0 - 42:0 todo todo varies slightly between samples
42:1 - 106:0 64 byte varying high entropy in all samples, signature?
106:1 - 106:7 0x00 or 0x80

Station Codes

  • Using 2-4 characters long alphabetical codes from https://rata.digitraffic.fi/api/v1/metadata/stations, Wikidata has those codes as untyped P296 properties
  • Values are encoded as a six bit number per character. Adding 55 to that number results in the corresponding ASCII code, which would suggest values 0-9 are reserved for digits. The value 36 (']' by that rule) is used to mark an unset character (for codes shorter than 5 characters).
  • The official table also uses the 'Ä' and 'Ö' characters, it's unclear how those would be encoded here though.
Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/KItinerary/vr.fi_Barcode&oldid=91802"