OGR.FileGDB support for UTF-8 paths fix

[danielzeitlin]

std::string FGDBLaunderName(const std::string name) has a bug. It simply breakes UTF-8 support completely (for paths and tables name). The following 'for' must be removed (it's bad):

for(size_t i=0; i < newName.size(); i++)
    {
        if ( !( newName[i] == '_' ||
              ( newName[i]>='0' && newName[i]<='9') ||
              ( newName[i]>='a' && newName[i]<='z') || 
              ( newName[i]>='A' && newName[i]<='Z') ))
        {
            newName[i] = '_';
        }
    }

Patch is attached.

[Even Rouault]

A better fix would be to add a LAUNDER=YES/NO layer creation option as in other drivers to enable/disable name laundering.

[danielzeitlin]

In any case LAUNDER=NO should be default for FileGDB driver.

[Even Rouault]

I wonder what you mean exactly with "paths". As far as I can see, FGDBLaunderName() is used to launder table/layer names and field names. This shouldn't affect filesystem paths.

[danielzeitlin]

I think you right, it's only table name, but still table name must not be laundered by default. We use Hebrew language for table names here and such if test on chars is bad. First it should convert name to Unicode and only than check using w_char.

[Even Rouault]

​https://trac.osgeo.org/gdal/ticket/4466 mentions a number of restrictions on layre names. Can you confirm that ArcGIS support Hebrew language for table name. An example .gdb with that would help confirming.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.