FreeTDS Development Group

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

On Tue, 3 Sep 2002 12:21:06 -0400, "Mark J. Lilback" <mark AT lilback.com>
wrote:

> At 9:59 AM -0500 9/3/2002, Steve Langasek wrote:
> >Further assertion: all national language character sets in current use
> >on either Unix or Windows platforms are codepoint compatible with
> >ASCII.
> 
> Is that true for the asian character sets?

Mark, I can't find any definitive statement about that.  

You can peruse your X fonts with xlsfonts(1) and xfd(1).  AFAICT, they all
include arabic numerals in sequential order.   
 
With Unicode, as you know, one isn't restricted to any single "character
set".  If you want to send a UCS-2 arabic zero character (DIGIT ZERO), you
send 0x0030, period.  The Devanagari range (0900­097F), for example, is
used to represent Tamil (as in Madras, India).  That range doesn't include
a DIGIT ZERO.  It does include 0966 (DEVANAGARI DIGIT ZERO), and 9 other
digit characters.  In sequential order, thankfully.  

I'm not aware of any standard way, however, to infer equivalence between
DIGIT ZERO and DEVANAGARI DIGIT ZERO, which is what I'd guess you'd need
for my putative anytoi() (tm).  

> At 6:36 AM -0700 9/3/2002, James K. Lowden wrote:
> >What would be the effect of setting the client character set to 
> >UTF-8 when the protocol is 4.2 or 5.0?
> 
> This would be useful.

Especially if it worked.  ;)

> The biggest issue for me has been with TDS 7. At first, iconv was 
> very problematic, and the default action of stripping down to ascii 
> was too limiting for me. So I just modified the code in the libraries 
> I distribute to not use iconv and only strip the high byte and treat 
> it as latin1.

Setting your client character set to ISO-8859-1 should work as well as
your highbytestripping in any recent snapshot.  

Regards, 

--jkl