Albert Chin wrote:
On Wed, Jun 07, 2006 at 11:53:08AM -0500, William A. Rowe, Jr. wrote:
Albert Chin wrote:
On Wed, Jun 07, 2006 at 10:04:14AM +0100, Joe Orton wrote:
On Mon, Jun 05, 2006 at 06:25:24PM -0500, Albert Chin wrote:
Trying the native Solaris iconv_open() for a conversion from "646" to
"UTF-8" seems to work though. Is this the recommended iconv
implementation for this platform?
Yes, unless you have found it to be broken in some way, why would you
not use the native iconv() where available?
Because not all the platforms we support has iconv so we build with
GNU libiconv everywhere to establish the same behavior. I'll ping the
GNU libiconv folks. I think the fix is simple.
Actually I'm curious what you have encoded in page 646. If this is part of
a server application, your local code page is possibly of zero interest.
If it's a console application it is probably significant.
We are trying to solve a Trac bug:
http://projects.edgewall.com/trac/ticket/2560
Here's the sequence of calls:
(subversion) svn_repos_find_root_path()
(subversion) svn_utf_cstring_from_utf8()
(subversion) get_uton_xlate_handle_node()
(subversion) get_xlate_handle_node(..., APR_LOCALE_CHARSET,
"UTF-8", ...)
(apr-utils) apr_xlate_open(..., APR_LOCALE_CHARSET,
"UTF-8", ...)
(apr-utils) handle_special_names(APR_LOCALE_CHARSET, ...)
(apr) apr_os_locale_encoding()
(apr) nl_langinfo(CODESET)
^^^^^^^^^^^^^^^^^^^^ returns 646 on
Solaris
Just a silly observation, but setting LANG to utf8 works, or no? does the
OS provide a neutral filename convention, or are the filenames in binary
truly 646 encoded?
Anyways make sure that your iconv was built with all standard, optional
and extra code pages.
Bill
