Thread: Unicode/client_encoding/conversion problem

Unicode/client_encoding/conversion problem

From
Andreas Pflug
Date:
Hi friends,

when a column SQL_C_CHAR is handled in ResolveOneParam, the conversion
is coded dependent on param_sqltype. If a SQL_CHAR variable is bound to
it, no conversion takes place, which is incorrect. ODBC architecture
assumes sqltype to be the server_encoding, but this is irrelevant for
pgsql. Instead, everything is done with client_encoding (anything but
UNICODE doesn't make sense here), so we need a conversion to UTF-8 in
any case.

I wonder if the other direction is handled correctly...

A patch is attached.

Regards,
Andreas
RCS file: /usr/local/cvsroot/psqlodbc/psqlodbc/convert.c,v
retrieving revision 1.99
diff -r1.99 convert.c
2560a2561,2565
> /*********************
>  * it's not correct to convert depending on param_sqltype,
>  * because the client_encoding is always unicode.
>  * We need conversion in any case.
>
2577a2583,2594
>
> */
>
>             if (SQL_NTS == used)
>                 used = strlen(buffer);
>             allocbuf = malloc(2 * (used + 1));
>             used = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer,
>                 used, (LPWSTR) allocbuf, used + 1);
>             buf = ucs2_to_utf8((SQLWCHAR *) allocbuf, used, &used);
>             free(allocbuf);
>             allocbuf = buf;
>


Re: Unicode/client_encoding/conversion problem

From
"Dave Page"
Date:
Thanks, committed with minor fix to close the comment in the correct
place (pls check).

Regards, Dave.

> -----Original Message-----
> From: Andreas Pflug [mailto:Andreas.Pflug@web.de]
> Sent: 16 June 2003 11:52
> To: pgsql-odbc@postgresql.org; Dave Page
> Subject: Unicode/client_encoding/conversion problem
>
>
> Hi friends,
>
> when a column SQL_C_CHAR is handled in ResolveOneParam, the
> conversion
> is coded dependent on param_sqltype. If a SQL_CHAR variable
> is bound to
> it, no conversion takes place, which is incorrect. ODBC architecture
> assumes sqltype to be the server_encoding, but this is irrelevant for
> pgsql. Instead, everything is done with client_encoding (anything but
> UNICODE doesn't make sense here), so we need a conversion to UTF-8 in
> any case.
>
> I wonder if the other direction is handled correctly...
>
> A patch is attached.
>
> Regards,
> Andreas
>

Re: Unicode/client_encoding/conversion problem

From
Andreas Pflug
Date:
Dave Page wrote:

>Thanks, committed with minor fix to close the comment in the correct
>place (pls check).
>
>
>

Hi Dave,

fix hasn't  made it correctly into the source. The comment was just to
leave the old code for reference. This probably happened because the
second fix (ResolveNumeric)  would shift the rows of the first fix.

There's no switch(param_sqltype) needed, instead all code that's under
the 3 case SQL_xxx is to be executed for unicode. Absolutely wrong is
the last line "buf=buffer" in the default hieve, because this would
override the previous conversion.

Attached a new patch file, diff'd from the current cvs.

Regards,
Andreas
RCS file: /usr/local/cvsroot/psqlodbc/psqlodbc/convert.c,v
retrieving revision 1.102
diff -r1.102 convert.c
2561,2565d2560
< /*********************
<  * it's not correct to convert depending on param_sqltype,
<  * because the client_encoding is always unicode.
<  * We need conversion in any case.
< */
2569,2594c2564,2571
<             switch (param_sqltype)
<             {
<                 case SQL_WCHAR:
<                 case SQL_WVARCHAR:
<                 case SQL_WLONGVARCHAR:
<                     if (SQL_NTS == used)
<                         used = strlen(buffer);
<                     allocbuf = malloc(2 * (used + 1));
<                     used = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer,
<                         used, (LPWSTR) allocbuf, used + 1);
<                     buf = ucs2_to_utf8((SQLWCHAR *) allocbuf, used, &used);
<                     free(allocbuf);
<                     allocbuf = buf;
<                     break;
<                 default:
<
<                         if (SQL_NTS == used)
<                         used = strlen(buffer);
<                     allocbuf = malloc(2 * (used + 1));
<                     used = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer,
<                         used, (LPWSTR) allocbuf, used + 1);
<                     buf = ucs2_to_utf8((SQLWCHAR *) allocbuf, used, &used);
<                     free(allocbuf);
<                     allocbuf = buf;
<                     buf = buffer;
<             }
---
>             if (SQL_NTS == used)
>                 used = strlen(buffer);
>             allocbuf = malloc(2 * (used + 1));
>             used = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer,
>                 used, (LPWSTR) allocbuf, used + 1);
>             buf = ucs2_to_utf8((SQLWCHAR *) allocbuf, used, &used);
>             free(allocbuf);
>             allocbuf = buf;


Re: Unicode/client_encoding/conversion problem

From
"Dave Page"
Date:

> -----Original Message-----
> From: Andreas Pflug [mailto:Andreas.Pflug@web.de]
> Sent: 18 June 2003 14:22
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: Unicode/client_encoding/conversion problem
>
>
> Dave Page wrote:
>
> >Thanks, committed with minor fix to close the comment in the correct
> >place (pls check).
> >
> >
> >
>
> Hi Dave,
>
> fix hasn't  made it correctly into the source. The comment
> was just to
> leave the old code for reference. This probably happened because the
> second fix (ResolveNumeric)  would shift the rows of the first fix.
>
> There's no switch(param_sqltype) needed, instead all code
> that's under
> the 3 case SQL_xxx is to be executed for unicode. Absolutely wrong is
> the last line "buf=buffer" in the default hieve, because this would
> override the previous conversion.
>
> Attached a new patch file, diff'd from the current cvs.

Ahh yes, that makes more sense. Applied.

Regards, Dave.