apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: Problem with iconv charsets...
Date Tue, 26 Jun 2007 11:04:15 GMT
On 6/26/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Eric Covener wrote:
> > On 6/25/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> >>  * At run-time this should probably be determined by parsing first the
> >>    LC_CTYPE, or LC_ALL in it's absense, or the fallback to the LANG
> >>    envvar if neither LC_ variable is defined.  The codepage follows
> >>    the period, e.g. LANG=en_US.UTF-8 would be parsed as 'UTF-8'.
> >
> > Wouldn't runtime checks would mean xlate/xlate.c needs to find a new
> > way to figure out what the codepage of the source code was (to
> > translate compiled-in strings)?
> >
> > Perhaps APR_DEFAULT_CHARSET could be split into two different
> > identifiers APR_CURRENT_CHARSET/APR_BUILD_CHARSET that xlate callers
> > would have to think about.
>
> I'm confused.  APR messages are all english (regrettably) in US-ASCII.

Taking that and massaging just a bit: APR strings in the source code
are either in US-ASCII or EBCDIC (simplifying just a bit on the
latter).

apr_os_default_encoding() needs to return something that can be passed
to apr_xlate_open() on the current platform in order to translate
compiled-in strings.

Mime
View raw message