You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've hoped, that properties files would be UTF-8 by default in Java 18. This didn't happened.
current situation:
Default character set in Java 18 is UTF-8
Java properties files (with translated texts) are still by default in ISO-8859-1 in Java 18
There is option in Netbeans to use UTF-8 properties files - Use project encoding checkbox
Would it be possible to improve handling of UTF-8 properties files? Biggest problem seems to be that checkbox settings is stored in local netbeans folder (~/.netbeans/14/var/attributes.xml) not in project folder. So every team member has to configure it himself. It doesn't make sanse for each team member to have different settings.
Use case/motivation
No response
Related issues
No response
Are you willing to submit a PR?
Yes I am willing to submit a PR!
Code of Conduct
I agree to follow the Apache Software Foundation's Code of Conduct
As a side note: UTF-8 is the default for properties files loaded via PropertyResourceBundle, while properties files loaded via Properties#load(InputStream) are ISO 8859-1. Due to backwards compatibility, the latter is unlikely to ever change. (Applications who want a different encoding can use Properties#load(Reader) with an appropriate InputStreamReader.)
I agree that storing the configuration in the projects directory in nb-configuration.xml would make sense. Ideally, path patterns could be defined to enable assigning different encodings to different properties files.
This is not a philosophical debate.
I am facing an urgent problem for which I am seeking a concrete solution.
We are beginning the internationalization of the Audiveris project—starting with graphical elements, followed by user-facing messages.
This involves approximately 250 .properties files per language, with 3 languages to start with.
In the short term, that means about 750 files.
Asking every contributor (using NetBeans) to manually edit the properties of each of his copy of the 750 files to ensure they conform to the project's encoding requirements is simply out of the question. And the other contributors (those not using NetBeans) don't want to fight with Unicode strings.
For now, I have added a Java class to Audiveris that scans the entire project and generates the necessary XML fragments, which must then be manually inserted into the attributes.xml user configuration file for NetBeans.
I am well aware that this approach is a bit ridiculous.
But it is the only workaround I have been able to find so far.
A proper solution would be to host these commands within the project itself (typically in the nb-configuration.xml file).
@hbitteur: One alternative approach is to mandate in your project that all non-ASCII characters be encoded using Unicode escapes. There are dedicated properties file editors that ensure this, as does NetBeans itself. There is also the native2ascii tool to automate this.
@nmatt
I know.
But Unicode escapes are precisely the feature that many contributors don't want.
They use different editors (other than NetBeans). I know some use NotePad, others Visual Code, etc ...
It is very unconvenient for them to see a Unicode escape string instead of say an accented letter.
@hbitteur: One alternative approach is to mandate in your project that all non-ASCII characters be encoded using Unicode escapes. There are dedicated properties file editors that ensure this, as does NetBeans itself. There is also the native2ascii tool to automate this.
There is no point nowadays to store Unicode characters as escape sequences. All modern editors support Unicode by default. Java itself support this since a long time.
Enabling a global option by default in NetBeans to save properties files in proper Unicode is a must for interoperability with all other editors and IDEs, otherwise all properties files will become a mess when people use different editors.
Guys it is understood. If you would have pushed the same energy into fixing the issue instead of talking about how bad it is, there might already be a solution. I'll have a look at this, but the trivial solution is: Don't call your files ".properties" or change the association of the ending ".properties" to mime type "text/plain". With the latter you'll loose the highlighting you get with property files, but you'll get the default encoding you are looking for.
Activity
nmatt commentedon Aug 17, 2026
As a side note: UTF-8 is the default for properties files loaded via PropertyResourceBundle, while properties files loaded via Properties#load(InputStream) are ISO 8859-1. Due to backwards compatibility, the latter is unlikely to ever change. (Applications who want a different encoding can use Properties#load(Reader) with an appropriate InputStreamReader.)
I agree that storing the configuration in the projects directory in nb-configuration.xml would make sense. Ideally, path patterns could be defined to enable assigning different encodings to different properties files.
SilverGreen93 commentedon Oct 15, 2026
So there is no per-project or per IDE setting to allow reading and writing UTF-8 by default in properties files? This is nuts!
I'm glad other IDEs exists :)
hbitteur commentedon Oct 22, 2026
This is not a philosophical debate.
I am facing an urgent problem for which I am seeking a concrete solution.
We are beginning the internationalization of the Audiveris project—starting with graphical elements, followed by user-facing messages.
This involves approximately 250
.propertiesfiles per language, with 3 languages to start with.In the short term, that means about 750 files.
Asking every contributor (using NetBeans) to manually edit the properties of each of his copy of the 750 files to ensure they conform to the project's encoding requirements is simply out of the question. And the other contributors (those not using NetBeans) don't want to fight with Unicode strings.
For now, I have added a Java class to Audiveris that scans the entire project and generates the necessary XML fragments, which must then be manually inserted into the
attributes.xmluser configuration file for NetBeans.I am well aware that this approach is a bit ridiculous.
But it is the only workaround I have been able to find so far.
A proper solution would be to host these commands within the project itself (typically in the
nb-configuration.xmlfile).nmatt commentedon Oct 22, 2026
@hbitteur: One alternative approach is to mandate in your project that all non-ASCII characters be encoded using Unicode escapes. There are dedicated properties file editors that ensure this, as does NetBeans itself. There is also the
native2asciitool to automate this.hbitteur commentedon Oct 22, 2026
@nmatt
I know.
But Unicode escapes are precisely the feature that many contributors don't want.
They use different editors (other than NetBeans). I know some use NotePad, others Visual Code, etc ...
It is very unconvenient for them to see a Unicode escape string instead of say an accented letter.
SilverGreen93 commentedon Oct 22, 2026
There is no point nowadays to store Unicode characters as escape sequences. All modern editors support Unicode by default. Java itself support this since a long time.
Enabling a global option by default in NetBeans to save properties files in proper Unicode is a must for interoperability with all other editors and IDEs, otherwise all properties files will become a mess when people use different editors.
matthiasblaesing commentedon Oct 22, 2026
Guys it is understood. If you would have pushed the same energy into fixing the issue instead of talking about how bad it is, there might already be a solution. I'll have a look at this, but the trivial solution is: Don't call your files ".properties" or change the association of the ending ".properties" to mime type "text/plain". With the latter you'll loose the highlighting you get with property files, but you'll get the default encoding you are looking for.
hbitteur commentedon Oct 24, 2026
matthiasblaesing commentedon Oct 24, 2026
In #9748 a first implementation can be found. The PR will yield a nightly built, that can be tested. The build is available from the checks page or directly using this link: https://github.com/apache/netbeans/suites/108741698265/artifacts/12570477936.
Go to Tools -> Options -> Miscellaneous, change File Extension to "properties" and change "Associated File Type (MIME)" to "text/plain":
That way files with
.propertiesextension are treated as plain text files and you won't get the autoconversion NetBeans applies to property files.