When I ran "locale charmap", I got "646", which I don't find in the list provided by "iconv -l". (what I can find in the list are ISO646-US, ISO_646.IRV:1991, ISO646_JP, ISO646_CN, etc.) I still tried "iconv -f 646 -t UTF-8 SOMEFILE.txt" and got "iconv: conversion from 646 unsupported".
Thanks, Allen > -----Original Message----- > From: Curt Arnold [mailto:[EMAIL PROTECTED] > > 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). > > >
