台灣無線電俱樂部 TAIWAN RADIO CLUB ( TRC )
標題: Amateur Data Interchange Format 1.0 [打印本頁]
作者: finns 時間: 2013-11-29 18:15
標題: Amateur Data Interchange Format 1.0
http://www.adif.org/adif.html
1. 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 field type indicator may follow the field length, separated by a colon: For example:
<qso_date:8:d>19960513
The field type indicator may be in upper, lower, or mixed case. A field type indicator is optional. For instance, the Field Definition for QSO_DATE specifies that the field is always of type Date, so it is not necessary to repeat it here. However, when exporting user-defined fields that are not part of the ADIF specification, a type indicator will assist anyone attempting to import the data.
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 line-feeds 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 new line 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.
2. Field Type Definitions:
Type | Description |
| Date | A date specification in YYYYMMDD format |
| | |
| Time | A time specification. May be 6 characters long (HHMMSS) if seconds are included, 4 characters (HHMM) if seconds are not included. Time is in 24-hour format, from 0000 to 235959. A zero-length field or omission of the field indicates an empty time value. |
| | |
| M | Multi-line text field. For xBase MEMO and similar data. |
| | |
| C (Character) | So far everyone who has written an export program has not specified a type for character data. However, it is included in the specifications for consistency. |
作者: finns 時間: 2013-11-29 18:25
3. Field Definitions:
| Name | Type | Comment |
| ADDRESS | M | As it will appear on the mailing label |
| AGE | N | |
| ARRL_SECT | C | |
| BAND | C | 160M, 80M, 40M, 30M, 20M, 17M, 15M, 12M, 10M, 6M, 2M, 70CM,23CM...see table below |
| CALL | C | |
| CNTY | C | US County in the format STATE,COUNTY. For example GA,BARROW. Use CQ County list |
| COMMENT | C | Comment field for QSO |
| CONT | C | Continent: NA,SA,EU,AF,OC,AS |
| CONTEST_ID | C | Contest Indentifier -- SS, ARRLVHF, ARRLDX, etc. |
| CQZ | N | CQ Zone |
| DXCC | N | Numeric identifiers from ARRL. See table below |
| FREQ | N | in Megahertz |
| GRIDSQUARE | C | 4, 6, or 8 or however many characters |
| IOTA | C | HYPHEN MUST BE INCLUDED. Example: NA-001 IOTA PROVIDES DISK IN THIS FORMAT |
| ITUZ | N | ITU Zone |
| MODE | C | SSB, CW, RTTY, TOR=AMTOR, PKT, AM, FM, SSTV, ATV, PAC=PACTOR,CLO=CLOVER |
| NAME | C | |
| NOTES | M | Long text for digital copy, third party traffic, etc. |
| OPERATOR | C | Callsign of person logging the QSO |
| PFX | C | WPX prefix |
| PROP_MODE | C | |
| QSLMSG | M | Personal message to appear on qsl card |
| QSLRDATE | D | QSL Rcvd Date |
| QSLSDATE | D | QSL Sent Date |
| QSL_RCVD | C | Y=Yes, N=No, R=Requested, I=Ignore or Invalid |
| QSL_SENT | C | Y=Yes, N=No, R=Requested, I=Ignore or Invalid |
| QSL_VIA | C | |
| QSO_DATE | D | YYYYMMDD in UTC |
| QTH | C | |
| RST_RCVD | C | |
| RST_SENT | C | |
| RX_PWR | N | Power of other station in Watts |
| SAT_MODE | C | Satellite Mode |
| SAT_NAME | C | Name of satellite |
| SRX | N | Received serial number for a contest QSO |
| STATE | C | US state |
| STX | N | Transmitted serial number for a contest QSO |
| TEN_TEN | N | |
| TIME_OFF | C | HHMM or HHMMSS in UTC |
| TIME_ON | C | HHMM or HHMMSS in UTC |
| TX_PWR | N | Power of this station in watts |
| VE_PROV | C | 2-letter abbreviations: AB, BC, MB, NB, NF, NS, NT, ON, PE, QC, SK, YT
|
作者: bluefat 時間: 2013-11-29 18:56
上傳LoTW就要用ADIF的格式,像我這個手寫LOG的古代人,
每個月都要勞煩高手幫我轉檔,才能上傳LoTW,金拍謝!!
作者: finns 時間: 2013-11-29 19:12
我那個守聽 JT65 是 CSV 的檔
三天就要"手工" 用 Excel 把他變成 ADIF ....才能上傳
| 歡迎光臨 台灣無線電俱樂部 TAIWAN RADIO CLUB ( TRC ) (https://radio.club.tw/) |
Powered by Discuz! X3.3 |