Standard naxps

UK postcodes comprise alphanumeric ‘outward’ and ‘inward’ parts separated by a space. For instance, for the postcode EC4M 8AD, EC4M is the outward and 8AD is the inward.

Although the space can be inferred if omitted (because the final inward part is always three characters), the encoding is affected by whether or not including a space is treated as the canonical form. Royal Mail says the standard version includes a space and so that is the standard we adopt here.

The anomalous GIR 0AA postcode is included, despite it officially having been phased out because, while it no longer appears in the official Postcode Address File (PAF), it remains in the Postzon product and may be present in older datasets.

Although the Royal Mail guide states that certain letters cannot appear in certain parts of a postcode, the standard naxps below encode all letters on the basis that

• following the guide explicitly would reduce the storage required from 31 bits to 30 bits, i.e. no material difference, and
• there is a history of postcode character exclusions being relaxed when more capacity is required – see e.g. the Netherlands postcode.

Some systems store a UK postcode as exactly eight characters by padding the spaces in the middle, e.g. B1␣␣␣1AA (where ␣ represents a single space character) so this is also included.

As with all postcode systems, a naxp encodes postcodes, but validation is a separate task, in this case typically requiring the PAF.

An Eircode comprises a three-character routing key plus a four-character unique identifier, with eleven letters that cause readability problems always excluded.

The guide recommends that an Eircode should always be

• stored as a single string of seven upper case characters in IT systems, e.g. A65F4E2, but
• presented in upper case as two parts separated by a space, e.g. A65 F4E2 and never A65F4E2.

For this reason, the two naxps below differ only in whether or not the version with a separator space is canonical.

The guide specifies that routing keys are letter-digit-digit or D6W. The naxps below deliberately widen the routing keys accepted to take a letter or digit as the third character on the basis that this accommodates the existing D6W special case and is one possible way Eircode could expand, while keeping the encoded value storage to 31 bits.

As with all postcode systems, a naxp encodes postcodes, but validation is a separate task, in this case typically requiring the Eircode Address File (ECAF).

A Netherlands postcode comprises four digits then two letters.

The official PostNL format mandates a space as a separator between the digits and the letters. In practice, online forms and backend databases omit the separator, and occasionally older legacy systems or international shippers use a hyphen e.g. 1012-AB, although this is technically incorrect.

As with all postcode systems, a naxp encodes postcodes, but validation is a separate task.

Netherlands postcodes are a case study in how strict original constraints on legal characters can later be relaxed when expansion is required. The 1977 format excluded
(a) the letters F, I, O, Q, U and Y – dropped in 2005, and
(b) zero (0) as a first digit – dropped in 2025, with postcodes 0000 AA to 0999 ZZ allocated for the Caribbean Netherlands.

Airline flight designators comprise two characters (letter-letter, letter-digit or digit-letter), followed by a flight number from 1 to 9999.

The treatment of leading zeros in the flight number varies by context: tickets omit leading zeros, e.g. AC861, whereas IT systems usually include them, e.g. AC0861. The definition of naxp encoding means that these two different formats result in different encoded values, and therefore only one of these forms can be canonical.

The approach taken here is that the version including leading zeros is the canonical format, which has the incidental benefit that encoded values sort by flight number within an airline.