Thread: UNICODE again

UNICODE again

From
"Frank A. U."
Date:
So lets clarify this again for me.

When I use the wide ODBC API, UTF-16 chars are exchanged with the
application and not UCS-2 chars?

When I use the ANSI ODBC API what is the expected encoding in this case?

Thanks,
Frank




Re: UNICODE again

From
Hiroshi Inoue
Date:
(2013/07/27 10:50), Frank A. U. wrote:
> So lets clarify this again for me.

How do you use odbc?
Via applications like MS Access or MS Excel ...?
Or via middlewares like ADO or .NET ...?
Or via your applcations which call ODBC APIs directly?

regards,
Hiroshi Inoue

> When I use the wide ODBC API, UTF-16 chars are exchanged with the
> application and not UCS-2 chars?
>
> When I use the ANSI ODBC API what is the expected encoding in this case?
>
> Thanks,
> Frank



Re: UNICODE again

From
"Frank A. U."
Date:
On Sat, 2013-07-27 at 18:34 +0900, Hiroshi Inoue wrote:
> (2013/07/27 10:50), Frank A. U. wrote:
> > So lets clarify this again for me.
>
> How do you use odbc?
> Via applications like MS Access or MS Excel ...?
> Or via middlewares like ADO or .NET ...?
> Or via your applcations which call ODBC APIs directly?
Via the application.  I'm trying to write a binding for it.

I'm new to ODBC.  The confusing thing about it is that, as far as I
understand, the wide API should consume UCS-2 (by standard) but some
drivers seem to use UTF-16 there.  Similar situation for the ANSI API
which may be even worse if we consider the legacy code pages and UTF-8
-- how does an application know what it gets there?  Well and there's
apparently the possibility that translations happen in the DM.

Maybe this is not the right place to discuss those things but I use
psqlodbc for my testing.

>
> regards,
> Hiroshi Inoue
>
> > When I use the wide ODBC API, UTF-16 chars are exchanged with the
> > application and not UCS-2 chars?
> >
> > When I use the ANSI ODBC API what is the expected encoding in this case?
> >
> > Thanks,
> > Frank
>
>
>