Name: bb33257 Date: 12/23/98


The converters for the Korean encodings Cp949 and Cp949C have one broken
mapping, and they are missing a few mappings required for compatibility
with the Microsoft encoders having the same names....

ByteToCharCp949, ByteToCharCp949C

Mapping Defect Correct Mapping
xAFFE -> null xAFFE -> uFFFD

There are also several new mappings that need to be added in order
to have compability with Microsoft's converters for these two code
pages. They are:

u00B7 (MIDDLE DOT) -> xA1A4
u00AD (SOFT HYPHEN) -> xA1A9
u2015 (HORIZONTAL BAR) -> xA1AA
u223C (TILDE OPERATOR) -> xA1AD
uFF5E (FULLWIDTH TILDE) -> xA2A6
u2299 (CIRCLED DOT OPERATOR) -> xA2C1

I'm filing this bug on behalf of IBM Japan's DBCS group. Since
I don't really know that much about these issues myself, feel free
to contact Masayuki Fuse at <###@###.###> for more info.

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

Name: krT82822 Date: 05/06/99


Hello,
When we use InputStreamReader to read our data with encoding CP949 to
our JTextArea (code conversion from CP949 to UCS2) and then use
OutputStreamWriter to write the data from JTextArea with encoding CP949
(code conversion from UCS2 to CP949. We expect to have the new data and
the original data will be the same since we just do the round trip
conversion. However, it is not the case. The hex value of the test
data is:
 
8141 8D62 9DE4 B9B9 CAA1 E4A4
 
However, if I use MS949 instead, the round trip conversion is OK. I
expect there is the bug in code conversion for CP949. Also, I can not
find MS949 in the list of supported encoding in JDK 1.2.

We also have the same problem with code conversion for EUC_CN.
8140 93CD A8A6 AA40 D1ED E979 FE4F

As for CP936, is it the same as EUC_CN? That is, if I have a text file in
CP936, can I use EUC_CN to code converted it to UCS2 via InputStreamReader?
(Review ID: 57911)
======================================================================