之前我一直把 0hB6AA 当作是有些特殊的字符串，Deepseek提醒说，它是 Varbinary 类型（二进制数据），这引起了我的兴趣。一直以来，都希望能像C语言那样，可随时将字符当作数值那样处理，也就是将 0hB6AA 与 0xB6AA 互换着玩。这下子，Varbinary 类型似乎满足了我的需求！嘿嘿。

车天車地也不知与“纯汉字”有什么关系？

当然有关系！让我们换一种“类C”方式重写一下顶楼的“UTF-8编码汉字判断函数”：

* UTF-8编码汉字判断
FUNCTION IsUTF8Chinese(tcChar)
LOCAL lnByte1, lnByte2, lnByte3, lnLen, lnUnicode

lcUnicodeLE = strconv(tcChar, 12)    && 将 UTF-8 转换为 Unicode
lcUnicodeBE = substr(lcUnicodeLE, 2, 1) + LEFT(lcUnicodeLE, 1)
lcUnicodeBE = STRCONV(lcUnicodeBE, 15)
lnUnicodeBE = EVALUATE("0x" + lcUnicodeBE)
RETURN (lnUnicodeBE >= 0x4E00 AND lnUnicodeBE <= 0x9FFF)
ENDFUNC

因VFP的 Unicode 转换结果是小端序，需高低位对调。

[此贴子已经被作者于2025-11-19 15:15编辑过]

UTF-16核心编码 0x4E00 ~ 0x9FFF，不考虑UTF-16扩展编码？

STRCONV()出来的是机内码 0h224E，U+4E22 是 0x4E22
? STRCONV(0h224E,6)
? STRCONV(BINTOC(0x4E22,"2rs"),6)

之所以在意这个大端序、小端序，只因 VFP 的 IDE 无法直接显示 Unicode 字符，软件调试时，只能在调试窗口监视其编码的字面值；而小端序我永远反应不过来，永远没办法第一反应直接将224E与“丢”对应起来，4E22才容易对应上。
这也是我只爱 UTF-8 的原因。
UTF-8 无歧义，无混乱，是全宇宙最最最最伟大的字符编码！
——不接受反驳。

不考虑。
只考虑 USC-2 子集。
前边看你建议将 UTF-8 转 ANSI，那个子集其实更小哇！
STRCONV(x, 6) 和 STRCONV(x, 11)，其实是不那么安全的，一不留神就可能转换出??。

那就是只考虑 UTF-16 核心编码 0x4E00 ~ 0x9FFF
这样是不是可以直接用 UTF-8 机内码 0hE4B880~0hE9BFBF 判断就可以？

* UTF-8编码汉字判断
FUNCTION IsUTF8Chinese(tcChar)
    RETURN BETWEEN(tcChar,0hE4B880,0hE9BFBF)    && 假设tcChar是3字节UTF-8字符
ENDFUNC

这个……直觉可能不太安全？
1110xxxx
10xxxxxx
10xxxxxx
这种掩码模式，当中存在大量无效缺码，如此简单粗暴比较，心中不太有底气……
另，很重要的一点：
lcUnicodeLE = strconv(tcChar, 12) 将utf-8 转换至 unicode ，不是脱裤子放P，其主要副作用是，自动验证utf-8字符参数的有效性——若自己写，需逐字节验证掩码，代码挺繁琐的。

[此贴子已经被作者于2025-11-19 07:23编辑过]

RETURN (lnUnicodeBE >= 0x4E00 AND lnUnicodeBE <= 0x9FFF)
RETURN BETWEEN(tcChar,0hE4B880,0hE9BFBF)
这两句有本质上的差别吗？