Re: [xsl] Unicode question

Subject: Re: [xsl] Unicode question
From: "David Carlisle d.p.carlisle@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 23 May 2018 18:24:50 -0000
> I would suppose that oXygen is showing you UTF-16 source but the
> processing is happening in UTF-8, where the emoji is a single code point
> and corresponding glyph.

Or rather, it is a single unicode code point which is encoded as  two
utf-16 units
or _eight_ bytes in UTF-8.

The XSLT processing is unaffected by the encoding used in the input source
(or by the encoding the processor uses internally to store the strings)


David

On 23 May 2018 at 19:00, Graydon graydon@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, May 23, 2018 at 05:41:44PM -0000, Erik Siegel erik@xxxxxxxxxxx
scripsit:
>>    I have a problem that is Unicode related. Some Unicode characters (for
>>    instance emojis) can have some code *following* the actual character to
>>    indicate a variant. For instance in the following stylesheet, the emoji
>>    character in $x (U+1F61C) is followed by U+DE1C. When I look in oXygen
it
>>    shows me this. But when I run the stylesheet it reports a string length
of
>>    1 and only a single codepoint.
>>
>>    I suppose that is true, it is only  single character. But how can I
find
>>    out (in XPath) what the value of the second bcharacterb (indicator?)
is?
>>    Or is that impossible anyway?
>
> If I try to look up U+DE1C, I am informed that this is not a Unicode
> code point.   It is the second half the UTF-16 surrogate pair --
> D83D DE1C -- use to represent U+1F61C in UTF-16.
>
> (See <https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%98%9C> )
>
> I would suppose that oXygen is showing you UTF-16 source but the
> processing is happening in UTF-8, where the emoji is a single code point
> and corresponding glyph.
>
> -- Graydon

Current Thread