@jratike80 Do you have access to recent MapInfo? If so it could be useful if you could provde a .mif/.mid and/or .tab using UTF-8 encoding

If so it could be useful if you could provde a .mif/.mid and/or .tab using UTF-8 encoding

and possibly with non-ASCII field names

Do you have access to recent MapInfo?

No, we do not have any licenses any more.

@drons This doesn't build

NB! utf8 mid/mif was generated using iconv utility, requires verification with MapInfo.

coverage: 69.26% (+0.002%) from 69.258%
when pulling d06db89 on drons:mitabUTF8
into 08cbb83 on OSGeo:master.

@rouault maybe std::iswalpha is a more suitable function for a "laundering"?

std::iswalpha is a more suitable function for a "laundering"?

I don't know what constraints MapInfo set, if any...

I don't know what constraints MapInfo set, if any...

There is a comment in GDAL code about oldie MapInfo fields name constraints. But there are weak constraints at resent MapInfo.

But there are weak constraints at resent MapInfo.

so maybe relax / remove laundering if we generate for a recent MapInfo version?

I'll think about testcase

I'll think about testcase

thanks, and some documentation for the new option in doc/source/drivers/vector/mitab.rst
By the way, I've just merged #10291 into master. It would be great if you could rebase your PR on top of it, and add the UTF-8 entry in the doc/source/drivers/vector/mapinfo_encodings.csv file

coverage: 68.847% (-0.4%) from 69.258%
when pulling 4782c39 on drons:mitabUTF8
into 08cbb83 on OSGeo:master.

coverage: 69.26% (-0.004%) from 69.264%
when pulling a02dab3 on drons:mitabUTF8
into c456677 on OSGeo:master.