讲真，遇到Unicode字符，应尽量地转换至UTF-8来处理，而尽量不要转换至Unicode（UCS-2）。
原因很简单：
UTF-8的英文字符，完全兼容ANSI，这样一来，许多涉及字符串的代码，几乎不需改动或改动很小，即可升迁至UTF-8；而UCS-2则很麻烦，英文的0h00就搞得人肝肠寸断、梨花带雨的。

自Windows NT开始采用Unicode（UCS-2）编码，大约是在15～20年前；再稍过一些时日，Java诞生，也采用了Unicode（UCS-2）编码。

这其实是个悲剧！鬼佬让中国人给骗了。呵呵。

那时，天还很蓝，草地还很绿，PM 2.5还远远不曾超标……鬼佬们天真地以为，只要用2字节16位65536种字符，就能包含地球上一切字符，于是欣然采用了Unicode（UCS-2）编码。

后来，他们才发觉自己好傻好天真！单单是中文字符，总数就已远超十万个！然后，这才亡羊补牢地搞什么utf-16、utf-32之类古里古怪的编码方案，说实话，大错已铸成，积重难返了。

相比utf-16，其实utf-8优势相当明显，特别是针对英语而言尤其如此。用在网络传输，utf-8也非常优秀、安全、方便，可称得上舍我其谁！

Windows API的W系列采用utf-16编码，其实是相当不智的。

UTF-8编码，最优雅、也最最令人喜爱之处是：

UTF-8不会主动插入“硬编码字符”0x00和0xFF，这意味着，即使是调用年代最远古的C代码字符处理函数，也不会遇到特别麻烦；而至于UCS-2、utf-16、utf-32则不成的，到处是0x00，一切字符处理函数，只要遇到utf-16，就必须统统推倒重来！所以说，Windows API的W系列采用utf-16编码，那纯粹是自寻烦恼！自找不痛快！！

实战中，我比较偷懒，一般直接调用C库函数来处理Unicode字符。
至于传递参数，那当然是转为UTF-8更安全、更优胜！
具体到你提及的uniLenC()函数，我查了一下函数库，C实现非常简单，只是一个静态查找表和一个宏：
//-----------------------------
//定义查找表，长度256，表中的数值表示以此为起始字节的utf8字符长度
static uchar utable[] =
{
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
    2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
    3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
    4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 6, 6, 1, 1
};
#define Ulength(x) utable[(x)]
//-----------------------------
这个C实现，可直接翻译成VFP原生代码，无任何问题的。

utf-8编码最诱人的好处是：绝不会让你遇上?? —— 但凡用VFP处理过Unicode字符的同学，相信能够明白我说的是什么。只要你传递的参数是utf-8，无论是传入还是传出，都不必担心??问题。

严格说来，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，可能是最优、最安全的方案，没有之一。