Opened 10 years ago
Closed 9 years ago
#5689 closed defect (invalid)
GDAL failed to open a Chinese path FileGDB file
Reported by: | liminlu0314 | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SF | Version: | 1.11.1 |
Severity: | normal | Keywords: | FileGDB |
Cc: |
Description
GDAL failed to open a Chinese path FileGDB file. Test data are in the attachment, including three layers:
/测试
/poly
/test/polygons
I try to modify some of the source code, and now data with Chinese path can be opened, such as the attached"/测试". But“/poly”and“/test/polygons”still cannot be opened.
The following is my modified code in file FGdbUtils.cpp:
std::wstring StringToWString(const std::string& utf8string) { char* pszUTF8String = NULL; if(CSLTestBoolean(CPLGetConfigOption("GDAL_FILENAME_IS_UTF8", "YES"))) pszUTF8String = CPLStrdup(utf8string.c_str()); else pszUTF8String = CPLRecode(utf8string.c_str(), CPL_ENC_LOCALE, CPL_ENC_UTF8); wchar_t* pszUTF16 = CPLRecodeToWChar( pszUTF8String, CPL_ENC_UTF8, CPL_ENC_UCS2); std::wstring utf16string = pszUTF16; CPLFree(pszUTF16); CPLFree(pszUTF8String); return utf16string; } std::string WStringToString(const std::wstring& utf16string) { char* pszUTF8 = CPLRecodeFromWChar( utf16string.c_str(), CPL_ENC_UCS2, CPL_ENC_UTF8 ); std::string utf8string = pszUTF8; CPLFree(pszUTF8); if(CSLTestBoolean(CPLGetConfigOption("GDAL_FILENAME_IS_UTF8", "YES"))) return utf8string; else { char* pszLocalString = CPLRecode(utf8string.c_str(), CPL_ENC_UTF8, CPL_ENC_LOCALE); utf8string = pszLocalString; CPLFree(pszLocalString); return utf8string; } }
Attachments (1)
Change History (4)
by , 10 years ago
Attachment: | 测试.gdb.zip added |
---|
follow-up: 2 comment:1 by , 10 years ago
You are testing on Windows and with GDAL_FILENAME_IS_UTF8 = NO defined ? I'm a bit skeptical it helps since CPLRecode(xxxx, CPL_ENC_LOCALE, CPL_ENC_UTF8) is equivalent to CPLRecode(xxxx, CPL_ENC_ISO8859_1, CPL_ENC_UTF8) (see CPLRecodeStub() implementation). So that would mean that you pass a ISO8859-1 encoded filename ? I can't see how it can work with Chinese characters
On Linux, I don't need the patch, but indeed the FileGDB SDK seems to have issues with the poly and polygons layers :
$ ogrinfo 测试.gdb --debug on FileGDB: Really opening 测试.gdb FGDB: Error opening \poly. Skipping it (Invalid function arguments.) FGDB: Error opening \test\polygons. Skipping it (Invalid function arguments.) GDAL: GDALOpen(测试.gdb, this=0x10b9560) succeeds as FileGDB. INFO: Open of `测试.gdb' using driver `FileGDB' successful. OGR: GetLayerCount() = 1 1: 测试 (Point) FileGDB: ref_count of 测试.gdb = 0 now FileGDB: Really closing 测试.gdb now GDAL: GDALClose(测试.gdb, this=0x10b9560)
I'm not sure something can be done regarding this, since the error comes from the SDK.
But for the record, on Linux, with the OpenFileGDB driver, I can list and read the 3 layers (note the -ro parameter that will trigger the OpenFileGDB driver):
$ ogrinfo 测试.gdb -ro INFO: Open of `测试.gdb' using driver `OpenFileGDB' successful. 1: 测试 (Point) 2: poly (Multi Polygon) 3: polygons (Multi Polygon)
comment:2 by , 10 years ago
Replying to rouault: Yes, I did the test on Windows and set the GDAL_FILENAME_IS_UTF8 = NO. After debugging I founded it worked. The filename is encoded according to CP936 instead of ISO8859-1. Thanks a lot. Best regards.
You are testing on Windows and with GDAL_FILENAME_IS_UTF8 = NO defined ? I'm a bit skeptical it helps since CPLRecode(xxxx, CPL_ENC_LOCALE, CPL_ENC_UTF8) is equivalent to CPLRecode(xxxx, CPL_ENC_ISO8859_1, CPL_ENC_UTF8) (see CPLRecodeStub() implementation). So that would mean that you pass a ISO8859-1 encoded filename ? I can't see how it can work with Chinese characters
On Linux, I don't need the patch, but indeed the FileGDB SDK seems to have issues with the poly and polygons layers :
$ ogrinfo 测试.gdb --debug on FileGDB: Really opening 测试.gdb FGDB: Error opening \poly. Skipping it (Invalid function arguments.) FGDB: Error opening \test\polygons. Skipping it (Invalid function arguments.) GDAL: GDALOpen(测试.gdb, this=0x10b9560) succeeds as FileGDB. INFO: Open of `测试.gdb' using driver `FileGDB' successful. OGR: GetLayerCount() = 1 1: 测试 (Point) FileGDB: ref_count of 测试.gdb = 0 now FileGDB: Really closing 测试.gdb now GDAL: GDALClose(测试.gdb, this=0x10b9560)I'm not sure something can be done regarding this, since the error comes from the SDK.
But for the record, on Linux, with the OpenFileGDB driver, I can list and read the 3 layers (note the -ro parameter that will trigger the OpenFileGDB driver):
$ ogrinfo 测试.gdb -ro INFO: Open of `测试.gdb' using driver `OpenFileGDB' successful. 1: 测试 (Point) 2: poly (Multi Polygon) 3: polygons (Multi Polygon)
comment:3 by , 9 years ago
Milestone: | 1.11.2 |
---|---|
Resolution: | → invalid |
Status: | new → closed |
Test Data