Re: Continuing encoding fun....
| От | Dave Page |
|---|---|
| Тема | Re: Continuing encoding fun.... |
| Дата | |
| Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC9F79@ratbert.vale-housing.co.uk обсуждение исходный текст |
| Ответ на | Continuing encoding fun.... ("Dave Page" <dpage@vale-housing.co.uk>) |
| Список | pgsql-odbc |
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marc Herbert > Sent: 08 September 2005 11:10 > To: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Continuing encoding fun.... > > "Dave Page" <dpage@vale-housing.co.uk> writes: > > > The ODBC API (defined by Microsoft of course) includes a > number of *W > > functions which are Unicode variants of the ANSI versions > with the same > > name. > > I think one extra layer of confusion is added by the fact that POSIX > defines the type wchar_t as "the abstract/platform-dependent > character", W just meaning here: "W like Wide enough", whereas > Microsoft defines WCHAR as: "W like Unicode". Microsoft's abstract > character being "TCHAR". > > Am I right here? That certainly wouldn't help matters. We already have ucs2<->utf-8 conversion in various places to deal with *nix/win32 differences - trying to properly munge other encodings into those correctly wouldn't be fun! As I said though - there are other advantages to having a non-Unicode driver (like, BDE won't barf for example), so why go to all the hassle, when we can just advise the non-Unicode folks to use the ANSI driver? Regards, Dave.
В списке pgsql-odbc по дате отправления: