Non-ascii characters garbled in CPS UI

[SA0ASM]

Hi!

Moved this bug report over from the "new members" discussion.
So, the problem is that names in a codeplug or csv file containing non-ascii characters are garbled in the CPS UI and you can't use the UI to enter such characters correctly.

I've had a look at the CPS code now and I think I may have an idea of what's going on. In the "Settings" class, methods "smethod_23" and "smethod_25" have the chinese codepage "gb2312" hardcoded. This borks european characters when they undergo conversion to and from this codepage. My limited experimentation shows that replacing "gb2312" with "latin1", and it seems to solve the problem.

Please fix the bug so I can edit my codeplug data (with channel names containing å, ä and ö) in OpenGD77 CPS.

73 de SA0ASM

[SA0ASM]

Updating this thread to ask the CPS developers if it would be possible to implement the simple fix suggested by me previously.

73 de SA0ASM

[SA0BUX]

UTF-8 in channel names seems to corrupt other data such as frequencies when doing a csv import.

[VK3KYY]

In general only A-Z , a-z,0-9 characters are supported by the firmware , and hence the CPS

[SA0ASM]

If this is the case, could you please replace "gb2312" with "latin1" in the CPS code so that the characters that happen to be supported by the firmware actually work in the CPS?

Also, I believe the CSV import issue that SA0BUX is having is not related to character encoding but probably field delimeters.

73 de SA0ASM

[VK3KYY]

If this is the case, could you please replace "gb2312" with "latin1" in the CPS code so that the characters that happen to be supported by the firmware actually work in the CPS?

Also, I believe the CSV import issue that SA0BUX is having is not related to character encoding but probably field delimeters.

73 de SA0ASM

Colin G4EML wrote the CSV import / Export and it uses standard functions to handle the CSV.
I don't think the code page is specified at all, and attempting to make these sorts of changes could cause problems and require a lot of testing.

Ultimately the CSV only handles basic ASCII and UTF8 etc files should not be used.

[SA0ASM]

This has nothing to do with the CSV import, we are just talking about the functionality of editing channel/contact names in the CPS UI.
I understand if you don't want to support extended character sets, but it's a bit of a shame that the UI could be fully functional for the few extended characters that the radio supports if you just switch from using the chinese code page. It certainly won't create any problems to make the change, as I don't expect you intend to support chinese characters!

I could give you pointers to exactly which few lines in what source file would need to be edited, please consider making this small fix!

73 de SA0ASM

[SA0BUX]

UTF-8 in channel names seems to corrupt other data such as frequencies when doing a csv import.

Can't reproduce the corrupted frequencies when importing UTF-8 coded CSV files now when I tested more today.
I see that Lat/Long also was corrupted.

But it was there earlier:

Screenshot 2024-03-30 134111.jpg (242.03 KiB) Viewed 784 times

[SA0ASM]

Sorry SA0BUX, that Lat/Long error may be a problem with the decimal precision output by my python script. Not related to this bug for sure!

73 de SA0ASM