FreeTDS Development Group

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

On Wed, 19 May 2004, Frediano Ziglio <freddyz77 AT tin.it> wrote:
> > If you are using a Microsoft server, you can store your data as
> > nchar/nvarchar/ntext.  You may then be able to use a binary binding,
> > causing FreeTDS to pass you the bits without interpretation.  
> > 
> 
> We don't support Unicode as client side. We support Unicode at server
> side. 

We should be careful with our terms.  "Unicode" is a system of assigning
numbers to components of written languages.  UCS-2 and UTF-8 are both part
of the Unicode standard; they're merely two different ways to represent
the same number.  (I know you know this, Freddy, but for the sake of
clarity....)  

> Data are converted from server ASAP so even
> using binary binding you get them using charset you provide.

True.  I never considered binary binding when we adopted our
convert-on-arrival scheme.  The caller would need to convert the nchar
data to a binary/image type on the server, and use a binary binding.  

I see now that FreeTDS is incompatible with Microsoft's ODBC driver in
this way.  There is no way to "just get the bits from the server", which
is what binary bindings are meant to do.  

> Honestly I don't see any reason to support client Unicode...

If you were using Windows or OS X for Chinese, you might find it more
convenient.   Those systems use UCS-2 natively, and have no built-in
support for UTF-8.  

I'm not sure db-lib *can* be 16-bit clean, because some of it is defined
in terms of null-terminated ASCII strings.  But the ODBC driver at least
could be; it's just a small matter of programming.  I imagine the same
goes for ct-lib, although the UCS-2 demand for ct-lib is vanishingly small
(hmm, DBD::Sybase for Japanese on a Macintosh).  

--jkl