今天在研究zip压缩时，压缩完文件之后，需要获取文件的名字以供在窗口显示其信息，结果出现获取的文件名称前面多出一些字符(本来应该是：新建文本文档.txt，结果却是：虢庋顾?新建文本文档.txt)，如下图示

 正确结果应该是：

原先获取字符串的子串时，都是用的是pos()+mid()+len()的方式，没有出现过这种问题，而这次使用的是lastpos()+len()+right()，却出现了子串错误的情况。

        经过查阅文档和demo测试，发现len、lenw、right、Rightw、left、leftw、pos、LastPos这几个方法在使用上存在一个坑，那就是方法返回的值或形参中的个数（例right方法中的第二个参数）到底是按字节的，还是按字符来计算。如果将按字节计算的方法与按字符计算的方法结合使用，自然而然就出现了前面提到的错误问题。

        那究竟哪些是按字节、哪些是按字符计算的呢？

        经过验证，在上述方法中，pos、mid、len是按字节计算，而lastpos、Rightw、leftw的第二个形参则是按字符计算的，最诡异的是right和left两个方法，开发文档对其第二个形参的描述是这样：A long whose value is the number of characters you want returned from the right end of string，其意思就是“从字符串右端返回的字符数”，也就是说是按字符计算的，但是与len和lenw结合使用，你会发现，right、left方法在与len方法一起使用的时候，是按字字符计算，但是与lenw方法一起使用的时候又是按字节来计算。

例如：

        有如下字符：

       string ls_path='C:\Desktop\新建文本文档.txt'

       int li_next = LastPos(ls_path, "\")    //获取ls_path最后一个"\"的个数位置，LastPos按字符计算

       当在Right方法中使用Len时：

                Right(ls_path,(Len(lls_path) - li_next)) ，获取到的值是：虢庋顾?新建文本文档.txt

       而使用lenw时：

                Right(ls_path,(LenW(lls_path) - li_next))，获取到的值是：本文档.txt

        而当Right的第二个形参写死时：

                Right(ls_path,10)，获取到的值是：本文档.txt(说好的按字符计算呢？怎么按字节计算了)

        当在RightW方法中使用len时：

                RightW(ls_path,(Len(lls_path) - li_next))，获取到的值是：p\新建文本文档.txt

                在窗口则显示：乱码+新建文本文档.txt

        而使用lenw时：

                RightW(ls_path,(LenW(lls_path) - li_next))，获取到的值是：新建文本文档.txt

                窗口也显示正常

        而当RightW的第二个形参写死时：

                RightW(ls_path,10)，获取到的值是：新建文本文档.txt

        窗口也显示正常

left与leftW也是如此，

        由此可见right和left方法是多么的坑，所以建议读者朋友在选取以上方法组合使用时请慎重。