Re: master e39cb515a10 1/4: Correctly handle non-BMP characters in Android content file names

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIU, this is because Java uses UTF-16 encoded strings to support
> Unicode, is that right?  If so, why not use encode-coding and
> decode-coding to en/decode between UTF-16 and the internal
> representation?  AFAIR, we want to deprecate CCL, and thus using it in
> new code should be avoided.

I think you've misunderstood that code.  Java communicates with C using
a custom character encoding that, while resembling UTF-8, encodes
characters that UTF-8 represents with 4-byte sequences as 3-byte
sequences of surrogate pairs, and the NULL character as a special
two-byte sequence, and it is this unique (i.e. underivable) coding
system that is being defined here.  It wouldn't be wise to remove CCL
until some better means of defining custom coding systems comes into
existence, and when it does I'll be as glad as you to see it replace
CCL, but until then there's not really an alternative short of
implementing it in coding.c.