-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
1.4.0, 1.4.2
-
generic, x86
-
generic, windows_xp
The problem has been there for years, it's not merlin specific.
Currently CharToByteUnicode inherits the canConvert(char) from it's
parent class CharToByteConverter, which hardcodes the output byte
buffer length to "3" before calling "convert() to test if the input
"char" is acceptable by the converter or not, in case of Unicode,
we need to write out 2 bytes of "unicode byte order mark" first by
default, which causes the "canConverter" method totally useless.
One example is to use native2ascii -reverse -encoding UTF16, it
doesn't convert the \udddd unocide noataion to real unicode correctly.
Currently CharToByteUnicode inherits the canConvert(char) from it's
parent class CharToByteConverter, which hardcodes the output byte
buffer length to "3" before calling "convert() to test if the input
"char" is acceptable by the converter or not, in case of Unicode,
we need to write out 2 bytes of "unicode byte order mark" first by
default, which causes the "canConverter" method totally useless.
One example is to use native2ascii -reverse -encoding UTF16, it
doesn't convert the \udddd unocide noataion to real unicode correctly.
- duplicates
-
JDK-4839755 CharToByteUnicode.canConvert() does not work correctly
-
- Closed
-
-
JDK-4915906 native2ascii -reverse -encoding UnicodeX misses the first \uxxxx sequence
-
- Closed
-