PROJ_LIB environment variable non ANSI characters in the path

[aharondavid]

Expected behavior and actual behavior.

PROJ failed to read PROJ_LIB environment variable when the file path encoding
is different from the system local

Steps to reproduce the problem.

1. set the PROJ_LIB environment variable to something different from your current locale (for example c:\temp\档案文件\proj )

2. add a egm96_15.gtx file to the above directory

3. transform failed on trying to open the GTX file

Operating system

Windows 10

PROJ version and provenance

PROJ 4.9.3

[kbevers]

PROJ 4.9.3 is quite ancient. Is this also a problem in PROJ 6.2.1?

[rouault]

We didn't change how we interact with files, so I'd bet yes. The issue is that we use ANSI C API. For Windows, we should likey use Win32 Unicode API like GDAL does. And possibly have some variable like GDAL also does to say if paths are in ANSI encoding or UTF-8. This comes from a GDAL ticket originally, but I suggested opening it here as it is a pure PROJ issue fundamentally.

[kbevers]

I figured, but my instinct tells me that a bug report for an unmaintained version of PROJ is not applicable.

And possibly have some variable like GDAL also does to say if paths are in ANSI encoding or UTF-8.

Is it really necessary to support both ANSI and Unicode in parallel? Wouldn't it be enough to just switch to the Unicode C API?

[rouault]

Wouldn't it be enough to just switch to the Unicode C API?

That would be a possibility. It is just that, at least in the old days when I tried on Windows, being able to specify a Unicode string in Windows cmd.exe was challenging. The default was to have the current codepage, which more or less what fopen() expects on Windows

[kbevers]

I'm no expert but I do work on Windows most of the time and it is my impression that Unicode generally works quite well. Unicode-support would be a nice feature for PROJ 7. I guess Linux/OSX already works fine with Unicode?

[rouault]

it is my impression that Unicode generally works quite well

my relationship with Unicode and Windows is definitely more complicated :-)

I guess Linux/OSX already works fine with Unicode?

They've been UTF-8 by default for the last 20 years or so :-) Nothing to do on that front.

[kbevers]

my relationship with Unicode and Windows is definitely more complicated :-)

You are at least correct in saying that cmd.exe is horrible when it comes to Unicode. PowerShell seems to be the same. Maybe it is too early to go full Unicode... :|

[busstoptaktik]

Maybe it is too early to go full Unicode

The cmd.exe unicode support is horrible, to say the least. It may need to wait for another couple of decades^H^H^H^H^H^H^H centuries^H^H^H^H^H^H^H^H^H milleniums^H^H^H^H^H^H^H^H^H^H aeons.