Okay, I've reviewed the apr-util code. What appears happening is
that nl_langinfo(CODESET) is called (by apr_os_locale_encoding) to
determine the current character set and that charset name is used to
get the iconv conversion to UTF-8. If nl_langinfo(CODESET) returns
null, an empty string or starts with a ^, then the compiler encoding
is used (likely ISO-8859-1). Running "locale charmap" in a console
should show the currently encoding. If the encoding name is not in
the list provided by "iconv -l" then bad things are likely to
happen. If it is, then try "iconv -f=XXXX -t=UTF-8 SOMEFILE.txt"
where XXXX is the encoding returned by "locale charmap" and
SOMEFILE.txt is some short text file and see if it reports any issues
with the conversion. If "locale charmap" returned null or an empty
string try using ISO-8859-1 as the encoding name.
It is possible that we could provide some fallback encoder/decoder in
case the locale info is messed up. But I'd really like to understand
what is going on before adding something that might cover up a
fixable issue. I searched the APR bugzilla and could not find any
bugs that mentioned APR_LOCALE_ENCODING or nl_langinfo(CODESET).
On Oct 20, 2006, at 6:35 PM, Allen Liu (allliu) wrote:
-----Original Message-----
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Looks like I bungled the cut and paste and must have got distracted
and not done a local build check before committing. I've hopefully
fixed the code, >>but haven't comfirmed it with a build as I'm in a
coffeeshop. Please try again.
charsetdecoder.cpp compiled but charsetencoder.cpp didn't. I fixed it
locally. I ran my small test program and got exception
APR_LOCALE_CHARSET.
Thanks,
Allen
