[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130626184715.GR29800@brightrain.aerifal.cx>
Date: Wed, 26 Jun 2013 14:47:15 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Iconv and old codepages
On Wed, Jun 26, 2013 at 02:39:59PM -0400, LM wrote:
> On Wed, Jun 26, 2013 at 2:15 PM, orc <orc@...server.ru> wrote:
>
> > I also noticed alternative libs thread and corresponding wiki page.
> > Does someone know lightweight iconv replacement as a temporary measure
> > (other than libiconv for example)?
> >
>
> Thought I had the Apache Portable Runtime project listed on the
> alternatives page. Will update that.
> APR has a version of iconv.
>
> BSD systems have their own implementations of iconv. Haven't found a
> standalone version. There may be some code in obase (listed on wiki).
> There's mention of a BSD licensed libiconv (
> https://wiki.freebsd.org/G%C3%A1borSoC2009 ) as part of Citrus (which was
> also supposed to have a gettext alternative). The web page on Citrus is at
> http://citrus.bsdclub.org/ but I haven't found the source code for the
> project. ICU ( http://site.icu-project.org/) provides uconv instead of
> iconv. On Windows, they typically use GNU libiconv since iconv isn't part
> of the C runtime library.
>
> If anyone thinks these (or possibly some other alternatives) are useful, I
> can add the links for them to the wiki. Please let me know if they any of
> them don't appear too bloated and would be worth adding.
You're welcome to add them, but it would be good to note that musl has
iconv, and it's definitely possible to consider deficiencies in musl's
iconv that are affecting real-world usage as bugs to be fixed. The
current priorities of musl's iconv are size, simplicity, and charset
coverage, in that order, and the usage cases I've prioritized are
conversion from legacy to Unicode-based rather than going in the other
direction.
So as of now, the main reasons someone might want a third-party iconv
when using musl are:
- Support for obscure charsets or the few not-yet-supported East Asian
charsets (mainly Korean and Taiwanese).
- High performance bulk conversions.
- Avoiding extremely-slow or missing reverse conversions (legacy
destinations). In musl, these are very slow and a few (the East
Asian legacy ones) are not even supported in reverse yet.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
