Parsowanie ADIFa: Różnice pomiędzy wersjami

Z sapijaszko.net
Skocz do: nawigacja, szukaj
m (Utworzył nową stronę „{{Wpis |klucz=sapijaszko-parsowanie-2015-01-17 |Autor= Grzegorz Sapijaszko |Tytul=Parsowanie ADIFa |Data = 2015-01-17 |strona główna = tak |Wstęp = ''... i mruga, ł...”)
 
m
 
(Nie pokazano 4 pośrednich wersji utworzonych przez tego samego użytkownika)
Linia 5: Linia 5:
 
|Data = 2015-01-17
 
|Data = 2015-01-17
 
|strona główna = tak
 
|strona główna = tak
−
|Wstęp = ''... i mruga, łatwa to piosenka niedługa...'' Ta popularna piosenka doczekała się wielu wersji i przeróbek, z których kilka podaje Wikipedia. Poniżej zamieszczam kilka, odnalezionych w makulaturze, parodii autorstwa Jarosława Iwaszkiewicza, Słonimskiego, Tuwima i innych.
+
|Wstęp = O parsowaniu ADIFa słów kilka.
 
|Treść =  
 
|Treść =  
 
Kilka spostrzeżeń na temat formatu ADIF z punktu widzenia implementacji.
 
Kilka spostrzeżeń na temat formatu ADIF z punktu widzenia implementacji.
Linia 11: Linia 11:
 
===Logger32===
 
===Logger32===
  
−
Rekord z pliku ADIF generowany przez ten program  
+
Rekord z pliku ADIF generowany przez ten program:
  
−
<BAND:2>2M <CALL:6>SP6xxx <APP_LOGGER32_CNTY:4>D-WW <CONT:2>EU <CQZ:2>15 <DXCC:3>269 <FREQ:10>145.600000
 
−
<ITUZ:2>28 <MODE:2>FM <NAME:9>Stanislaw <OPERATOR:6>SQ6xxx <PFX:3>SP6 <QSL_SENT:1>Y <QSLSDATE:8>20140313
 
−
<QSO_DATE:8:D>20080126 <TIME_ON:6>215400 <QTH:7>Wroclaw <RST_RCVD:2>59 <RST_SENT:2>59 <STATE:1>D
 
−
<TIME_OFF:6>215400 <TX_PWR:1>5 <APP_LOGGER32_QSO_NUMBER:1>4 <EOR>
 
  
−
Brak pola <tt><CNTY>,</tt> za to informacja o województwie i powiecie zapisana jest w polu <tt><APP_LOGGER32_CNTY></tt> w postaci <tt><STATE>-<CNTY></tt>
+
<BAND:2>2M <CALL:6>SP6xxx <APP_LOGGER32_CNTY:4>D-WW <CONT:2>EU <CQZ:2>15 <DXCC:3>269
 +
<FREQ:10>145.600000 <ITUZ:2>28 <MODE:2>FM <NAME:9>Stanislaw <OPERATOR:6>SQ6xxx
 +
<PFX:3>SP6 <QSL_SENT:1>Y <QSLSDATE:8>20140313 <QSO_DATE:8:D>20080126 <TIME_ON:6>215400
 +
<QTH:7>Wroclaw <RST_RCVD:2>59 <RST_SENT:2>59 <STATE:1>D <TIME_OFF:6>215400 <TX_PWR:1>5
 +
<APP_LOGGER32_QSO_NUMBER:1>4 <EOR>
 +
 
 +
Mimo dodania informacji o województwie i powiecie, brak w wynikowym ADIFie pola pola <tt><CNTY>,</tt> za to informacja ta zapisana jest w polu <tt><APP_LOGGER32_CNTY></tt> w postaci <tt><STATE>-<CNTY></tt>. Co dziwne, w przypadku UA czy UT informacja o podziale administracyjnym jest zarówno w <tt><STATE></tt> jak i w <tt><CNTY>:</tt>
 +
 
 +
 
 +
<BAND:3>40M <CALL:6>RA3xxx <CNTY:5>VR-01 <CONT:2>EU <CQZ:2>16 <DXCC:2>54
 +
<FREQ:8>7.100000 <GRIDSQUARE:6>KO91oq <ITUZ:2>29 <MODE:3>SSB <OPERATOR:8>SQ6xxx
 +
<PFX:3>RA3 <QSL_SENT:1>Y <QSO_DATE:8:D>20100508 <TIME_ON:6>090602 <RST_RCVD:2>59
 +
<RST_SENT:2>59 <STATE:2>VR <TIME_OFF:6>090600 <TX_PWR:1>5 <APP_LOGGER32_QSO_NUMBER:2>70
 +
 
 +
Dla stacji DL w polu <tt><APP_LOGGER32_CNTY></tt> przechowywany jest numer DOK, np.: <tt><APP_LOGGER32_CNTY:3>X30</tt>.
  
 
Brak pola <tt><QSL_RCVD></tt> ze statusem <tt>'R'</tt> - w takim przypadku zakładamy, że dla wysłanych QSL (pole <tt><QSL_SENT:1>Y </tt>) oczekujemy karty QSL <tt><QSL_RCVD:1>R</tt>  
 
Brak pola <tt><QSL_RCVD></tt> ze statusem <tt>'R'</tt> - w takim przypadku zakładamy, że dla wysłanych QSL (pole <tt><QSL_SENT:1>Y </tt>) oczekujemy karty QSL <tt><QSL_RCVD:1>R</tt>  
  
−
==Przypisy==
 
−
<references/>
 
 
}}
 
}}

Aktualna wersja na dzień 23:47, 5 mar 2017

Parsowanie ADIFa

Kilka spostrzeżeń na temat formatu ADIF z punktu widzenia implementacji.

Logger32

Rekord z pliku ADIF generowany przez ten program: 


<BAND:2>2M <CALL:6>SP6xxx <APP_LOGGER32_CNTY:4>D-WW <CONT:2>EU <CQZ:2>15 <DXCC:3>269
<FREQ:10>145.600000 <ITUZ:2>28 <MODE:2>FM <NAME:9>Stanislaw <OPERATOR:6>SQ6xxx
<PFX:3>SP6 <QSL_SENT:1>Y <QSLSDATE:8>20140313 <QSO_DATE:8:D>20080126 <TIME_ON:6>215400
<QTH:7>Wroclaw <RST_RCVD:2>59 <RST_SENT:2>59 <STATE:1>D <TIME_OFF:6>215400 <TX_PWR:1>5
<APP_LOGGER32_QSO_NUMBER:1>4 <EOR>

Mimo dodania informacji o województwie i powiecie, brak w wynikowym ADIFie pola pola <CNTY>, za to informacja ta zapisana jest w polu <APP_LOGGER32_CNTY> w postaci <STATE>-<CNTY>. Co dziwne, w przypadku UA czy UT informacja o podziale administracyjnym jest zarówno w <STATE> jak i w <CNTY>: 


<BAND:3>40M <CALL:6>RA3xxx <CNTY:5>VR-01 <CONT:2>EU <CQZ:2>16 <DXCC:2>54 
<FREQ:8>7.100000 <GRIDSQUARE:6>KO91oq <ITUZ:2>29 <MODE:3>SSB <OPERATOR:8>SQ6xxx
<PFX:3>RA3 <QSL_SENT:1>Y <QSO_DATE:8:D>20100508 <TIME_ON:6>090602 <RST_RCVD:2>59
<RST_SENT:2>59 <STATE:2>VR <TIME_OFF:6>090600 <TX_PWR:1>5 <APP_LOGGER32_QSO_NUMBER:2>70

Dla stacji DL w polu <APP_LOGGER32_CNTY> przechowywany jest numer DOK, np.: <APP_LOGGER32_CNTY:3>X30.

Brak pola <QSL_RCVD> ze statusem 'R' - w takim przypadku zakładamy, że dla wysłanych QSL (pole <QSL_SENT:1>Y ) oczekujemy karty QSL <QSL_RCVD:1>R

Źródło: „http://www.sapijaszko.net/index.php?title=Parsowanie_ADIFa&oldid=3221”
Fakty o Parsowanie ADIFa
Kanał RDF
AutorGrzegorz Sapijaszko +
Kluczsapijaszko-parsowanie-2015-01-17 +
Klucz rodzajusapijaszko-parsowanie-2015-01-17 +
RodzajArtykuł +
Strona głównatak +
TreśćO parsowaniu ADIFa słów kilka. +
TytułParsowanie ADIFa +
Data
"Data" is a type and predefined property provided by Semantic MediaWiki to represent date values.
styczeń 17, 2015 +