JDK-5046759 : Corrupted localized chars in CLI
  • Type: Bug
  • Component: globalization
  • Sub-Component: translation
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-05-13
  • Updated: 2004-06-10
  • Resolved: 2004-06-10
Related Reports
Duplicate :  
Relates :  
Description
When the appletviewer is invoked without the parameters it prints out it's usage. On some locales the usage contains special chars which display corrupted. The same problem found in "jar" tool. Not logging separate bug.

Found with J2SE 1.5 beta2 b50
Locale: all euro (de, es, fr, it, sv)
OS: Windows 2003, Windows XP Pro & Home, Windows 2000 Pro

Comments
EVALUATION Name: rpR10076 Date: 05/18/2004 I was experimenting with German locale, so I'll give specific details for that locale only. I assume that the problems with other locales are similar. When I set input locale/regional settings to German, in the console I have code page 850 (OEM). This can be checked with "mode" command. In this case, both appletviewer and jar display garbage instead of some symbols. However, if I set code page to 1250 (WIN) (done with the command "mode con cp select=1250"), both jar and appletviewer display text correctly. It looks like localized messages were entered using wrong encoding. ###@###.### ====================================================================== Please view the java locale support document at: http://java.sun.com/j2se/1.5.0/docs/guide/intl/locale.doc.html#jfc It states that the windows encoding supported is 1252 for Latin/Western Europe. Please try "chcp 1252" on windows terminal to set the code page to 1252. Microsoft Windows uses Cp1252. But DOS uses Cp850. This created a problem. IBM and other companies have release notes directing the users to use "chcp 1252" in order to display extended characters on DOS windows. Please also refer to evaluation on: 4038677. I am copying ###@###.### 's 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 ###@###.### 2004-06-09 I am going to close this as duplicate of RFE 4153167. ###@###.### 2004-06-09
15-01-2004