我说的也是字符数而非字节数，字节数谁都会数数

就是了
还是回到VFP的问题，VFP没有“字”的概念，顶多也是双字节、宽字符。W带头的通常也是指“宽字符”，所以VFP调用W***()通常要用到STRCONV(...,5)。
VFP提到的UNICODE也只有局限到一些，至于UNICODE的“字”，通常有8bit、16bit、24bit、32bit、40bit、48bit...甚至更多bit。
VFP如何精准获取UNICODE字符串，尤其是从文件中获取，甚至在超大文件中获取，通常是要通过缓冲来处理。

严格说来，utf-16其实是不定长的。在Unicode基本平面定义的字符，没错儿是2字节；而在辅助平面定义的字符，则为两个2字节（即4字节）。
故而，若追求定长，那必须是UTF-32，每个字符都使用4字节。当然那样一来，存储英文的磁盘空间，就多了三倍。存储中文，也比ANSI多了将近1倍。
不能因为Windows API是utf-16，就说它好啊。
USC-2我也觉得爽哇！偷懒时当然我也曾这么干：

LenByte = len(c)
LenUnicode = int(LenByte/2)
假装Unicde == USC-2，假装用户不可能用到辅助平面定义的字符。

只是，在VFP这种ANSI内核的环境之下，若需处理Unicode，那么，转换成UTF-8，可能是最优、最安全的方案，没有之一。