什么回事？
0xFF9F - 0x004E 那里来的？

看来还没搞清 0h与0x的关系

一眼就明，还用去算：
0x9FFF 与 0xFF9F
0x4E00 与 0x004E

好吧，你就直接回答：
0h0100 是否落在 0h004E ~ 0hFF9F 区间？
你只需回答：是 或 否
不需任何分析。
（笔者注：我经常这样命令Deepseek。）

就当是字符串比较这样说得吧
不知你车来车去又车到 0h0100 与 0h004E ~ 0hFF9F 的比较目的是什么？
直接探讨完善 IsUTF8Chinese 就好了。

我意思是：
Unicode汉字基本平面（BMP）的范围是 ‌U+4E00 至 U+9FFF‌，覆盖了绝大多数常用汉字（约20900个）。
而非你信口胡诌的 0h004E ~ 0hFF9F。
这个范围用“大端序”机内码去表述是准确的，然而，当你试图用 Windows 默认的小端序机内码去描述，则会引发混乱。
换句话说，稳妥的字符区间比较是0x，而非0h。
至于用 0h 能够比较 UTF-8，那纯属运气好！内在原因是 UTF-8 的编码设计，极其科学、合理，规避了可能因字节顺序而引发的混乱，这恐怕也是Win10/11的记事本，默认改用 UTF-8 编码存储的主要原因。
但，UTF-8 用在某些地方，则并不如 USC-2方便，比如本例所涉及的汉字编码区间查询。

UTF-8 用在哪些地方不那么方便，我举几个例子，比如说：

lenU(Utf8)
SubstrU(Utf8, 3, 5)
leftU(Utf8, 13)
rightU(Utf8, 11)

因 UTF-8 字符长度不固定，必须从头至尾扫描掩码，才能确定字符个数。倘若：
Unicode = STRCONV(Utf8, 12)
则：
lenU(Unicode)
SubstrU(Unicode, 3, 5)
leftU(Unicode, 13)
rightU(Unicode, 11)

那瞬间便不再是问题，因 Unicode BMP 平面定长2字节。

你重心是放在UTF16，我是想不用转到UTF16而直接在UTF8处理，因入口就是UTF8。
因先说定不考虑扩展编码，汉字的UTF8还有不是3字节编码的吗？
之前提到的按每位字节比较来判断是否UTF8汉字未必正确。

谁在信口胡诌？
继续吹水，又要我费口水，车来车去你还是没分清0h与0x的关系。
再解释一次：
对于16位无符号整数0x4E00，其内码为0h004E，0x4E00与0h004E是同一个数据的两种表达形式。
所以 0h004E ~ 0hFF9F 也可以理解为 0x4E00 ~ 0x9FFF  
如：
0x4E00 -- 0h004E
0x4E01 -- 0h014E
...... -- ......
0x4E10 -- 0h104E
...... -- ......
0x9876 -- 0h7698
...... -- ......
0x9EFF -- 0hFF9E
0x9FFF -- 0hFF9F

可能是我最初用 BETWEEN(v, 0h..., 0h...) 误导了你。

最后做一下UTF16与UTF8的汉字编码对照过程就可以找出有无问题