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

N/A

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.
  xxxxx@xxxxx  



======================================================================

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   xxxxx@xxxxx   '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.
  xxxxx@xxxxx   2004-01-15
  xxxxx@xxxxx   2004-06-09

I am going to close this as duplicate of RFE 4153167.
  xxxxx@xxxxx   2004-06-09