(version 2.2.0  updated 2008-05-02 by AA6YQ)

Table of Contents

Physical Specifications

Data Types

Fields

Application-defined Fields

Deprecation

Enumerations

ARRL Section Names

Bands

Modes

Propagation Modes

Primary Administrative Subdivisions

Secondary Administrative Subdivisions

Country Codes

 

Physical Specifications

Each data field is preceded by a field name and length enclosed in angle brackets. The name and length are separated by a colon. The field name may be in upper, lower, or mixed case. Case is insignificant. For instance, CALL, Call, or call are equivalent. The length specification is ASCII text in display format, and may be of any non-negative value. The data follows the closing angle bracket. For example:

<CALL:6>WN4AZY

Records are made up of multiple fields and terminated with <EOR> or <eor> as an end-of-record marker. For example:

<call:6>WN4AZY<band:3>20M<mode:4>RTTY<qso_date:8>19960513<time_on:4>1305<eor>

An optional data type indicator may follow the field length, separated by a colon: For example:

<qso_date:8:d>19960513

or

<APP_MONOLOG_BIRTHDAY:8:d>19470726

Data type indicators are defined for each ADIF data type. The data type indicator may be in upper, lower, or mixed case. Data type indicators are redundant for ADIF-defined fields such as qso_date above, but are useful in application-defined fields as a hint for applications attempting to import such fields. 

Any number of characters of any value except < may be added after a field’s data or <eor> and before the start of the next field. This is typically carriage returns and/or linefeeds to make the file easier to read in a text viewer. For example:

<call:6>WN4AZY<band:3>20M<mode:4>RTTY
<qso_date:8:d>19960513<time_on:4>1305<eor>

<call:5>N6MRQ<band:2>2M<mode:2>FM
<qso_date:8:d>19961231<time_on:6>235959<eor>

In this example, a newline is inserted in the middle of each record, and two newlines are inserted at the end of each record. This makes long records easy to read in a text editor.

Optional header information may be included before the actual data in the file. To include optional header info, the first character of the file must be something other than <. Any amount of header info of any value except <eoh> may be included. The header info must be terminated with <eoh>. Any number of characters of any value except < may follow <eoh>. The first < after <eoh> is the start of the first field of the first data record in the file. Here is an example:

this data was exported using WF1B RTTY version 9, conforming to ADIF standard specification version 9.99<eoh>

<call:4>aa1a...

If the first character of a file is <, it is presumed to be the first field of the first data record.

The ADIF version may be included in the header info as follows: <adif_ver:4>1.00 is included as part of the header specification, an importing program can easily determine the ADIF version used to create the file. Note that this must not be at the beginning of the header info, because < as the first character indicates that there is no header.

It is important for the programmer importing ADIF data to note that any number of characters of any value may follow the actual data in a field. For example, carriage return/linefeed, or just a line feed. There is nothing in the specifications to prevent an exporter from placing a comment after the actual data. Therefore, after reading a field’s data based on the length specification, the programmer should read and discard characters until the start of a new field (<) or <eor> is encountered.

There is no specification for the order in which fields appear. They may appear in any order. Unused fields may be omitted entirely. Therefore, each record will not necessarily have the same fields. The specification does not prohibit a zero-length field, so those writing import programs should allow for this.

There is no specification for field length or maximum field length in the Physical Specifications. Unless there is a length specification in the Field Definition, exporters simply export all data in their field. Importers import as much data as their program can accept.

Note that while these examples have all been of simple ASCII fields, the specification permits data of any type or length. It could be easily used to transfer pictures or text documents, for instance.

Data Types

Fields

Application-defined Fields

Applications may define their own fields. To avoid naming collisions, such fields must be named using the format

APP_{PROGRAMID}_{FIELDNAME}

where {PROGRAMID} is replaced by the string used in the PROGRAMID field.  An application whose PROGRAMID string is MONOLOG could thus define the field APP_MONOLOG_BIRTHDAY .

if it wished to capture the contacted operator's birthday. To facilitate importing,  display, and editing by other applications, instances of application-defined fields should include the optional data type indicator, as in

<APP_MONOLOG_BIRTHDAY:8:d>19470726

Deprecation

Deprecated fields and enumeration values shall be accepted when importing an ADIF file, but shall not be emitted when exporting an ADIF file.

Enumerations

Ant Path Enumeration

ARRL Section Enumeration

Band Enumeration

Contest ID

Mode Enumeration

Propagation Mode Enumeration

Primary Administrative Subdivisions