Subject: Re: iconv vs. libiconv, was Re: Patch: Fix for Bug 1164, 2nd try
From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Wed May 23 2001 - 00:51:42 CDT
Vlad Harchev wrote:
>
> On Tue, 22 May 2001, Andrew Dunbar wrote:
>
> > Vlad Harchev wrote:
> > >
> > > On Tue, 22 May 2001, ha shao wrote:
> > >
> > >
> > > > Patch to add codepage items for Chinese. Really useful?
> > >
> > > It would be nice to commit it.
> > >
> > > Also everywhere, CJK hackers told us that not all iconv
> > > implementations know "CP950" and "CP936" under these names - if it's true for
> > > iconv AW is linked with, fallback charset names "BIG5" and "GB2312" should be
> > > used.
> >
> > According to the libiconv docs the encodings are not exactly
> > equivalent. The same goes for "CP932"/SJIS and possibly the korean
>
> AFAIR CJK hackers suggested this - it seems a reasonable fallback. But yes,
> these encodings are strictly speaking different.
>
> > encoding. Is there a good reason not to just use libiconv on all
> > platforms since we know it's a good implementation and know what
> > it does and does not have. It seems a small price to pay for a
> > nice gain in determinism.
>
> At least Linux's libiconv seems to be better (extensible at runtime, for
> example, etc) than libiconv - and unix people seem not to like code bloat..
This seems related. I've noticed in xap_EncodingManager.cpp the
function charsetFromCodepage returns "GB2312", "BIG5", etc instead
of "CP936", "CP950", etc even when the iconv supports
the "CPxxx"
form and the encodings differ.
I've looked at where this function is called and it seems to me this
opens the door to lossy conversions. Should this function also use
some form of fallback so that "BIG5" is only returned when iconv
doesn't support "CP950"? Or maybe this function is ambiguous and
really should be two separate functions?
Andrew Dunbar.
-- http://linguaphile.sourceforge.net _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:06 CDT