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.
[Nb #200409071800, jdk1.5.0] User should be warn when the document cannot be correctly saved in the current encoding, e.g. when user have a document with ISO-8859-2 specific characters and then tries to save it in ISO-8859-1. The current editor implementation silently destroy the document (all ISO-8859-2 specific characters are replaced by question mark). Unfortunately reproducible in Java nad XML editors too.
Fixed in the jsp editor.
Now fixed in xml editor as well: http://xml.netbeans.org/source/browse/xml/core/src/org/netbeans/modules/xml/core/text/Bundle.properties.diff?r1=1.6&r2=1.7 http://xml.netbeans.org/source/browse/xml/core/src/org/netbeans/modules/xml/core/text/TextEditorSupport.java.diff?r1=1.22&r2=1.23 http://xml.netbeans.org/source/browse/xml/core/src/org/netbeans/modules/xml/core/lib/Convertors.java.diff?r1=1.6&r2=1.7
Fixed in jsp and xml editor -> reassigning to the java.
This is probably Martin's favorite bug, we have the same issue from him. *** This issue has been marked as a duplicate of 48843 ***
Not sure if marking this bug as duplicate is ok, if there are proves about fixes... Please integrate those fixes to Beta2 branche too. IMHO, including this fix to Beta2 would be nice. After the fix is integrated into the 'release40_beta2' branch, the committer must change the status whiteboard to 'beta2-fix'.
Reopening -> rassigning back to web (we have our own issue regarding this)
and changing back to fixed.
I don't think this is Beta2 candidate. This bug was here for all history of netbeans. I'm removing the beta2-candidate from Status Whiteboard.
I have to reopen. This is partialy fixed for easy scenarios. But if you do following: 1) have some (simple) JSP file with UTF-8 encoding 2) write into comment some national characters <!-- ěčřtýřá --> 3) save it. Close it. Open it again. So far so goood. 4) Change encoding to UTF-7 5) save it. You've got warning about non-supported encoding and if you wish to store the file in previous UTF-8 encoding. Say YES. And close it. 6) open it. And say YES that you wish to open this file in UTF-8 enc. so far so good. 7) NOW!!!change encoding to ISO-8859-1. And save it. No Question is arrised:-( 8) Close it. And reopen it. You lost your national char. in comment
Fixed in the trunk http://web.netbeans.org/source/browse/web/core/src/org/netbeans/modules/web/core/jsploader/BaseJspEditorSupport.java.diff?r1=1.42&r2=1.43
Still reproducible for: .tld, struts-config.xml, faces-config.xml, sun-web.xml, ...
Is it usual to change encoding in config files? I agree this is important for JSPs, because these are a part of the UI of the web application (and must be I18N), but how critical is it for config files? If this is just for config files, then I don't think this is a P2.
if it were P2 it should be solved already many many months ago;-) BTW: every "stupid" or smart? editor like notepad++, pspad, ultraedit, etc... can encode your edited file in encoding in which you preffer. So I don't see any objectives why the NB IDE (its editor(s)) can't do the same: to recognized correctly the current encoding and privide the possibilities to save it in a different one. that's my 2cents ;-)
Not common, but possible data lost is not P3 for me.
Fixed for tld files, struts config, jsf config. If there is a files, which has its own data object like sun-web.xml, then the similar issue should be entered against the implementation and not reopened this issue. Generally it's solved for xml files, but if someone overwrites the xml editor support or doesn't use it, then he has to take care about encoding by himself. IDE:------------------------------------------------- IDE: [7/4/06 5:36 PM] Refreshing CVS Status started M StrutsConfigEditorSupport.java IDE: [7/4/06 5:36 PM] Refreshing CVS Status finished IDE:------------------------------------------------- IDE: [7/4/06 5:36 PM] Diffing "StrutsConfigEditorSupport.java" started IDE: [7/4/06 5:36 PM] Diffing "StrutsConfigEditorSupport.java" finished IDE:------------------------------------------------- IDE: [7/4/06 5:42 PM] Committing Files started Checking in core/src/org/netbeans/modules/web/taglib/Bundle.properties; /cvs/web/core/src/org/netbeans/modules/web/taglib/Bundle.properties,v <-- Bundle.properties new revision: 1.2.96.3; previous revision: 1.2.96.2 done Checking in core/src/org/netbeans/modules/web/taglib/TLDEditorSupport.java; /cvs/web/core/src/org/netbeans/modules/web/taglib/TLDEditorSupport.java,v <-- TLDEditorSupport.java new revision: 1.4.14.1.2.2; previous revision: 1.4.14.1.2.1 done Checking in jsf/src/org/netbeans/modules/web/jsf/JSFConfigEditorSupport.java; /cvs/web/jsf/src/org/netbeans/modules/web/jsf/JSFConfigEditorSupport.java,v <-- JSFConfigEditorSupport.java new revision: 1.3.2.2.2.2; previous revision: 1.3.2.2.2.1 done Checking in jsf/src/org/netbeans/modules/web/jsf/Bundle.properties; /cvs/web/jsf/src/org/netbeans/modules/web/jsf/Bundle.properties,v <-- Bundle.properties new revision: 1.2.2.4.2.3; previous revision: 1.2.2.4.2.2 done Checking in struts/src/org/netbeans/modules/web/struts/StrutsConfigEditorSupport.java; /cvs/web/struts/src/org/netbeans/modules/web/struts/StrutsConfigEditorSupport.java,v <-- StrutsConfigEditorSupport.java new revision: 1.3.2.2.2.2; previous revision: 1.3.2.2.2.1 done Checking in struts/src/org/netbeans/modules/web/struts/Bundle.properties; /cvs/web/struts/src/org/netbeans/modules/web/struts/Bundle.properties,v <-- Bundle.properties new revision: 1.2.4.2.2.5; previous revision: 1.2.4.2.2.4 done IDE: [7/4/06 5:42 PM] Committing Files finished
For the sub-web.xml I created issue #79726.
2 questions - 1. I'd like to verify in nb6 - what is the basic scenario ? 2. when the feq for project encoding for web apps is implemented when default internall encoding is utf-8 but user can change project encoding, will that have impact on this fix ? ken.frank@sun.com
>1. I'd like to verify in nb6 - what is the basic scenario ? It should be done by QA. Martin could you verify it for NetBeans 6.0? >2. when the feq for project encoding for web apps is implemented >when default internall encoding is utf-8 but user can change project encoding, >will that have impact on this fix ? I don't know, whether I will answer your question. But for JSP will have to be implemented file encoding in the data layer, because there can be jsp files from one project with different encoding. This is real usecase. You can provide special jsp file for one language and another for another language. And because the file encoding has bigger priority than project encoding, the project encoding will not influence the jsp encoding. I expect similar solution for xml (configuration files).
actually for verifying, I am in QA, focusing on i18n things, so the scenario I asked about is the actual steps to do in nb to verify this issue ? for the feq question, you mentioned below "But for JSP will have to be implemented file encoding in the data layer, because there can be jsp files from one project with different encoding. " --> is this part of the web app feq that was just fixed - 97848 or is it another issue already filed - or does it need to be filed. Thanks for explaining about this fix and about jsp encoding vs new project encoding - that will be helpful scenario. ken.frank@sun.com
Verified for: .jsp, tld files, struts config, jsf config. But still reproducible for some other data objects. I'll enter another issues.
there is some discussion about flow of these warnings and consistency among same kind of warnings of html and xml; here is some mail exchange with Petr Pisl; other issues can be filed but it will help to know what the expected behavior should be; please let me know more about that and I can file some things. this below is in reverse chronological order since from email thread: c. a. from Ken I really would appreciate your opinion first on what should be the desired behavior, since there are 3 iz categories involved and I don't know which one would have the bug. T hen based on your comments, I can file the bug in the other categor(ies). Thanks - Ken b. from Petr Hi Ken, I don't think that there is a spec for the behavior. Every case was done by different developer and I agree with you that the behavior should be consistent. Could you enter a bug for this inconsistent behavior? Regards, Petr from Ken: > > Can you let me know about this or who else to ask: > > when changing the meta charset and/or page encoding value of xml, html, > jsp and > visualweb jsp files to iso-8859-1 from another encoding, there is a > warning popup > explaining about that, for example for html, that meta charset value is > invalid or doc > has chars that can't be saved ok in that encoding. > > and asks do you want to save using the original encoding value. > > for html or jsp, if click no, it does not save it, which seems like it > could be confusing > since if user clicks no, wouldnt it mean they understand the problem > and that the file > should be saved using iso ? > > for xml, a different popup appears, says the file has chars which will > be damaged during > conversion to iso-8859-1 and do you want to proceed > > if click yes, it does save it. > > > ==> thus it seems the behaviors are different, in that for jsp and html, > it wont save at all > if insist on using 8859-1 but xml will ======> what is the spec on all of this kind of functionality ? > I'm not saying fucntionality of either case is wrong or needs to be the > same; I I just want to understand it.