Hi QRZ-Team, we noticed a small change at the QRZ-LogDownload via API. It seems like QRZ generates it's adifs a bit different than before. e.g.: UTF8-File // QSO with a station who has a NAME with special-characters. QRZ: <NAME:20>José María Melchor Old One: <NAME:18>José María Melchor can anybody confirm or help here? which one is correct? According to ADIF-Standard the Length should be "The length of the ASCII-Strings". Since é isn't a ASCII-String, the counting of QRZ would be right. however: since that has been changed by QRZ (not sure), some parsers are failing. Any help is appreciated
Additional Info: A lot of Logbook-Tools create the above example with a stringlength of 18 (Number of chars // not number of bytes) The new behaviour of the QRZ-Export breaks a lot of parsers out there. Reproduce: Create a QSO to any Station with HamRadioDeluxe, Log4OM or HamOffice and Type in "Jôrgê" (instead of "Joerg") at the Name. ADIF-Export at all those Tools contain `<NAME:5>Jôrgê` Upload the resulting ADIF to QRZ. You'll notice that qrz shows `Jôrg` instead of `Jôrgê` because the importer at QRZ is already counting Bytes instead of letters/chars. this one isn't that evil, since there are only a few letters/chars missing (Bad, but nothing breaks). Now try it viceversa and download the QSO from QRZ. You'll notice, that the Name Field will be exported as `<NAME:5>Jôrg`. Now most of the import-parsers will fail, because there are (now) 4 letters/chars and not 5. The Export from QRZ has been adjusted to that during the last few days. The Import (QRZ takes ADIF) was always working that way (Cut strings in case of UTF8-Chars)
Jôrgê, We are still investigating this issue and cannot find anywhere that such a regression could have taken place. However there definitely seems to be an issue more work will be done on this tomorrow.
Could it be UTF-8 encoding that is representing special characters as 2 or 3 bytes? Could it be counting cr-lf?
Yes: Those special Chars are counting 2 bytes. That explains the behaviour. But: At ADIF everyone counts letters/chars, not bytes. That's the problem here. No: CR/LF wasn't/isn't part - thats another story
@DJ7NT I am testing a build that will return these field lengths based on the number of printable characters rather than bytes. We still have some concerns as we have not been able to verify what regression caused this issue and may have to roll back if more problems arise. We will also be testing a build that should handle importing these values better without truncating them (not currently life but I wanted to give you a heads up as it could impact your testing)
