[unixODBC-support] unixODBC and Unicode

Fredrik Ålund fredrik.alund at mimer.se
Wed Jan 31 09:46:15 GMT 2007


Nick Gorham wrote:
> Fredrik Ålund wrote:
>
>> Nick,
>>
>> 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.
>>
>>
>> Regards,
>> Fredrik
>> _______________________________________________
>> unixODBC-support mailing list
>> unixODBC-support at easysoft.com
>> http://mail.easysoft.com/mailman/listinfo/unixodbc-support
>>
>>
>>  
>>
> 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.

But that only works if you transfer to Windows from Linux. A Windows
application is most likely to use SQLWCHAR as a wchar_t and using all
the standard string functions and that cannot be done on Linux.

How am I supposed to use SQLWCHAR on Linux?
>
> "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.
>

/Fredrik



More information about the unixODBC-support mailing list