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.
-create a web project (ie. WA1) -set it to use windows-1252 character encoding in project properties -> sources -create an enity class named "Myóc" (ó is 00F3 in unicode) there -create a rest service from this class -create another web project (ie. WA2) -set it to use windows-1252 character encoding in project properties -> sources -create REST js stub (new file -> web services -> restful ws client stubs) for WA1 project (in the last panel of the wizard press Add Project button, look up WA1 project, keep defaults for the rest of fields in the wizard and finish it) -open web-pages -> rest -> wa1 -> Myóc.js file in the IDE's editor (or in some other (ie win notepad) which can show file in hex mode) => Myóc.js is written using UTF-8 encoding (on the ó's position one can find 00C3 00B3 characters in hex), I'd expect it to be in windows-1252 encoding since that's the one I set for the project
Created attachment 72481 [details] editor's screenshot
It might be that since project encoding was changed, that there could be some assumptions or charset tags in files created before the project encoding was changed, that might cause this - am just guessing here. I realize it could just be that creation of .js does not use project encoding/feq but it could be good to make sure the steps are done to avoid having the original encoding value of the project be noted somewhere even if project encoding prop is changed - thus suggest the following steps: 1. create some java project, it will use default utf-8 encoding; change this project encoding prop to the 1252 2. then create the first and subsequent web projects - they will be created in 1252 from the beginning and see if problem still happens. ken.frank@sun.com
thanks for your comment, Ken. Problem here is that the code responsible for .js files creation uses new OutputStreamWriter(projectStub.getOutputStream(lock), "UTF-8"); which means that UTF-8 will be always used regardless of what's set for the project (and looking more through the code I see no use of FileEncodingQuery to get correct encoding when it's needed), so to answer your question - yes, problem will persist even if the project will be created with win-1252 encoding from the beginning. I'm attaching a patch which should fix this issue in trunk ;-) Feel free to use it or let me know and I can push it to main
Created attachment 72487 [details] proposed patch
jungi, thanks for the explanation; can you please push it to trunk and we'll verify it as we begin testing for next nb release or for first patch - perhaps this one could go into patch ? kaa, was this problem seen by you when you were testing web services ? ken.frank@sun.com
ok, I'll take care of this
fixed locally in 06a5b9d41094, I'll push this later today. Added 65fixes1-candidate sw as well since I still remember hard times I had with proper file encodings as a usual user in webapps back in NB 3.5 & 3.6 times. Ayub, review my patch please. Thanks.
Excellent work Lukas! The fix 06a5b9d41094 looks good. -Ayub
Integrated into 'main-golden', will be available in build *200810230201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/06a5b9d41094 User: Lukas Jungmann <jungi@netbeans.org> Log: IZ #151036: I18N - js stub generator doesn't honor project wide encoding
verified: Product Version: NetBeans IDE Dev (Build 200810280201) Java: 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22 System: Windows XP version 5.1 running on x86; MS932; ja_JP (nb) re-checked with build 1005, WinXP, Japanese locale: The issue didn't happen with utf-8 project encoding. The issue was reproducible for win-31j project encoding. Also reproducible with NetBeans IDE 6.5 RC2 (Build 200810231029)
Since this issue is P3 priority, in accord with rules "How to include issues into patch" (http://wiki.netbeans.org/NetBeansPatches) it must include an explanation as to why its backport is necessary and how safe it is. Could you please provide such explanation?
justification: in case project uses non-default encoding some (js) IDE generated files will be generated using UTF-8 encoding which may cause troubles for users who will develop (localized) application using ie some chinese encoding. The only workaround for this is to find some other app/editor which is able to convert files from UTF-8 to user defined encoding how safe: fix replaces hardcoded "UTF-8" argument used in OutputStreamWriter with call to IDE wide FileEncodingQuery which is guaranteed to return valid, non-null value
The fix has been backported into release65_fixes repository. http://hg.netbeans.org/release65_fixes/rev/f57544705836