Fix Version/s: 11-pool
Compatibility Risk Description:Applications that expect the existing mapping for those one-way conversion code points will not work. Since these are uncommon box character code points, the risk is low. It should be best avoided to introduce a property to switch back to the old behavior.
Interface Kind:Java API
MS950 charset encoder behaves differently as defined in the Traditional Chinese Windows specification
Windows code page 950 has some n:1 byte-to-char mappings for certain code points. In JDK's MS950 charset, there are 4 char-to-byte mappings differ from Traditional Chinese Windows.
(Actual issue was in https://bugs.openjdk.java.net/browse/JDK-8232161)
I recommend that following 4 char-to-byte mappings need to change.
\u2550 -> \xA2\xA4 \u255E -> \xA2\xA5 \u2561 -> \xA2\xA7 \u256A -> \xA2\xA7
\u2550 -> \xF9\xF9 \u255E -> \xF9\xE9 \u2561 -> \xF9\xEB \u256A -> \xF9\xEA
Traditional Chinese Windows conversion table is:
Newer MS950 definition is:
\u2550, \u255E, \u2561 and \u256A are in BOX DRAWINGS Unicode range.
(See attached 4Chras.png for font glyphs)