Skip to Content.
Sympa Menu

freetds - Re: Unicode, UTF-8, and Greek

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Steve Langasek <vorlon AT netexpress.net>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Unicode, UTF-8, and Greek
  • Date: Wed, 10 Oct 2001 16:41:42 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page