FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

Curt,

On Wed, Oct 10, 2001 at 12:43:56PM -0700, Curt Hagenlocher wrote:
> I want to apologize for my last email; it was pissy and off-topic.
> I haven't really been following this thread that closely, and am
> not a user of the FreeTDS C library in any event.

No apology is needed.  Rather, I would like to thank you for giving me
the opportunity to clarify my viewpoint.  Surely if you got the
impression that my comments were intended to slag Microsoft, I hadn't
done a very good job of presenting my technical arguments against UCS-2!

Another consideration I have in mind when suggesting UTF-8 (or rather,
when opposing UCS-2) is the large number of applications built not
directly on the FreeTDS C libs, but on top of bindings for other
languages.  Adding additional complexity to each of these bindings in
order to take a UCS-2 presentation and turn it into something that can
be consumed by each of these languages (namely, a multibyte
representation, since I believe PHP, Perl and Python all favor
byte-oriented string processing) seems wasteful to me.

>> FreeTDS is being written today, not five years ago when UCS-2 was
>> being put into NT4.  A Unix widechar
>> implementation done today should be using UCS-4.  Much better still is
>> the multibyte standard, UTF-8, which almost everyone in the Unix world
>> uses as the Unicode encoding of choice.

> As someone else pointed out, you'd still be limited by the server
> implementation even if the client implements the newer, wider spec.
> UTF-8 can, of course, be stored in regular char/varchar fields as
> long as all the clients of the database app agree to use that
> representation.

Yep.

> Would you return an error if someone passed a valid UCS-4 or UTF-8
> string that was not also a valid UCS-2 string?

I think that's the only reasonable thing to do if we're converting
between UCS-2 and UTF-8.  (Unless everyone agrees to the 'client
conspiracy UTF-16' idea, which I don't think even *I* agree with. :)
This would be a server limitation under any OS, after all, since UCS-2
is the only supported charset...  I think the people who run into this
limit with Unicode are probably already going to be acutely aware of
where this boundary lies.

Steve Langasek
postmodern programmer

Attachment: pgp5WiCEIt46s.pgp
Description: PGP signature