United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8011194 : Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X

Details
Type:
Bug
Submit Date:
2013-04-01
Status:
Resolved
Updated Date:
2014-09-04
Project Name:
JDK
Resolved Date:
2013-08-02
Component:
core-libs
OS:
os_x
Sub-Component:
java.util:i18n
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u51,7u4,7u40,8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
JDK-8003228 fixed a problem on OS X with filenames containing non-ASCII characters.  For instance, such files would not show up in file chooser dialogs under certain circumstances (launching via webstart or double-clicked .jars, or from the Terminal with LANG=C).  Post-8003228, the sun.jnu.encoding property is always set to UTF-8 on Mac OS X.

The problem remains that once the file is loaded, non-ASCII characters *contained* in files do not display correctly.  This is due to the "file.encoding" property being set to US-ASCII for apps launched by double-clicking a .jar file.

                                    

Comments
I'd probably be dreaming if the solution was to change the default encoding for MacOS to UTF-8.... sigh.
                                     
2013-04-01
JDK-7193966 covered this issue in the context of browser applets.

                                     
2013-04-01
I've attached a copy of the Notepad JFC demo, modified to display the value for the following upon startup:
* file.encoding system property
* sun.jnu.encoding system property
* LANG env var
* LC_ALL env var

Make sure you have a jre7 or jre8 installed (not Apple's jre6).

To reproduce the bug, build the test case, go to NotepadProj/dist/ in the Finder, and double-click on the Notepad.jar file.  Use File->Open to open the NonAscii_.txt file.  The file will display in Notepad, with '?' characters displayed instead of the proper unicode characters.

The app displays the file correctly when launched from Terminal, provided that LANG or LC_ALL is set to something unicode-capable (such as en_US.UTF-8).

(Note: the absence of the NonAscii_??.txt file from the list of files in the Notepad file chooser indicates the presence of bug 8003228.  This should not happen for jdk8b73 or later).

                                     
2013-04-01
The problem happens even when the preferred language is set to something besides English in the Language & Text preferences pane.  I tried Japanese & German (plus logged out & back in), but a double-clicked .jar still got a file.encoding of US-ASCII.

                                     
2013-04-03
If the problem happened only on English perhaps it is easy to fix, but if the encoding is not set regardless of the
user chosen language then what do we set the encoding to ? and how does the Apple's JDK manages to set
the correct encoding ? So is the default encoding simply set to UTF-8 regardless on an Apples JDK ?
                                     
2013-04-03
The JDK should pick up the env variable _CF_TEXT_ENCODING and set the encodings based on this. 
See: http://developer.apple.com/library/mac/#technotes/tn2228/_index.html 
http://superuser.com/questions/82123/mac-whats-cfusertextencoding-for

It is not clear what the encoding should be set to, and it appears this needs to be sorted out, discussing with the Apple developers ?

Regardless, this is not a launcher issue, the launcher has no way of knowing whether it was double-clicked launch or launched via java -jar Foo.jar. I am reassigning this issue to core libraries.
                                     
2013-04-18
This does not work with Apple's Java either, though the details are a little different.  In this case, file.encoding (and sun.jnu.encoding) are set to "MacRoman" ("SJIS" if the default language is Japanese).  Files containing Japanese text or umlauts are garbled in Notepad (though differently than under US-ASCII).

It doesn't appear that a double-clicked .jar has ever been able to display non-ASCII characters on MacOS X.

                                     
2013-06-25
7u40-defer-request justification:  This bug should be deferred because making changes to the default file.encoding would be too risky this late in an update release.

This bug documents long-standing behavior: it has never been possible for a double-clicked .jar to display non-ASCII characters, even dating back to Apple's JDK6.

Care will need to be taken to allow double-clicked .jars to use a file.encoding other than US-ASCII, while maintaining correct behavior for other launch methods & locales.

We plan to target a fix for 8, and backport to 7 from there.

                                     
2013-06-27
need SQE-OK for deferring this issue.
                                     
2013-06-28
SQE is OK since this functionality never worked
                                     
2013-07-01
A workaround that an application can use is to explicitly specify an encoding when reading a file, instead of relying on the default encoding.  The following change made to the Notepad demo allows it to correctly display the file containing non-ASCII characters when launched via double-clicking the .jar:


*** 789,795 ****
                  status.add(progress);
                  status.revalidate();
  
!                 Reader in = new FileReader(f);
                  char[] buff = new char[4096];
                  int nch;
                  while ((nch = in.read(buff, 0, buff.length)) != -1) {
--- 789,798 ----
                  status.add(progress);
                  status.revalidate();
  
!                 // Ignore the default encoding and specify UTF-8
!                 Reader in = new InputStreamReader(new FileInputStream(f),
!                                   java.nio.charset.Charset.forName("UTF-8"));
!                 
                  char[] buff = new char[4096];
                  int nch;
                  while ((nch = in.read(buff, 0, buff.length)) != -1) {

                                     
2013-07-02
feedback from the CAP member - 

I could in theory use that workaround myself, but jAlbum is an open framework where 3:rd party developers add plugins and it's not manageable to have all change their code to use an explicit encoding. It's far better to have the bug fixed, isn't it?
                                     
2013-07-03
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/883cc296ec89
User:  naoto
Date:  2013-08-02 22:46:16 +0000

                                     
2013-08-02
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/883cc296ec89
User:  lana
Date:  2013-08-13 18:14:45 +0000

                                     
2013-08-13



Hardware and Software, Engineered to Work Together