This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Web browser displays garbage characters in non-UTF-8 ja locale. OS: Solaris snv_60 Locale: ja Java: 1.6.0 NetBeans: 5.5 build: griffin 070319 Generated Model Report specifies "charset=eucJP-open". OS: RHEL 3 Locale: ja_JP.eucJP Java: 1.5.0_10 NetBeans: 5.5 build: griffin 070319 Generated Model Report specifies "charset=EUC-JP-LINUX".
There is a feature in IDE itself that generating html files from source codes. I understand it uses always "UTF-8" as encoding and I think using UTF-8 can be the easy and reasonable solution for this issue.
Is this seen in using localized uml ? are all things seen in model report the garbage characters ? Can you specify and perhaps include a gif ? Are any of the garbage chars from the 2 html localized files ? If so, what is the meta charset of those 2 files and is that the one that is supposed to be used ? (Will can tell you more) PS what about on the mac - is it a problem for you there also ? (assuming the 2 html localized files are using correct encoding) ken.frank@sun.com
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.
will close this as duplicate of 89515 as Sheryl mentions and since there is the workaround. then will discuss with Sheryl about correct wording to use for new IZ issue that can let us having a full solution, since as Sheryl mentions, it needs additional parts to be done. I do think its something that needs to be solved since it forces solaris users into doing a workaround. ken.f.rank@sun.com *** This issue has been marked as a duplicate of 89515 ***