Opened 16 years ago
Closed 15 years ago
#2339 closed defect (fixed)
ODBC WVARCHAR Access Lacking
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.5.3 |
Component: | OGR_SF | Version: | unspecified |
Severity: | normal | Keywords: | odbc WCHAR NVARCHAR UTF-8 |
Cc: |
Description
Currently SQL Server NVARCHAR and similar native language fields are requested as SQL_C_CHAR by OGR which appears to trigger a translation to the current locale's encoding. If the field contains something like Arabic text this results in the text being corrupted (mostly turned to '?' characters).
The desirable solution would be to fetch the text as UCS-2 wchar_t and translate to UTF-8 for returning from OGR.
This bug is broadly address by rfc23_ogr_unicode but a more narrow fix will be required for OGR 1.5.2.
Change History (2)
comment:1 by , 16 years ago
Status: | new → assigned |
---|
comment:2 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
RFC 23 has been implemented in trunk for the ODBC driver. No further action required I think.
I have prepared a preliminary update to cpl_odbc.cpp that is MSVC only, and fetches WCHAR type fields as wchar_t and then converts to UTF-8 using the win32 WideCharToMultiByte() function. This is committed in 1.5 branch (r14361).
This is intended to be a narrow (non-disruptive) change for the stable branch while trunk will get a broader treatment based on rfc23_ogr_unicode but using a similar approach at the ODBC level.