Re: Status of UTF-8 support in 0.83 dev

"James K. Lowden" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
Hi Sebastien, 

> When I print the client and the server charset in tds_convert_string()
> called from tds_put_data(), I see:
> 
>    char_conv->client_charset.name = "UTF-8"
>    char_conv->server_charset.name = "CP1252"
> 
> I expected UCS-2 for the server charset...????
> 
> Hence it's normal that the conversion of non-CP1252 compatible chars
> like é´» result in error...

That's OK.  I think you misunderstand the meaning of
client2server_chardata: "server_chardata" is the server's single-byte
encoding, used for char/varchar/text columns.  The server announces its
encoding as a message immediately after logon.  

(Off the top of my head, I can't think why we care about the server's
single-byte encoding.  Maybe for TDS 4.2.  TDS 7+ uses UCS-2; we never
send the server anything else IIRC.) 

As I said yesterday, CP1252 could explain your 2-byte/3-byte observation. 


First assertion: in unprefixed strings, *only* characters represented by
CP1252 will be stored correctly on your server.  All others will be
converted to CP1252 first by the server, with varying results.  Pick *any*
non-CP1252 character and see what happens.  

Second assertion: all prefixed strings embedded in SQL text will be
handled correctly on both ends.  

Final assertion: parameterized query buffers are not correctly converted
when sent to the server.  

That's where I think we are.  Agreed?  

Regards, 

--jkl
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.