PROJ_LIB environment variable non ANSI characters in the path #1765
Comments
|
PROJ 4.9.3 is quite ancient. Is this also a problem in PROJ 6.2.1? |
|
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. |
|
I figured, but my instinct tells me that a bug report for an unmaintained version of PROJ is not applicable.
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? |
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 |
|
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? |
my relationship with Unicode and Windows is definitely more complicated :-)
They've been UTF-8 by default for the last 20 years or so :-) Nothing to do on that front. |
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... :| |
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. |
…o#1765) For backward compatibility, if PROJ_LIB content is found to be not UTF-8 or pointing to a non existing directory, then an attempt at interpretating it in the ANSI page encoding is done. proj_context_set_search_paths() now assumes strings to be in UTF-8, and functions returning paths will also return values in UTF-8.
…o#1765) For backward compatibility, if PROJ_LIB content is found to be not UTF-8 or pointing to a non existing directory, then an attempt at interpretating it in the ANSI page encoding is done. proj_context_set_search_paths() now assumes strings to be in UTF-8, and functions returning paths will also return values in UTF-8.
…o#1765) For backward compatibility, if PROJ_LIB content is found to be not UTF-8 or pointing to a non existing directory, then an attempt at interpretating it in the ANSI page encoding is done. proj_context_set_search_paths() now assumes strings to be in UTF-8, and functions returning paths will also return values in UTF-8.
…o#1765) For backward compatibility, if PROJ_LIB content is found to be not UTF-8 or pointing to a non existing directory, then an attempt at interpretating it in the ANSI page encoding is done. proj_context_set_search_paths() now assumes strings to be in UTF-8, and functions returning paths will also return values in UTF-8.
[RFC4_dev] Use Win32 Unicode APIs and expect all strings to be UTF-8 (fixes #1765)
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.
set the PROJ_LIB environment variable to something different from your current locale (for example c:\temp\档案文件\proj )
add a egm96_15.gtx file to the above directory
transform failed on trying to open the GTX file
Operating system
Windows 10
PROJ version and provenance
PROJ 4.9.3
The text was updated successfully, but these errors were encountered: