Bug 130311

Summary: I18N - Problem with Japanese characters in output window
Product: projects Reporter: rovf <rovf>
Component: AntAssignee: Jesse Glick <jglick>
Status: RESOLVED WONTFIX QA Contact: issues <issues.netbeans.org>
Priority: P2 CC: jf4jbug, kfrank, mpetras
Version: 6.xKeywords: I18N, RELNOTE
Target Milestone: TBD   
Hardware: Macintosh   
OS: Mac OS X   
Whiteboard:
Issue Type: DEFECT Exception Report:
Attachments: Example program to show the error
Screenshot of program execution, shows that question marks are printed instead of Japanese characters

Description rovf 2008-03-17 17:13:56 UTC
I have installed Netbeans 6.0 on Mac OSX 10.4. When I try to System.out.println strings containing Japanese characters,
the characters display correctly in the source code, but are displayed as question marks in the output window.

Note that for instance German umlaut characters display fine.
Comment 1 rovf 2008-03-17 17:15:51 UTC
Created attachment 58506 [details]
Example program to show the error
Comment 2 rovf 2008-03-17 17:18:28 UTC
Created attachment 58507 [details]
Screenshot of program execution, shows that question marks are printed instead of Japanese characters
Comment 3 Ken Frank 2008-03-17 21:36:05 UTC
see also 130117 filed on j2se project since was seen in doing in j2se project
but am thinking this is not limited to j2se project though
as mentioned in that issue, some multibyte appears ok in output window.

ken.frank@sun.com
Comment 4 t_h 2008-03-25 13:01:59 UTC
The String arrives to output window already with default character encoding. Reassigning to ant for evaluation.
Comment 5 Jesse Glick 2008-03-25 21:03:44 UTC
Works fine on Ubuntu (provided that you configure the project with UTF-8 encoding, or use Unicode escape sequences in
the source). Generally speaking, sending non-ASCII characters to standard output streams is highly dependent on your
operating system; it is outside of NetBeans' control. If you want it to work, Linux is your best bet, and generally you
will want your system to be configured to use UTF-8 encoding universally.
Comment 6 Ken Frank 2008-03-25 22:34:29 UTC
since this was filed on mac specifically, should it be closed just because it works
on linux ? Am assuming its valid for users to do what is described in issue on mac.

ken.frank@sun.com
Comment 7 Jesse Glick 2008-03-25 23:36:54 UTC
That's why it's WONTFIX, not WORKSFORME.
Comment 8 Ken Frank 2008-03-26 03:56:28 UTC
yes, understand its marked as wontfix; am asking for technical reasons why it won't or can't be
fixed for mac.  that is, is it a known  mac limitation or issue
or mac jdk one vs something in netbeans ?   I think thats a fair kind of request when
issue is marked as wontfix.

ken.frank@sun.com
Comment 9 Jesse Glick 2008-03-26 05:10:07 UTC
The Java runtime in the user app translates characters to bytes when writing to a stream such as System.out, and
correspondingly translates bytes to characters when reading from the (misleadingly named) Process.getInputStream in NB
(or actually the Ant class which handles I/O for <java>). If in the first case the OS defines a platform encoding which
cannot represent some characters, it replaces them with '?'. Mac OS X, from what I recall (I have no access to a Mac to
verify), uses some funny encoding which is incapable of representing full Unicode; ditto Windows and Solaris; whereas
all modern Linux distributions use UTF-8 throughout and so have no such problem. Similar considerations apply to
filenames and other OS-visible strings: a Linux machine using an ext3 filesystem (normally interpreted as using UTF-8)
can trivially name a file with any Unicode characters, but on other OSs this will not work in many cases, depending on
implementation details of the JRE, and the particulars of the OS installation (e.g. Japanese Windows vs. American Windows).
Comment 10 t_h 2008-03-26 10:21:23 UTC
*** Issue 130317 has been marked as a duplicate of this issue. ***
Comment 11 Ken Frank 2008-03-26 15:55:11 UTC
thanks for the explanation; I've marked with relnote keyword so can be decided
if it needs a relnote or not later in the cycle.

ken.frank@sun.com
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