Bug 32028 - I18N - Encoding property missing for plain text files
I18N - Encoding property missing for plain text files
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: -- Other --
3.x
All All
: P2 with 4 votes (vote)
: 6.x
Assigned To: issues@editor
issues@editor
: I18N
Depends on: 42638
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-16 00:35 UTC by hlavac
Modified: 2007-09-18 00:16 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hlavac 2003-03-16 00:35:29 UTC
Somehow we lost the ability to set plain text file's 
character encoding. There used to be Property for this,
now there is Encoding property for Java source files, but 
there seem to be no way of setting encoding of plain text 
files.
Is "Text" pane missing from plaintext file properties??
Comment 1 Miloslav Metelka 2003-03-18 13:31:26 UTC
The encoding property exists for java files only. Other files must be
handled by setting the global JVM-level encoding property -Dfile.encoding.
I'm not aware whether there is any effort being done in this area
(encoding cookie or similar) but transferring to core for
evaluation.The editor module itself is not the right place to do the
possible conversion (choosing the right byte-to-char-converter) as it
should only get the reader with the proper encoding.
Comment 2 David Simonek 2003-03-20 17:18:01 UTC
Reassigning to openide/editor, please try to evaluate, thx. I don't
know enough details, but could it be that in text module we will do
similar functionality like in java...or would it be wise if
openide/editor supported encoding selection for any document type?

Jan Hlavaty, in which version did plain text encoding property 
exists? Thx.
Comment 3 Miloslav Metelka 2003-03-21 09:37:37 UTC
I think it would be very desirable to do it for all the mime-types in
a common way.
 The editor kit part could then obtain the java.io.Reader with the
proper encoding.
Comment 4 David Konecny 2003-03-21 15:14:23 UTC
I think there never was Encoding property. Closing as duplicate.

*** This issue has been marked as a duplicate of 19928 ***
Comment 5 David Konecny 2003-05-28 13:53:15 UTC
Reopening. Please see the discussion in issue 19928. It does not look
we will be able to implement this properly soon in plaltform. And so a
solution similar to one in Java module should be done in the meantime
for plain text files.

At the moment I'm not sure whether this is editor module issue or text
module issue. Please reassign if necessary. Thx.
Comment 6 Jesse Glick 2003-05-28 17:31:53 UTC
Needs to be impl in text module. Compare java module's JavaNode prop,
Util.setFileEncoding, and of course JavaEditor.loadFromStreamToKit and
saveFromKitToStream. It doesn't look particularly complicated to me; a
bit more work in java module just because it needs to be passed to the
compiler too.
Comment 7 hlavac 2003-09-18 21:24:54 UTC
Any progress on this? I need to edit files which are in UTF-8 
(JavaScript, data files...) but IDE insists on platform default 
encoding...
It can't be too complicated to do this.

I'm pretty sure there was a generic character encoding property on 
file nodes in explorer tree view in previous versions.

Maybe some magic autodetection would be nice - like looking 
for "encoding=UTF-8" (or encoding=<anything> or charset=<anything>) 
string in the first few lines of text file. I could then place 
encoding declaration into comments of some sort.
Comment 8 David Konecny 2004-04-30 11:56:22 UTC
Issue 42638 if approved could make implementation of this one simpler.
Comment 9 nguyenq 2004-11-26 01:29:22 UTC
It's currently not possible in NB to save a text file in Unicode or in
any other formats except the default encoding. It's essential to have
a file encoding option for text-based files (.txt., .js, .html, etc.).
Comment 10 hlavac 2005-11-19 09:51:38 UTC
In NB 5.0 beta 2, we still have no way to specify encoding of plain text files
(documentation, readme files, licenses, configuration files...) Platform default
encoding is not appropriate for projects that are to be worked on by many
developers with different default platform encodings (where a fixed encoding
like UTF-8 would be much better). This is a major shortcoming, can you please
look into this?
Comment 11 aanno 2006-01-30 08:45:59 UTC
Comment from a (very bored) netbean user: 
 
This is essential and my feeling is that the problem is more sever in 
netbean-5.0-rc2. I would recomment to have the possiblity to set the mime type 
AND encoding for all projects files (perhaps the java source code is another 
issue...). 
 
Background: 
 
I'm doing professional J2EE coding with tapestry as web front library. With 
tapestry, you are using XML description files for (template) html pages and 
components. This files are XML but are in files named *.page and *.jwc 
respectively. It is common to have a utf8 or 8859-15 encoding here because 
this files are engaged in http form input validation and because of this there 
are often regex in the files that limit the input for example to [a-z]|[A-Z]|
[äöüÄÖÜ߀] or something the like. 
 
In netbean-4.1 it was bad: You couldn't edit this files but if you opened 
them, they wasn't harmed. In netbean-5.1-rc2 it is worse: you couldn't edit 
this files and when you open them, they are DESTROYED by coverting all 
'unknown' characters to '?'. This is done even when my default encoding 
contains 'äöüÄÖÜ߀' !!!! 
 
I fiddled around a bit with a start script like this: 
 
#!/bin/sh -x 
/usr/java/netbeans-5.0-rc2/platform6/lib/nbexec --userdir \ 
$HOME/.netbeans/5.0rc2 -J-Dfile.encoding=utf8 
 
but with absolute no success. The default encoding seems to be ignored. 
 
At the moment the is no support for having xml files without an *.xml file 
name! 
 
PS: 
 
This is an extract of an *.page file as an example: 
 
<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE page-specification 
      PUBLIC "-//Apache Software Foundation//Tapestry Specification 4.0//EN" 
      "http://jakarta.apache.org/tapestry/dtd/Tapestry_4_0.dtd"> 
 
<page-specification class="de.atron.b2xsale.web.Calculate"> 
    <description>Calculate</description> 
    <inject property="mandantDao"           object="spring:mandantDao"/> 
[...] 
    <bean name="pointValidator" 
class="de.atron.b2xsale.web.util.BankCodeValidator" lifecycle="render"> 
    	<set name="required" value="false"/> 
    	<set name="pattern">"([0-9]|[A-Z]|[äöüÄÖÜß]|[a-z]|\\ |\\-|\\.|\\(|\\))
{0,35}"</set> 
    	<set name="errorMessage" value="ognl:messagesUtil.nameValidatorMsg"/> 
    </bean> 
[...] 
</page-specification> 
 
 
 
Comment 12 Miloslav Metelka 2006-01-30 10:42:15 UTC
Strange - overriding of the default encoding should work (though not supported
officially). Could you try -J-Dfile.encoding=UTF-8 please? Thanks.
Comment 13 hlavac 2006-01-30 10:54:32 UTC
Problem with this is that you assume a single, global encoding - which is often
not the case! We need to be able to specify encoding of any text file with
better granularity - ideally per file.
Comment 14 Miloslav Metelka 2006-01-30 13:08:57 UTC
I know what the problem is well, what I was wondering about was that overriding
of the JVM's file encoding property did not worked as expected.
Comment 15 Masaki Katakai 2006-04-03 02:27:38 UTC
good example of user experience,

http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=67055

I think that text file encoding (including .java, .txt, .js and etc. - that can not
have encoding info in it) should be defined per

- entire IDE on option dialog
- project based on project property dialog
- file based on file property dialog

Then if different encoding other than system encoding is set, compiler option
should be changed properly e.g. adding -encoding UTF-8 according to text
file encoding.
Comment 16 Jiri Prox 2007-09-17 21:37:33 UTC
Obsolete milestone, please reevaluate
Comment 17 Jesse Glick 2007-09-18 00:16:57 UTC
6.0 has file encoding support (of a different sort than prior releases).


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo