Skip to Content.
Sympa Menu

freetds - Re: Ode to UTF-8

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Mark J. Lilback" <mark AT lilback.com>
  • To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Ode to UTF-8
  • Date: Tue, 3 Sep 2002 12:21:06 -0400


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




Archive powered by MHonArc 2.6.24.

Top of Page