[unixODBC-support] unixODBC and Unicode
nick.gorham at easysoft.com
Wed Jan 31 09:39:12 GMT 2007
Fredrik Ålund wrote:
>Why does unixODBC use 2 byte SQLWCHAR on Linux? Since wchar_t is 4 byte
>and all standard string (the unicode version like wscmp) used wchar_t I
>can not use any of them with SQLWCHAR. How am I supposed to work with
>SQLWCHAR? For portability between Linux and Windows, would it not be
>better to use wchar_t as SQLWCHAR? Even though wchar_t is 2 byte on
>Windows, how many applications really care about that? Most (all)
>applications I have seen simply uses wchar_t and that would be portable
>to unixODBC if SQLWCHAR was typedefed as wchar_t. As it is now SQLWCHAR
>(and therefore all W-functions) are very cumbersome to use. Now I use
>the ANSI versions of the ODBC functions and UTF-8, but when I write a
>new Unicode application it would be much easier to be able to use
>wchar_t and all standard C functions together with SQLWCHAR and the -W
>versions of the ODBC functions.
>I know I can recompile unixODBC to use 4 byte SQLWCHAR, but then I
>cannot rely on other users unixODBC installation to work with my
>application. Furthermore, I might break other applications when I build
>unixODBC with 4 byte SQLWCHAR.
>unixODBC-support mailing list
>unixODBC-support at easysoft.com
As you say, unixODBC has the option to use 4 bytes, so you are fee to do
that. The problem is that you then need the drivers to do it as well. So
you are no further.
As to there being no 2 byte applications, all the ones I have seen are 2
byte, OpenOffice being one that springs to mind.
Also this is ignoring the fact that there is potentially a conversion
required when going from 2 byte to 4 byte, who should do that, I would
guess you would expect unixODBC to do that, but I feel its better done
under the control of the application. As it is, unixODBC is the same on
windows as unix, so code on one will work on the other.
"I know I can recompile unixODBC to use 4 byte SQLWCHAR, but then I
cannot rely on other users unixODBC installation to work with my
application. Furthermore, I might break other applications when I build
unixODBC with 4 byte SQLWCHAR."
And the same would be true if I decided to make the default 4 from next
Wednesday, at least as it is now, its consistent across platforms.
More information about the unixODBC-support