Bug report #9080
GdalTools (QGIS 2.0.1) fail if file path includes non-ascii characters
| 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 over 10 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 about 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 almost 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 over 7 years ago
- Category changed from GDAL Tools to Processing/GDAL
#5
Updated by Alexander Bruy about 7 years ago
- Status changed from Open to Feedback
Is it true for Processing front-end in master?
#6
Updated by Giovanni Manghi about 7 years ago
- Resolution set to not reproducable
- Status changed from Feedback to Closed
Closing for lack of feedback.