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(_at_)marost(_dot_)ca
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
On Wed, May 23, 2018 at 05:41:44PM -0000, Erik Siegel
erik(_at_)xatapult(_dot_)nl 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 “character” (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
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--