Documentación técnica RCH

ADIF

Ficheros ADIF

Los ficheros Amateur Data Interchage File son muy populares ya que la mayoría de los programas de radio amateur permiten, al menos, la exportación a este formato.

Hay un formato alternativo de adif (ADX) que no se tratará en este apartado debido a que las librerias y algoritmos para parsear y procesar XML son abundantes y bien conocidas.

Paradójicamente la mayoría de los programas hacen una interpretación poco estricta del formato, por lo que la carga y validación de los datos necesarios para la actividad del club es compleja y laboriosa.

Esto es debido a la flexibilidad aparente del formato. Este es muy sencillo de entender ya que usa una estructura en la que la información esta organizada en un fichero que contiene:

  • Una cabecera opcional (aunque fuertemente recomendada)
  • Un listado de “Records” que representan cada QSO

En ambos casos los datos de cada una de estas estructuras se representa con una etiqueta de clave - longitud - valor; y/o opcionalmente clave - longitud - tipo - valor. Por ejemplo:

<call:6>EA4RCH

Siendo el formato desglosado de la siguiente forma:

__Inicio de etiqueta
|__Inicio de clave (como se llama el dato)
||   __Separador de clave
||   |__Longitud en caracteres ascii del valor
||   ||_Fin de etiqueta
||   |||_Inicio del valor
||   ||||
vv   vvvv
<call:6>EA4RCH

En el caso de que los datos estén acompañados del tipo de dato entonces tendrán un solo carácter en mayusculas de los tipos permitidos en el formato. Por ejemplo, si a la etiqueta anterior le queremos añadir que es un campo de texto (S) quedaría de la siguiente manera:

<call:6:S>EA4RCH

Se da el caso de que como el tipo de dato es opcional, casi nunca se pone. Pero esto es así porque no podemos usar como clave de la etiqueta (en el ejemplo anterior call) lo que queramos. Como el estandar tiene una lista de los campos y tipos que tienen son conocidos por lo que no se suelen poner.

Esto no significa que podamos agregar cualquier campo arbitrario solo con ponerle el tipo. Ya que si el validador esta bien hecho debería arrojarnos un error de “campo desconocido”. Sin embargo es lo que pasa en la mayoría de los casos; que nos encontramos un campo inventado sin ninuna pista de que es, y nos vemos obligados a tratarlo como un simple texto. Como por ejemplo:

<SoyUnTioGuay:1:B>Y

Campos de aplicación

Las aplicaciones que lean y escriban ADIF tienen una nomenclatura que deben seguir para los campos propios. Aunque se recomienda adherirse lo máximo posible a los existentes, ya que el principal objetivo de este fichero es el intercambio de datos; y no solo de una aplicación a otra identica pero en otra localización (log4om -> log4om).

En el caso de que haya campos especiales para una aplicación estos deben seguir unas normas. La primera de ellas es que la etiqueta debe empezar por APP y estar seguida por un código de letras que identifica la aplicación, como por ejemplo “L4ONG”. Después el resto del campo siguiendo las normas estandar. Y como he comentado, es una buena practica poner el tipo de dato aunque nadie lo haga.

Aunque debemos evitar la tentación de embeber otros tipos de datos. Algunos programas se inventan un campo <APP_MIAPP_DATA:555>{"dato1": "valor1", "dato2":"valor2", ... }. Y esto es claramente no seguir el formato adif.

Campos de usuario

También debe soportar los campos de usuario, que se declaran en la cabecera. Hay que especificar su nombre, tipo y valores si es una enumración. De forma que la aplicación pueda comprobar que los datos son correctos. Esta última capacidad no la he visto usarse nunca. Lo cual es una pena, ya que es muy potente.

Su uso es poco conocido, pero se debe usar la cabecera:

<USERDEFINED[n]:[L]:[D]>[nombre],[enumeración]

Sustituyendo los [] por los siguientes datos:

  • n: Un número secuencial del número de campos dentro del fichero empezando en uno.
  • L: La longitud del valor del campo, como es habitual.
  • D: El tipo de dato del nuevo campo, que debe ser uno de los listados aquí.
  • nombre: el nombre que tendrá el nuevo campo.
  • enumeración: si el tipo de dato (D) es una enumeración, aqui debemos listar entre {} los posibles valores separados con ,

Es una forma fantástica de llevar un registro de información detallado para, por ejemplo, los diplomas locales que no tienen entidad internacional suficiente para ser añadidos a la lista oficial de diplomas de ADIF.org.

Last updated on 5 Jun 2023
Published on 5 Jun 2023