This is being filed as per suggestions from Sheryl about, on solaris, 

encoding charset is not picked up by solaris browser if encoding string returned
from
System.getProperty("file.encoding") has a suffix "-open" and  if auto detect
encoding is turned off, so user has to manually set display encoding on browser
view->character encoding, but the page navigation with mbyte path is OK.

that is, so far its seen this happens on solaris euc ja locale since the encoding
string has the word 'open' in it.

--> what is needed is for user not to need to do the workaround in this
situation, that is, not needing to manually set the encoding using the view->
character encoding menu.



see 89185 that is related to this, but was orignally closed as having workaround
be done, but that does not seem like way to go now since can impact all on solaris.

also see 98285 which is from external user on seeing this situation.

From 98285:

The root cause is that we use encoding charset returned from query
System.getProperty("file.encoding") to set html meta tag. On Solaris, we get
"eucJP-open" instead of "euc-jp", which caused browser unable to render text
using the specified encoding, this glitch was noted in issue 89515, the
workaround is to manually set browser display encoding to the system default
one, or turn on auto-detect.

We can either 

1. leave out html charset meta tag when generating report, which does not really
solve this particular issue as browser will not automatically switch to euc-jp
encoding, but at least the html source will not be coded as 'eucJP-open'. 

2. further process the value from System.getProperty("file.encoding") and
convert it to the encoding accepted by browsers. This will not be a full
solution unless we have a complete encoding string mapping.


From 89515 - 4th paragraph marked by *** deals with this issue

Browsers on Solaris 
does not take mbyte string specified in href tag when it's encoded in a
different charset than the system default one. In our case, we generate page
using utf-8 with link reference to other pages encoded in utf-8, in system other
than utf-8, it will not find the page for the mbyte link. One possible solution
is to encode url string when generating href value, and the charset to encode
url has to be system default one. The drawback is encoded html source in href
value. Another option is to generate page using system default encoding, so we
don't need to process href  value.

JavaDoc uses system default encoding to generate pages, I think we should just
follow the model, implementation has been changed to use default encoding, no
special handling of url path is required.

Furthermore, to simplify localization settings, I made changes to avoid mixing
static and dynamic content, now the only html template files that should be
localized are index.html and help.html ( they should be localized in the charset
specified in metadata ), l10n.list is updated. Localized jar must be updated
before testing.

*** I tested on various zh and ja locales on Solaris, mbyte in package and diagram
name seems to be fine now. I did find a minor issue on one ja locale, when
encoding charset is not picked up by browser (encoding string returned from
System.getProperty("file.encoding") has a suffix "-open") if auto detect
encoding is turned off, so user has to manually set display encoding on browser
view->character encoding, but the page navigation with mbyte path is OK.***