<i18n dev> RFR: 8232161 Unexpected 1-way trip conversion entries on MS950 charset

naoto.sato at oracle.com naoto.sato at oracle.com
Wed Oct 30 16:25:21 UTC 2019


Takiguchi-san,

Personally I am reluctant to make this change. If we were to introduce 
this, it will be a different encoding from the existing MS950, so either 
1) we need a new encoding, or 2) make some switch between the encoding, 
possibly a system property. But neither seems worth doing, as :-

1) JDK's conversion is not a bug per se.
2) Seems that Unicode.org's "best fit" was introduced around 2006? (From 
the date on the unicode.org 
(https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt), 
so JDK's mapping predates it.
3) Those code points are not a common ones (BOX DRAWINGS), and no 
customer had a complaint about it.

Please let me know if there are some rationale for fixing it.

BTW, as to the CSR, I don't see it was created.

Naoto


On 10/29/19 11:35 AM, Ichiroh Takiguchi wrote:
> Thanks, Sato-san.
> 
> There is no special meaning to the word "until now".
> I rewrote charset related testcases, then I found this issue.
> 
> I read "Frequently Asked Questions about the CSR" [1],
> I tried "Create CSR" operation, but I could not determine it worked or 
> not...
> (Select "Create CSR" from "More" menu)
> It worked ?
> 
> [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-10-29 03:03, naoto.sato at oracle.com wrote:
>> Hi Takiguchi-san,
>>
>> On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> I have no idea about compatibility impact.
>>>
>>> But according to ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
>>> These are BOX DRAWINGS characters.
>>>
>>> 2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
>>> HORIZONTAL;;;;
>>> 255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT 
>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND RIGHT DOUBLE;;;;
>>> 2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;;;;;N;FORMS 
>>> VERTICAL SINGLE AND LEFT DOUBLE;;;;
>>> 256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;
>>>
>>> I don't think it was used as valuable data until now.
>>> I think it's necessary to evaluate compatibility.
>>
>> What do you mean by "until now"? Are there customers claiming that it
>> should be corrected? Since the current JDK's mapping is not incorrect
>> per se (not just "best match"), I would like to know why this needs to
>> be fixed now.
>>
>> Naoto
>>
>>>
>>> To Sato-san,
>>> if you have any question and suggestion, please let me know.
>>>
>>> To other reviewers,
>>> please let me know if you have any question and concern.
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>>
>>> On 2019-10-19 16:36, Alan Bateman wrote:
>>>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>>>>> Hello.
>>>>>
>>>>> Could you review the fix ?
>>>>>
>>>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8232161
>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>>>>>
>>>>> I have a concern about 1-way trip conversion entries (4 entries) on 
>>>>> MS950 charset.
>>>>> The detail information is in JDK-8232161 [1]
>>>>>
>>>> Do you know any sense on the compatibility impact of changing this? I
>>>> think Naoto has the same question and we aren't sure if this one with
>>>> need a compatibility property. I think it will need a CSR.
>>>>
>>>> -Alan


More information about the i18n-dev mailing list