Re: Wrapper string encodings are inconsistent

Hi Michael,

I assume you're talking about the C# or Java bindings . In the case of 
the Python bindings, given the dynamic typing of the language, the 
typemap code tries to convert to UTF-8 when possible or return a bytes 
if not, and is also tolerant on if it receives a Unicode string or a 
bytes as input.

The issue is that even if *nominally* exchanges in the GDAL API are 
supposed to be in UTF-8, there is the possibility that some drivers 
might return strings in a unknown encoding. That could be CSV for 
example, or shapefiles or mapinfo files whose declared encoding is not 
understood by GDAL. I believe there is a ticket about the possibility of 
creating 2 variants of the SWIG methods for which that could occur: one 
with UTF-8, one with a binary type. Actually that might be this PR 
https://github.com/OSGeo/gdal/pull/3825 that  got stale.

Even

Le 25/03/2026 à 20:00, Michael via gdal-dev a écrit :
> Every function which returns char** has the "char **CSL" typemap 
> applied, which causes strings in the returned array to be decoded with 
> UTF-8.
>
> Every function which accepts a char** parameter has either the "char 
> **options", "char **dict", or "char **dictAndCSLDestroy" typemap 
> applied, which causes strings in the parameter's array to be encoded 
> with UTF-8.
>
> However, many functions which return a single string value or accept 
> single strings as arguments do not use UTF-8 encoding. This causes 
> several inconsistencies in the wrapper's behavior.
>
> For example, many times string values from string arrays which are 
> UTF-8 are used in other functions which are not UTF-8.
>
> Some examples:
> - AlgorithmRegistry.GetAlgNames() returns a string array of algorithm 
> names decoded with UTF-8, but AlgorithmRegistry.InstantiateAlg(string 
> algName) does not encode algName with UTF-8.
> - Algorithm.GetArgNames() returns a string array of argument names 
> decoded with UTF-8, but Algorithm.GetArg(string argName) does not 
> encode argName with UTF-8.
> - GeomCoordinatePrecision.GetFormats() returns a string array of 
> format names decoded with UTF-8, but 
> GeomCoordinatePrecision.GetFormatSpecificOptions(string formatName) 
> does not encode formatName with UTF-8.
>
> Also, some functions which return a string array have related 
> functions which return a single string value, but the strings in the 
> array are encoded with UTF-8 while the single string values are not. 
> For example, AlgorithmArg.GetAsStringList() returns an array of 
> strings decoded with UTF-8, but AlgorithmArg.GetAsString() does not 
> decode its returned string with UTF-8.
>
> And finally, many other string functions which accept or return 
> strings not encoded with UTF-8 probably _should be UTF-8_.
>
> Some examples:
> - Any "Get*Name" function or "name" property
> - Any "Get*Description" function
> - Any "Create*", "Delete*", or "Get*" function which accepts a "*name" 
> parameter
>
> Really, are there _any_ strings which _shouldn't_ be encoded with 
> UTF-8? I can't find a single reason why every string passed to the 
> wrapper should not be encoded as UTF-8, and no reason why every string 
> retrieved from the wrapper should not be decoded with UTF-8.
>
> -- 
> Michael Bucari
>
> _______________________________________________
> gdal-dev mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev