Scott, thanks for the great explanation. Though it's
disappointing (as I need to check for _any_ Japanese
character to make this test effective), at least it makes sense.
Scott's explanation is correct: you can't distinguish between a character
represented natively, and the same character represented as an entity
reference. And in your application, you shouldn't, because you really don't
want to constrain the document creator/sender to use one form rather than
the other.
XSLT 2.0 has good facilities for this. There's a function
string-to-codepoints which allows you to convert a string into a sequence of
integers representing the Unicode codepoints; or you can use regular
expressions which include constructs to match particular character
categories - 12360 is in the Hiragana block which is matched by
\p{IsHiragana}.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--