Incorrect value length in ADI export

When a .adi is exported, if the data contains multi-byte characters, the value’s length is incorrect.

For example:

Generated on 2022-10-10T16:03:10.771Z 

The exported length seems to be a count of the UTF-16 code units, and not a count of the bytes.

'👨🏿'.length; // 4
# vs.
new Blob(['👨🏿']).size; // 8

In real-world use, is this problematic? I don’t know anyone who logs and exports characters other than straight text. Most other services and apps won’t accept them anyway (e.g, POTA. App, etc.). I don’t think the ADIF format allows it either.

This has proven problematic in an ADIF library that I work on, though I realize the user-base compared to the projects you’ve mentioned is rather small.

Regardless of whether other applications actually support multi-byte characters though, ADI doesn’t strictly support or disallow Unicode (or any other encoding). Why should the value’s length be a count of the Unicode code points then?

I’m interested in how other logging software handles multi-byte characters now. I’ll look into that.

It appears as though the logging programs that I’ve tried all handle this slightly differently.

  • HAMRS and Xlog both seem to count the Unicode code-points.
  • Cloudlog counts the number of UTF-8 characters.
  • AClog seems to convert the non-ASCII code points to ?s and sets the length to 4. (for “:adult:t6:”)

Every one of the tested applications, with the exception of AClog, will happily export multi-byte characters, but counts them wrong. I’m actually OK with AClog’s approach (even though it’s destructive) because it doesn’t break parsing. Every other program, including HAMRS, results in a broken ADIF file that can’t be parsed according to the specification.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.