Bug report #9080

GdalTools (QGIS 2.0.1) fail if file path includes non-ascii characters

Added by Minoru Akagi about 11 years ago. Updated over 7 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Processing/GDAL
Affected QGIS version:2.0.1 Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied:No Resolution:not reproducable
Crashes QGIS or corrupts data:No Copied to github as #:17725

Description

This problem was fixed once in 1.9 (8970a1f), but it was affected by c9eb4f2 I made to fix an issue #8010. I'm sorry for this. To fix it again, there might be two solutions in QGIS side.

1. revert c9eb4f2
Most users do not set the environment variable GDAL_FILENAME_IS_UTF8, I guess.

2. add --config GDAL_FILENAME_IS_UTF8 NO option into gdal command arguments.
This works in my environment. I think this way is better than 1.

History

#1 Updated by Minoru Akagi about 11 years ago

Another solution is here! in qgis.bat (qgis.bat.tmpl):

- set GDAL_FILENAME_IS_UTF8=YES
+ set GDAL_FILENAME_IS_UTF8=

These have the same meaning since internal default value of GDAL_FILENAME_IS_UTF8 is YES, and the new setting do not force the environment variable value to gdal program process.

#2 Updated by Minoru Akagi over 10 years ago

.exe utility programs (e.g. gdalwarp.exe) work with one of the above options, but python utilities (e.g. gdal_merge.py) do not work in any ways. I tested some more:

# gdalwarp works with the configuration option GDAL_FILENAME_IS_UTF8=NO
D:\\>gdalwarp --config GDAL_FILENAME_IS_UTF8 NO テスト\\N34E130.tif テスト\\N34E131.tif out.tif
Processing input file テスト\\N34E130.tif.
0...10...20...30...40...50...60...70...80...90...100 - done.
Processing input file テスト\\N34E131.tif.
0...10...20...30...40...50...60...70...80...90...100 - done.

# gdal_merge doesn't work with directly specified non-ASCII path
D:\\>gdal_merge --config GDAL_FILENAME_IS_UTF8 NO -o out.tif テスト\\N34E130.tif テスト\\N34E131.tif
ERROR 4: `eXg\\N34E130.tif' does not exist in the file system,

# gdal_merge works with UTF-8 encoded parameter file
# param.txt contains string "-o out.tif テスト\\N34E130.tif テスト\\N34E131.tif" in UTF-8
D:\\>gdal_merge --config GDAL_FILENAME_IS_UTF8 YES --optfile param.txt
0...10...20...30...40...50...60...70...80...90...100 - done.

# gdal_merge doesn't work with CP932 encoded parameter file
D:\\>gdal_merge --config GDAL_FILENAME_IS_UTF8 NO --optfile param_CP932.txt
ERROR 4: `繝・せ繝・N34E130.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

# gdalwarp works with non-ASCII path + wildcard
D:\\>gdalwarp --config GDAL_FILENAME_IS_UTF8 NO テスト\\*.tif out.tif
Creating output file that is 3601P x 1201L.
Processing input file テスト\\N34E130.tif.
0...10...20...30...40...50...60...70...80...90...100 - done.
Processing input file テスト\\N34E131.tif.
0...10...20...30...40...50...60...70...80...90...100 - done.
Processing input file テスト\\N34E132.tif.
0...10...20...30...40...50...60...70...80...90...100 - done.

# gdalwarp doesn't work with non-ASCII path + wildcard in UTF-8 encoded parameter file
# param_warp.txt contains string "テスト\\*.tif out.tif" 
D:\\>gdalwarp --config GDAL_FILENAME_IS_UTF8 YES --optfile param_warp.txt
ERROR 4: `繝・せ繝・*.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

#3 Updated by Minoru Akagi over 10 years ago

I did not understand this problem well. GdalTools do not simply set GDAL_FILENAME_IS_UTF8=NO, but append "NO" to the variable. GDAL_FILENAME_IS_UTF8 is set to "YES;NO" after running one of GdalTools. This is why GDAL tools (.exe) do not work with non-ASCII path in Windows.

#4 Updated by Giovanni Manghi almost 8 years ago

  • Category changed from GDAL Tools to Processing/GDAL

#5 Updated by Alexander Bruy almost 8 years ago

  • Status changed from Open to Feedback

Is it true for Processing front-end in master?

#6 Updated by Giovanni Manghi over 7 years ago

  • Resolution set to not reproducable
  • Status changed from Feedback to Closed

Closing for lack of feedback.

Also available in: Atom PDF