Incorrect value length in ADI export

[j4nr6n]

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 
<adif_ver:5>3.0.5
<programid:5>HAMRS
<programversion:5>1.0.6
<EOH>
...
<notes:4>👨🏿
...
<notes:2>😁
...
<eor>

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

[KZ3L]

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, QRZ.com. POTA. App, etc.). I don’t think the ADIF format allows it either.

[j4nr6n]

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.

[j4nr6n]

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 “”)

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.