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.
Encoding is such a crucial property of the file that is simple unbelievable that NB team keeps on ignoring it for almost 4 years (just check the history of http://www.netbeans.org/issues/show_bug.cgi?id=42638 and all relate bugs). Setting the encoding only per project is not going to solve the problem neither -did you ever developed anything in the environment where developers are spread all over the world and where final project needs to be assembled out of files in different encodings. Using external editors (read UltraEdit) before importing files into IDE is the solution in my case , but you can not imaging how annoying is it !... And then Property files, JSP etc .... I hoped so much that with NB6 and J2SE6 this will be solved once for good :-/ Don't want to start any religious ware here BUT just an suggestion: If some of you guys take look around the corner you'll see Eclipse and you will see that they have a recursive system of Encoding inheritance - on all the levels: each file (or dir) can specify its own encoding OR use the encoding of its parent (this is the default behavior). It all goes up to the project level, where the Project itself inherits its default encoding from the encoding property of IDE itself. Finally, IDE gets its default encoding from the OS.Simple, effective and straight forward - IMHO Why we can not have the same behavior ?! Is it possible that is so marginal issue for NB developers ? NB is great product and i really don't understand this attitude ....
The project encoding is not the only encoding you have. Indeed the project encoding is the default encoding of project and encoding of project's java files. The other files like (JSP, HTML,...) can have other encoding. The reason why all the java files have to have the same encoding is because the java compiler works in this way. If you create two java files depending on their self each having different encoding the compiler compiles them in single encoding (one is compiled in wrong encoding or not compiled at all) even if you start two java compilers with different -encoding option. Can you describe the case you are solving in more details?
Fair enough - I wasn't thinking about limitations of javac.... indeed javac should support the encoding per file not per invocation (request probably should be logged against this @ SUN)... But until they do so something, we could to do something for NB Anyhow, as you have pointed out, apart from javac, there are some other cases: I tried to summarize them bellow (pls feel free to add some other) A) Java source code: like someone proposed here, we can specify encoding in the Open/Save dialog box (and maybe some others) - once when text is in the NB it is UTF-16 encoded anyway. This is, IMHO, a nice compromise for the javac problem - in a case when source files are coming in a different encoding. When they need to be included in the project, they have to be Open/Save-d (which is always the case, anyway) ... and that's all - not perfect but it works. B) XML, HTML, JSP, CSS and others which have information about their encoding included inside the file (in a form of some markups etc) : It is not mandatory, per their specification, to include markups about their encoding, which means that their respective editors in NB have to guess something about the encoding used: usually they go for system default one and, usually, they are right. But they can be wrong as well ! Having encoding specified in the Open/Save dialog box (like in the case "A") can only partially solve the problem in this case. This type of files should actually have the Encoding Property on their Property page as a permanent attribute. Editors in question should try to respect that property if markup attributes are not specified in the file. However, If they are specified --and-- if that value is different from the one specified in the Property page then, the Editors, should ask a user (via some dialog box) in which encoding the file needs to be saved C) CVS/SVN Don't know anything about these - my SVN just works :-) ... but i guess they have their own "encoding" story ? -------- Anyhow, what is your thought on this ? ... It seems a lot of work but the problem is that NB is not used only as a Java editor but also it serves as an "Editor"/Viewer for many other things. Again, it is really annoying to have such a powerful tool like NB and still go for some external tools to do such a trivial thing like an encoding conversion .... like a Mercedes without air conditioner ... on a hot day :-)
Tomasi, isn't this rather enhancement for next release of NetBeans than a regular bug. It needs to be treated on different level than projects IMO.
I've finally got to this, sorry for the later answer. The most things you have described here are done. The NetBeans encoding API is very flexible, it provides API for clients like editor, refactoring and search and SPI provided by projects, data types (XML, HTML, ...). Each provider can define priority, for example the XML provider has higher priority than the project since XML may have stored encoding, if there is no stored encoding the encoding system uses project encoding when the XML is under some project otherwise it uses system encoding. So for XML, HTML, JSP you have a chance to override the project encoding by specifying the encoding in the file. As you pointed the problem is when you import sources stored in some other encoding different from project encoding and system encoding. Fox example you import XML file without encoding property stored in UTF-16 into project which uses UTF-8. The "Open In Encoding" action should help in this, you will be able to open the file and possibly add the encoding property or save it in the original encoding using "Save In Encoding" action. I think that all these problems can be solved by these two actions. Do you agree? I've added Jano (a netBeans UI engineer) to comment the suggested actions. I am not sure if these actions will be accepted by the UI team, but I will at least try to provide module with these actions on Autoupdate.
was off for a week - i.e. this is still important thing (imho) :-) so: those two actions (Open/Close) seem to be sufficient to solve the problem of Java source files, but for the XML, JSP etc i think poperty attribute should be specified (because the reasons ive described in the section B of my second post). Anyhow, if those two Open/Save actions can be implemented it would be already a great progress ! Did you hear from Jano & Co ? Any dates etc ?
No UI suggestions yet, I will implement the actions during this weekend as contrib module for now.
I think that rfe for allowing changing of encoding prop of xml and jsp can be good; it already exists for html. I don't know if that is needed as separate rfe than this one. ken.frank@sun.com
As usually I've forgot to delete INCOMPLETE :-)
Created attachment 51510 [details] [Open|Save] in encoding actions
I've created a module with Open In Encoding and Save in encoding actions, the sources are located in the Netbeans CVS contrib/encoding. The actions are placed in the Files menu when invoked they open file chooser in which you select file to open (save) and desired encoding. In addition to available encodings there is a special item "Default encoding" which means the encoding which would be used when the user opens (saves) the file using the ordinary open (save). When you open (save) a file using open (save) in encoding the encoding is bound to this file, it's remembered until you open (save) it in the default encoding. So, after opening the file in an encoding the file is always opened in this encoding until you save it or reopen it in the default encoding.
I installed and used it today. I think this is good that it requires explicit location for saving the file rather than saving in the project by default; as well as for opening the file it asks for location rather than assuming the project. since for java files, the need is to have all java files be in same encoding, and this way, if user has some files in other encoding, they can open them in their existing encoding, and then save them in the other encoding, and they can then give path to the project files, but at least it requires them to do explicit steps about it. ken.frank@sun.com ken.frank@sun.com
so, what would be the "Target Milestone" for this one and who has to set it up ... also who has to change the status to "FIXED"? (I hope you didnt forget it ;-)
Hi Goran, No target milestone yet, the Open|Save in encoding are available only on auto update for dev build 6.1. To resolve this issue I need to put them either to product or stable auto update. The first may be hard from the UI point of view (adding new actions to files menu), the seconds seems better. Have you tried these actions? Tomas
I tried this plugin, and it works great. It remembers my choice to the file, so I don't need to open the file with custom encoding every time. I think two enhancement needed: 1. the file encoding should be changeable in file's properties window http://www.netbeans.org/issues/show_bug.cgi?id=157817 2. in the projects, the default handling of file encoding should stay, but an option is needed in project properties: a checkbox in Project/Properties/Sources/Encoding "use this encoding for all project files" to enable that all the files in the project be handled with the project's encoding. In this way all the three cases solved: 1. set encoding per file 2. mixed encoding in a project (with unchecked checkbox) 3. one encoding for all project files (with checked checkbox)
It's a known RFE reported in version 6.0, please do not move Version field forward.
*** Issue 168517 has been marked as a duplicate of this issue. ***
I've tried the encoding module for a long time. Honestly, I don't think it is a convient way to solve the file's encoding. I agree with jrechtacek it's better to have a property to specify file's encoding. I finished a patch to do this. See http://www.netbeans.org/issues/show_bug.cgi?id=174083 for the duplicated issue or http://www.netbeans.org/nonav/issues/showattachment.cgi/89104/per-file-encoding.patch just for the patch itself A screenshot is attached also. http://www.netbeans.org/nonav/issues/showattachment.cgi/89103/newly_introduced_prop.png You can see that a new property named Text Encoding was appended to the platform. It defaults to the encoding of the whole project, or your OS's default one while no project is avaiable for the file, for example, when you drag a text file just from Windows Explorer. In my situation, GBK on a simplified Chinese Windows environment. And you can easily change it into another valid encoding (invalid value would cause a message dialog to come out), it will reload the document immediately without closing it and new encoding will be used then. If the document is modified, it will be closed automatically, then you must save your existed work after the encoding is changed, or your new encoding will be dismissed. I didn't think much about saving the file with a different encoding from which it is opened with. But you can simply do a copy (in encoding A) & paste (in encoding B) to solve it, as what I've done many times in Eclipse. Issues like resetting the per-file encoding to whole project's one are not considered, but not that difficult to resolve. I think it is meaningful to provide a property for encoding on each file in the platform, since only the user knows exactly about the encoding of a file. We could simply warn the user or address that the per-file encoding property is only for editing, not for the build. Maybe someday some build would rely on both per-file encoding and project's encoding, but clearly it is not now.
Hi. I've created an FOW page for this issue. (http://wiki.netbeans.org/TextEncodingFOW) Is there anyone who would review it or give more advices. Thanks.
Also see issue #19928.
It would be really useful for this to get implemented.
Change of default owner.
No plans for the standard IDE distro to include functionality to set different encodings on individual files within the project (except for formats such as XML which define an encoding in band). Third-party modules can easily support this using various GUIs if really needed. (Does not make any sense for Java sources since these must use a uniform encoding in order to be passed to javac in batch.)
(In reply to comment #22) > No plans for the standard IDE distro to include functionality to set different > encodings on individual files within the project (except for formats such as > XML which define an encoding in band). Third-party modules can easily support > this using various GUIs if really needed. (Does not make any sense for Java > sources since these must use a uniform encoding in order to be passed to javac > in batch.) So please add support for different file encodings at least in Netbeans for PHP. Every professional PHP IDE have this feature (Zend Studio, Eclipse...), so if you - developers of Netbeans - think support for PHP language seriously - it's a MUST-HAVE FEATURE. Project that have all files in one encoding would be great, but in practice with bigger (and older) projects in a lot of companies it's just an utopia! It would be great if Netbeans would have feature which is described in http://wiki.netbeans.org/TextEncodingFOW But if it can't be done, fix at least Encoding Support plugin: why it's available only in dev list of plugins? It's still buggy or not finished? Why can't be improved and available in Netbeans PHP by default?
(In reply to comment #23) > please add support for different file encodings at least in Netbeans for PHP This would be an RFE for php/project. > fix at least Encoding Support plugin I do not know about status of this plugin but can file issues in contrib/code for tzezula.
good post. http://www.winmilliongame.com http://www.gtagame100.com http://www.subway-game.com http://www.zumagame100.com