<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Sherman,<br>
    <br>
    Thank you for the info. MS936.map is really out-of-date. Updating it
    will be very very helpful.<br>
    <br>
    On 05/30/2012 02:12 PM, Xueming Shen wrote:
    <blockquote cite="mid:4FC5BA33.2000507@oracle.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Hi Charles,<br>
      <br>
      The MS936 charset is long overdue for a update. See&nbsp; CR#6183404.
      The mapping need<br>
      to be re-generated from MS's latest 936 table (not, MS936 should
      just follow MS's mapping<br>
      table, not GB18030) As noted in MS936.map, the existing mapping
      table uses 1894 entries<br>
      from GBK UDC block for EUDC mapping, as suggested by IBM engineer
      back to 1999, which<br>
      was a reasonable approach back then.<br>
      <br>
      I will try to generate a new MS936 for JDK8.<br>
      <br>
      -Sherman<br>
      <br>
      On 5/23/2012 1:03 AM, Charles Lee wrote:
      <blockquote cite="mid:4FBC99C9.7080508@linux.vnet.ibm.com"
        type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        Hi guys,<br>
        <br>
        We have a simple test case:<br>
        <br>
        for (String cname : new String[] { "GBK", "MS936", "GB18030" })
        {<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Charset charset = Charset.forName(cname);<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; System.out.println("charset: " + charset.name());<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; CharsetEncoder ce = charset.newEncoder();<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; char[] chars = new char[] { 0xE585, 0xE586, 0xE592 };<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; CharBuffer cb = CharBuffer.wrap(chars);<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ByteBuffer bb = ce.encode(cb);<br>
        <br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; for (char c : chars) {<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; System.out.printf("\\u%04x", (int) c);<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; System.out.print(" -&gt; ");<br>
        <br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; for (byte b : bb.array())<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if (b != 0x0) {<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; System.out.printf("\\x%02x", (int) b &amp; 0xFF);<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; System.out.println("");<br>
        &nbsp;&nbsp;&nbsp; }<br>
        <br>
        The output is <br>
        charset: GBK<br>
        \ue585\ue586\ue592 -&gt; \xa2\xa0\xa2\xab\xa3\x40<br>
        charset: x-mswin-936<br>
        \ue585\ue586\ue592 -&gt; \xa2\xa0\xa2\xab\xa3\x40<br>
        charset: GB18030<br>
        \ue585\ue586\ue592 -&gt; \xa2\xa0\xa3\x40\xa3\x4c<br>
        <br>
        From the msdn[1], U+E000 -&gt; U+F8FF is in the EUDC scope. So
        U+E586 is in the EUDC scope. But the mapped code in MS936/GBK is
        0xA2AB, it is not in the EUDC scope.<br>
        With another simple test case, you can find there are more codes
        that is not mapped right:<br>
        <br>
        for (int i = 0xE000; i &lt; 0xE000 + 1894; i++) {<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; String s = new String(new char[] { (char) i });<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; byte[] bs = s.getBytes("MS936");<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; int b0 = (int) bs[0] &amp; 0xFF;<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; int b1 = (int) bs[1] &amp; 0xFF;<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if ((b0 &gt;= 0xAA &amp;&amp; b0 &lt;= 0xAF) &amp;&amp;
        (b1 &gt;= 0xA1 &amp;&amp; b1 &lt;= 0xFE))<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; continue;<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if ((b0 &gt;= 0xF8 &amp;&amp; b0 &lt;= 0xFE) &amp;&amp;
        (b1 &gt;= 0xA1 &amp;&amp; b1 &lt;= 0xFE))<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; continue;<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if ((b0 &gt;= 0xA1 &amp;&amp; b0 &lt;= 0xA7) &amp;&amp;
        (b1 &gt;= 0x40 &amp;&amp; b1 &lt;= 0xA0))<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; continue;<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; System.out.printf("\\u%04X -&gt; \\x%02X\\x%02X%n", i,
        b0, b1);<br>
        &nbsp;&nbsp;&nbsp; }<br>
        <br>
        <br>
        I have written a generator in C#[2] which outputs the mapping
        code in GB2312[3] and GB18030[4] in scope U+E000 and U+F8FF to
        find that most of code are the same. Hereby I suggest we may
        follow the code from GB2312 and the changed map file in openjdk
        can be found [5][6].<br>
        <br>
        Would anyone help to take a look on this issue?<br>
        <br>
        <br>
        <br>
        [1] <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://msdn.microsoft.com/en-us/library/windows/desktop/dd317837%28v=vs.85%29.aspx">http://msdn.microsoft.com/en-us/library/windows/desktop/dd317837%28v=vs.85%29.aspx</a><br>
        [2]
        <meta http-equiv="content-type" content="text/html;
          charset=ISO-8859-1">
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Elittlee/OJDK-63/webrev.00/Program.cs">http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/Program.cs</a><br>
        [3] <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Elittlee/OJDK-63/webrev.00/gb2312Map.txt">http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/gb2312Map.txt</a><br>
        [4] <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Elittlee/OJDK-63/webrev.00/gb18030Map.txt">http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/gb18030Map.txt</a><br>
        [5] <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Elittlee/OJDK-63/webrev.00/GBK.map.new">http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/GBK.map.new</a><br>
        [6] <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Elittlee/OJDK-63/webrev.00/MS936.map.new">http://cr.openjdk.java.net/~littlee/OJDK-63/webrev.00/MS936.map.new</a><br>
        <br>
        P.S: Sorry for the late notice.<br>
        <br>
        <br>
        On 03/29/2011 03:00 PM, Charles Lee wrote:
        <blockquote cite="mid:4D918382.7070905@linux.vnet.ibm.com"
          type="cite">
          <meta content="text/html; charset=ISO-8859-1"
            http-equiv="Content-Type">
          On 03/28/2011 11:06 PM, Alan Bateman wrote:
          <blockquote cite="mid:4D90A40C.6090802@oracle.com" type="cite">
            <meta content="text/html; charset=ISO-8859-1"
              http-equiv="Content-Type">
            Charles Lee wrote:
            <blockquote cite="mid:4D9000B7.8080504@linux.vnet.ibm.com"
              type="cite">
              <meta content="text/html; charset=ISO-8859-1"
                http-equiv="Content-Type">
              :<br>
              <br>
              It looks similar. How can I find the patch quickly? I
              notice it says "the list is attached to this CR". Is it
              CR-<font face="">6183404? Since cr has the pattern
                cr.openjdk.java.net/~username/id, how can I know who is
                the committer to this CR?<br>
              </font></blockquote>
            cr.openjdk.java.net is the place where we push webrevs when
            a patch is out for review. I don't think this one is one
            anyone's list for jdk7 and the list attached to the bug is
            likely the list of incorrect mappings. If this is fixed then
            I assume the fix will update the mappings in
            jdk/make/tools/CharsetMapping/MS936.map.<br>
            <br>
            -Alan<br>
          </blockquote>
          I have output more bytes[1] to see whether other bytes are
          encoded correctly. But unfortunately it is not. It is kind of
          like, on windows, using ms936, PUA of ms936 use the PUA of
          gb18030. In wikipedia, it says gb18030 is compatible with gbk
          which ms936 implemented. Can we conclude that ms936 should
          follow the gb18030's behavior?<br>
          <br>
          <br>
          [1] 0xE585, 0xE586, 0xE587, 0xE588, 0xE589, 0xE58a, 0xE58b,
          0xE58c, 0xE58d, 0xE58e, 0xE58f, 0xE590, 0xE591, 0xE592,&nbsp;
          0xE593, 0xE594, 0xE595, 0xE596, 0xE597,&nbsp; 0xE598, 0xE599,&nbsp;
          0xE59a, 0xE59b, 0xE59c, 0xE59d, 0xE59e, 0xe79f.<br>
          Using MS936 charset, we expect:<br>
\xa2\xa0\xa3\x40\xa3\x41\xa3\x42\xa3\x43\xa3\x44\xa3\x45\xa3\x46\xa3\x47\xa3\x48\xa3\x49\xa3\x4a\xa3\x4b\xa3\x4c\xa3\x4d\xa3\x4e\xa3\x4f\xa3\x50\xa3\x51\xa3\x52\xa3\x53\xa3\x54\xa3\x55\xa3\x56\xa3\x57\xa3\x58\xa6\xfe<br>
          but we got:<br>
\xa2\xa0\xa2\xab\xa2\xac\xa2\xad\xa2\xae\xa2\xaf\xa2\xb0\xa2\xe3\xa2\xe4\xa2\xef\xa2\xf0\xa2\xfd\xa2\xfe\xa3\x40\xa3\x41\xa3\x42\xa3\x43\xa3\x44\xa3\x45\xa3\x46\xa3\x47\xa3\x48\xa3\x49\xa3\x4a\xa3\x4b\xa3\x4c\xa7\xa0<br>
        </blockquote>
        <br>
        <br>
        <pre class="moz-signature" cols="72">-- 
Yours Charles</pre>
      </blockquote>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Yours Charles</pre>
  </body>
</html>