JDK-4038677 : In DOS prompt java prints in iso-8859-2 not CP-852 in poli
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio.charsets
  • Affected Version: 1.1
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1997-03-13
  • Updated: 2004-01-15
  • Resolved: 2004-01-15
Related Reports
Relates :  
JDK-5046759 - Corrupted localized chars in CLI
Description
Name: mc57594			Date: 03/13/97


Unicode text printed with System.out.println in application run 
with java prints text using iso-8859-2 charset not CP-852 used by
Command Prompt in Windows.

company -  , email - ###@###.###
======================================================================

One of our licensees has this to add....

The problem I am encountering is that the java environment has the
encoding (file.encoding systems property) to be 8859_1.  The DOS
console thinks it is Cp850.
When the tool prints the UNICODE character \u00D6, the java environment
converts it to code point D6 in the 8859_1 codepage.  When it is 
displayed on the DOS console, it is an the D6 codepoint of the 850 table.
I checked the javasoft "bugParade" finding two relevant
bugs , 4038677 and 4080134.  4038677 is my exact problem except that
this person encountered it using 8859_2 and Cp852.  Neither of the bug
reports offer work around or have any reply from javasoft.  
This is a big problem for me.

- mick.fleming
Comments
WORK AROUND Name: mc57594 Date: 03/13/97 ======================================================================
11-06-2004
EVALUATION The underlying issue is the dual codepage support (ansi & oem codepages) which differentiates the default codepage used for console i/o and display and windows based display. J2SE runtime chooses the ANSI codepage when determining the default encoding whereas native console codepage is the OEM codepage. RFE 4153167 expresses a desire for either API support or automagical support of some kind which would allow the VM bootstrapping process to either automatically detect the appropriate (ANSI or OEM) codepage and choose the requisite default encoding based on that determination. However this is not an issue determined to be of high priority at this time, Also this bug was raised on a very old j2se release 1.1.x. Since no significant business case exists or is apparent with this issue I am closing this bug out now as will not fix. ###@###.### 2004-01-15
15-01-2004