FreeTDS Development Group

["James K. Lowden" <jklowden AT speakeasy.org>]

Brian Bruns wrote:

> The most important goal here is "don't break anything."  UTF-8 retains
> null termination which is pretty cool as far as this goes.  Using iconv to
> do UCS2 -> UTF-8 translation would "just work" for the english speaking
> folks (me).  This strikes me as a good default scheme.
>
> It would be nice to support UCS2 to other single byte character sets
> such that greek, german, french, etc... could work with existing systems
> that did not have UTF-8 support (variable length characters, bleah!). Is
> UTF-8 compatible with any of iso_1? or are chars > 127 all different?

Could I ask you to elaborate a little bit?  Are you sure you really *want * 
to be in
the translation business?  What dblib (for instance) functionality will iconv
support?  I thought binding happened server-side.  Or is it that everything 
arrives
from SQL Server 7 in Unicode, and you have to "step down" varchars at the 
client
end?  I'd like to understand this better.  I'm wondering what BCP 
ramifications there
might be.

Gnu claims to support 150 character sets for iconv.  Using it would yield 149 
more
character sets than we support now, a step in the right direction. :-)  It's 
a safe
bet the "easy" ones were done first, but I'm still looking into that.

> There should be some mechanism for a straight return of UCS2 to the
> client, assuming it can handle multibyte chars that is, for our CJK
> friends.

Yes.  A clear unadulterated UCS2 channel would meet Niky's needs, for one.  I 
would
think you'd want to make this the default case.

>
> This is all well and good as long as we are querying text.  I have no clue
> what happens on the insert (SQL) side of the house.

Right.  What does "select last_name from authors" look like in Greek?

--jkl