<i18n dev> RFR: 8364365: HKSCS encoder does not properly set the replacement character [v2]
Volkan Yazici
vyazici at openjdk.org
Thu Aug 7 15:07:10 UTC 2025
On Wed, 6 Aug 2025 00:25:58 GMT, Xueming Shen <sherman at openjdk.org> wrote:
>> test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 139:
>>
>>> 137: return coderResult.isUnmappable();
>>> 138: };
>>> 139: }
>>
>> I'd appreciate it if you can double-check these _"Is the given `char[]` unmappable for a particular encoder?"_ test generators.
>
> I might be missing something you're trying to do here, but any reason why we can't just do
>
> return c -> !encoder.canEncode(c[0]);
>
> as the predicate? I think we are doing 'single char', no surrogates, here, right?
>
> or simply go with
>
> private static char[] findUnmappable(CharsetEncoder encoder) {
> for (char c = 0; c <= 0xff; c++) {
> if (!encoder.canEncode(c))
> return new char[]{c};
> }
> System.err.println("Could not find an unmappable character!");
> return null;
> }
You're right. Simplified as suggested in ba1e5ff4de6.
I wanted to use `{Single,Double}Byte.Encoder` methods deliberately, since those were the ones triggering the failure. Though `CharsetEncoder#canEncode(char)` should do the trick, plus, it is public.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2260610086
More information about the i18n-dev
mailing list