FreeTDS Development Group

["Mark J. Lilback" <mark AT lilback.com>]

At 9:04 PM +0200 9/2/2002, Frediano Ziglio wrote:
>  > Mac OS X uses unicode natively for strings, so any native (as opposed
>  > to command line port) application should be testing it. My
> >  application does, and I've got a few basic tests setup to check for
> >  Unicode support (which currently fail with freeTDS).
>
> If you want to provide some test you made I think your material could be
> very useful in future releases

I'll see if I can get it abstracted out to be generic. Right now 
they're all done via AppleScript so I can compare what the GUI 
produces to what I know is in the database.

> Mac OS X use ucs4 ?? What waste of space...

No. In all of APIs higher than BSD, you use a CFString/NSString, 
which encapsulates a string. By default, I think it stores in the 
format you constructed it with, but it supports ucs2, utf8, and a 
huge list of encodings. Every non-bsd system call accepts a CFString 
instead of a char*, and for those calls you're suppose to just pass 
in utf8 (accessible via a simple function/method).

I was just pointing out that in the future, ucs4 support might be 
necessary, so if changes are going to be made to support ucs2, they 
should be extendable so at a later point ucs4 could be added without 
trouble. I'm happy with utf8, however.

>  > If conversion were at the client level, I could get the unicode via
>  > dbdata(). As it is, that doesn't work since the iconv support is at
>  > the tds layer. Utf8 or ucs2 support would be better, of course.
> >
>
> Disagree. Too work for even a simple program that want just to use
> ascii...
> No conversion at all mean that client must expect data in
> single/multiple bytes with dozen of character sets...

By client I mean the API, such as dblib, ctlib, or ODBC.

At 4:43 PM -0400 9/2/2002, James K.Lowden wrote:
> Instead of dual
> conversion with an internal format, have zero or one conversions, as
> requested by the client.

That's what I'd like to see. If I want the same character set as what 
came on the wire, I shouldn't have to have two conversions.

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?

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.

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.

I haven't tried getting iconv to work again, but I'm sure I can get a 
version that works from Apple. (I don't remember where I got the 
version I tried.)

I'd prefer to not worry about using iconv, as the Mac has its own 
built-in encoding routines. I'd just like to get what comes over the 
wire from SQL Server 2000 and let the CoreFoundation framework deal 
with character sets and encoding.


--
__________________________________________________________________________
                                  "They that can give up essential liberty
Mark J. Lilback                    to obtain a little temporary safety
<mark AT lilback.com>                 deserve neither liberty or safety."
http://www.lilback.com/                               -- Benjamin Franklin