FreeTDS Development Group

["Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>]

Thanks James,

> You could add some/all of your names to alternative_character_sets.h.  

I discovered that my iconv() would convert ISO-8859 to UTF-8 (despite
circumstantial evidence to the contrary), so I did this and got past that
stage. However I then fell over on the ISO-8859 / UCS-2 conversions. My
iconv was having none of that.

> Or you could write replacements/iconv.c, implementing iconv_open(),
> iconv_close(), and iconv() for ISO-8859-1 <-> UCS-2 conversions (and same
> <-> same), leaning on the old ascii2unicode logic.  That's my grand plan
for
> reenabling non-iconv builds.  

So I guess I'm going to have to do this, if I'm to move forward with the
latest code.
I'm supposing it's not going to be THAT difficult, but I have a couple
questions before I consider it further...

If I code a replacements/iconv.c , will it have to replace my existing iconv
in all cases ?
If so, will I also have to cater for other conversions - like the
8859->ASCII and the 8859->UTF-8 ?

Any Idea what an iconv_t is ? I can't seem to find it in my Solaris header
files, all I can find is 

typedef struct _iconv_info *iconv_t;

or at least some ideas about what I'll need to put in my own version of it ?

> Or you could install GNU iconv.

Maybe, I'd rather not add this extra dependency for my freetds distributions
though.

Bill

> -----Original Message-----
> From: Lowden, James K [SMTP:LowdenJK AT bernstein.com]
> Sent: 24 June 2003 19:06
> To:   'FreeTDS Development Group'
> Subject:      RE: [freetds] RE: latest snapshot testing on Sun Solaris
> 
> > From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> > Sent: June 24, 2003 12:15 PM
> > 
> > AFAICT from the freetds code, we're trying to get iconv to 
> > say that it will
> > convert the 8859 character set (in various guises) to UTF-8 (again in
> > various guises), and giving up if it won't...
> > 
> > Have I correctly understood the problem do you think ? 
> 
> Basically, yes.  We're not trying to convert to UTF-8 per se.  We're
> assessing the client character set from nl_langinfo(3) or freetds.conf(5)
> ;-) and taking an agnostic point of view wrt the charsets.  That is, we
> don't assume anything about who's using what charset, except that we know
> TDS7+ metadata are always UCS-2LE.  
> 
> What you're bumping into is our long long long discussion about character
> set names.  There's no commonly accepted name (i.e. string) for charsets.
> One iconv_open(3) might use "ASCII" and another might use "646".  On Mac
> OS
> X and Win32, they're not even strings; they're numbers.  
> 
> We chose to use GNU's names as our canonical name i.e., the name to pass
> to
> tds_iconv_open.  To figure out what to pass to iconv(3), we use a lookup
> table src/tds/alternative_character_sets.h.  Your iconv's names are
> definitely not there, which is the nub.  
> 
> Freddy changed some of the logic, and I haven't looked at it closely
> since,
> so I'm a little hazy on just exactly what happens in configure and then at
> runtime.  But the notion is that if iconv rejects our canonical name, we
> try
> all the alternatives in turn until we succeed or exhaust the set.  I think
> the successful one becomes our canonical name for the duration of the
> session.  
> 
> > and if  so, what's the way forward ?
> 
> You could add some/all of your names to alternative_character_sets.h.  
> 
> Or you could write replacements/iconv.c, implementing iconv_open(),
> iconv_close(), and iconv() for ISO-8859-1 <-> UCS-2 conversions (and same
> <-> same), leaning on the old ascii2unicode logic.  That's my grand plan
> for
> reenabling non-iconv builds.  
> 
> Or you could install GNU iconv.
> 
> Thanks for pointing this out, Bill.  I haven't had time to work on FreeTDS
> since Erika got back from school, but I dislike imposing the iconv
> requirement on our Romanesque users.  
> 
> --jkl
> -----------------------------------------
> The information contained in this transmission may contain privileged and
> confidential information and is intended only for the use of the person(s)
> named above. If you are not the intended recipient, or an employee or
> agent responsible for delivering this message to the intended recipient,
> any review, dissemination, distribution or duplication of this
> communication is strictly prohibited. If you are not the intended
> recipient, please contact the sender immediately by reply e-mail and
> destroy all copies of the original message. Please note that we do not
> accept account orders and/or instructions by e-mail, and therefore will
> not be responsible for carrying out such orders and/or instructions.
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds