如果是标准字库编码，字或符是有区位定义。

确实是搞复杂了，呵呵，用区位比较简单。
另，#3的代码，英文符号也有漏洞，“\”(0h5C)这个符号，居然成功混过了这一句代码：
*设c1 = "\"
c2 = Strconv(c1, 1)
? c2 == c1

标准字库本身就有规范，直接查表就可以。
简单写个GB2312-80标准的

hzs = "汉＃字￥啊％挨＆鼾、尊。昨℃匾＄鼽│左┃卦┄阿┅鼹"
FOR i=1 TO LENC(hzs)
    hz = SUBSTRC(hzs,i,1)
    ? " ", hz, hzqm(hz)
ENDFOR
RETURN

FUNCTION hzqm(hz)
    LOCAL qm
    qm = BITRSHIFT(ASC(hz)-0xA0A0,8) 
    RETURN ICASE(BETWEEN(qm, 1, 9),"符号",;
                 BETWEEN(qm,16,55),"一级汉字",;
                 BETWEEN(qm,56,87),"二级汉字",;
                 "非标码")
    
ENDFUNC

妙招，高人啊

弊就弊在，时光匆匆流转到了2022年，作为一群真的猛士，我们每天需直接面对、需直接处理的字符串，绝大多数是UTF-8、Unicode LE、Unicode BE啊，亲！
光用硬编码对付GB2312-80、GBK，那可不成啊，亲！
还必须做到能够妥善处理Strconv(x, 6)='??'的那一堆千奇百怪的偏僻字符啊，亲！

考虑到，今时今日，在这个星球上，几乎一切网页、一切文档，字符串皆采用UTF-8编码，这已经是事实上的“行业标准”了！——无论VFPer喜欢也罢，诅咒也罢，无奈也罢，接受也罢，敌视也罢——故而，字符串相关处理函数的编程开发，若能够直接针对UTF-8编码进行处理，我相信，那必然会是性价比最高的代码开发了。

你说呢，亲？

字符编码都可以互转的
VFP的Strconv()也绝对没问题
问题是VFP自身输出的兼容问题，看到的不等于实际的，??也就是编码不在兼容之内，有人叫他“乱码”。
要用UTF-8，VFP也可以找个支持兼容编码控件来处理，这不是什么大的问题。

VFP作为桌面数据库应用涉及UTF-8的不多，但作为windows平台的应用，应该也能利用windows的功能应付UTF-8的应用吧。
试了一下，VFP也可以直接编辑web页面的。