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.
running in ja locale and using multibyte in java class name and data, which is legal. am not changing the default utf-8 project encoding (new feature for nb6) (its utf-8 but it still shows chars ok of the default locale user is in when running ide, which is the system locale; for me its solaris ja locale which is euc encoding. showing the local history window, the multibyte is not shown correctly; compare with right side of gif which is correct. I am guessing that some changes/assumptions related to the feq implenentation might have caused this problem in that local history code might be assuming euc-jp encoding vs utf8. the reason for this guess is that, if change the project encoding to euc-jp, create a new java file, and use mbyte, the local history left side is same as right side and shows correct multibyte.
Created attachment 43577 [details] image
clarification on the proj encoding property - user should not need to change it for default case which is, they are in some locale when running ide and using the characters of that locale in files - those chars should be shown correctly.
*** This issue has been marked as a duplicate of 85257 ***
no duplicate - LH doesn't handle the diff streams the same way as cvs and svn
fixed http://versioncontrol.netbeans.org/source/browse/versioncontrol/localhistory/src/org/netbeans/modules/localhistory/ui/view/LocalHistoryDiffView.java?r1=1.8&r2=1.9
verifying. appears ok when using both default utf-8 encoding or euc-jp encoding of project (when in ja locale) on variety of file types like java, text, html, jsp, xml. if user changes proj encoding then edit previously created file, its not expected that all non ascii chars should show ok, whether in local history or elsewhere, since the prev file was created in another encoding. ken.frank@sun.com
Still happens on Windows. filed as bug 123829.